Saving an image to file from windows clipboard
I just threw this together because I find myself needing it now and
then. Requires PIL and optionally ImageMagick to convert to png, since
I think PIL is not able yet to convert a bmp to a png. You can of
course use the os.path module instead of the path module. I keep it in
my windows start menu for convenience. Thanks PIL folks!
from PIL import ImageGrab
from os import popen
from path import path
myimage = ImageGrab.grabclipboard()
myfile = path(r'D:\Profiles\csb046.DS\Desktop\screen.bmp')
f = file(myfile,'wb')
myimage.save(f)
f.close()
command = 'convert "' + myfile + '" "' + myfile.replace('bmp','png') +
'"'
popen(command).read()
myfile.remove()
Stephen
--
http://mail.python.org/mailman/listinfo/python-list
Re: Saving an image to file from windows clipboard
Thanks -- works as advertised. Stephen -- http://mail.python.org/mailman/listinfo/python-list
Re: Photo layout
Thanks! This works well -- I was letting myself be too intimidated with
reportlab before looking at the documentation, but it was really not
hard at all. I think I figured out how to do landscape mode too.
from reportlab.pdfgen import canvas
from reportlab.lib.pagesizes import letter
def insertPicture(c):
c.drawInlineImage("geese1.jpg",100,100,200,150)
width, height = letter
letter = height, width # change to landscape
c = canvas.Canvas("picture.pdf",pagesize=letter)
insertPicture(c)
c.showPage()
c.save()
Larry Bates wrote:
> You can use Python Imaging Library (PIL) and ReportLab to resize and
> place the photos on a page quite easily. Actually ReportLab calls
> PIL automatically to resize the photos when you call .drawInlineImage
> method of the canvas object with the proper width and height arguments.
>
> To get ReportLab go to: http://www.reportlab.org
>
> Note: I'm assuming the photos are in .JPG, .TIF or some format that
> PIL can recognize. If they are in some proprietary RAW format you
> will need to convert them first.
>
> -Larry Bates
>
> Stephen Boulet wrote:
> > Is there a python solution that someone could recommend for the following:
> >
> > I'd like to take a directory of photos and create a pdf document with
> > four photos sized to fit on each (landscape) page.
> >
> > Thanks.
> >
> > Stephen
--
http://mail.python.org/mailman/listinfo/python-list
Passing a variable number of arguments to a wrapped function.
Is there a better way of doing this so that I don't have to go through every permutation of possible arguments (the example here from the matplotlib 'plot' function): def makeplot(self, xvalues, yvalues, linecolor='', linewidth=''): if linecolor and linewidth: plot(xvalues, yvalues, linecolor, linewidth=linewidth) elif linecolor: plot(xvalues, yvalues, linecolor) elif linewidth: plot(xvalues, yvalues, linewidth=linewidth) else: plot(xvalues, yvalues) Stephen -- http://mail.python.org/mailman/listinfo/python-list
Re: Passing a variable number of arguments to a wrapped function.
Using 'plot(*args, **kwargs)' does seem to work just fine. Thanks to all for their suggestions. Stephen -- http://mail.python.org/mailman/listinfo/python-list
Re: "Best" way to SIGHUP spamd from web page?
Webmin (webmin.com) has a command shell module (cgi over https?). Isn't this an example of a secure way to run commands via the internet? Stephen -- 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
Help with python_fold.vim
I see that the python_fold plugin for vim lets you fold classes/functions, etc. Can someone tell me how to fold/unfold sections? Thanks. Stephen -- http://mail.python.org/mailman/listinfo/python-list
Re: Help with python_fold.vim
Found an earlier thread that answered my question: http://mail.python.org/pipermail/python-list/2005-July/289078.html """Then zo opens the fold under the cursor one level, zO opens it recursively, zc and zC close it non- and recursively. zr opens all folds one level, zR opens them all recursively, zm closes them all one level, and zM closes them all recursively.""" Stephen -- http://mail.python.org/mailman/listinfo/python-list
Printing a percent sign
Hi all. How do I escape the "%" sign in a print statement so that it prints? Thanks. Stephen -- http://mail.python.org/mailman/listinfo/python-list
Re: Printing a percent sign
Thanks -- a percent escapes itself when using %-formatting. Stephen [EMAIL PROTECTED] wrote: > Hi all. How do I escape the "%" sign in a print statement so that it > prints? Thanks. > > Stephen -- http://mail.python.org/mailman/listinfo/python-list
Looping over a list question
I found myself writing: for f in [i for i in datafiles if '.txt' in i]: print 'Processing datafile %s' % f but I was wishing that I could have instead written: for f in in datafiles if '.txt' in f: print 'Processing datafile %s' % f Has there ever been a proposal for this? Just wondering ... Stephen Boulet -- http://mail.python.org/mailman/listinfo/python-list
Re: Looping over a list question
Fredrik Lundh wrote:
[snip]
> probably. but unless your editor or keyboard is horribly broken, you
> can of course press return at the right place instead:
>
>for i in datafiles:
> if '.txt' in i:
> print 'Processing datafile %s' % f
>
> (for this specific case, "endswith" is more reliable than "in", btw)
>
>
My "print" line is actually a long 40 line block. I guess I could just
do
datafiles = [f for f in datafiles if f.endswith('.txt')]
and then loop over it.
[EMAIL PROTECTED] wrote:
> Yes, there has:
> http://groups.google.ca/group/comp.lang.python/browse_thread/thread/9...
Thanks for the link. I didn't know about str.startswith and
str.endswith, which I can see is very useful.
So, not a universally popular proposal. Interesting how different
programming 'phrasings' resonate with different people. For me, for
example, lambda causes my eyes to glaze over.
I do love list comprehensions though. I'd also love to see string
constants implemented some day too (like str.whitespace and
str.ascii_letters).
Stephen
--
http://mail.python.org/mailman/listinfo/python-list
Newbie Help!
Hi All, im new to python i just have a few questions and was wondering if you could help me?? 1. what programming langaugue does python use? or which is most popular? 2. Does anyone know where i could get hold of practice code 3. Any good ebooks or links to start with. (according to the web this is the best place to start.) i know you probally get asked these questions all the time! but im trying to mirgrate for windows to linux. Cheers all CFR -- http://mail.python.org/mailman/listinfo/python-list
Re: ~!~ Britneys New BOOBS
netto 24 bottles 33l 9.99 grolch <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > http://scargo.in - Download pics and videos of Britneys new Boob job > see her new tits naked! > -- http://mail.python.org/mailman/listinfo/python-list
Re: List append
In your code, "array" is a class attribute, so it is shared among all instances. You need to use the __init__ method to define instance (data) attributes instead: def __init__(self): self.array = [] On Sep 14, 11:25 pm, mouseit <[EMAIL PROTECTED]> wrote: > I'm trying to add an element to a list which is a property of an > object, stored in an array. When I append to one element, all of the > lists are appended! > > Example Code: > > class Test: > array = [] > > myTests = [Test() , Test() , Test()] > print len(myTests[1].array) > myTests[0].array.append( 5 ) > print len(myTests[1].array) > > prints: > 0 > 1 > > This is probably a really easy question (I'm very new to python), so > thanks in advance for your help! -- http://mail.python.org/mailman/listinfo/python-list
Tkinter Status on OSX
Hey guys, What is that status of Tkinter on OSX (10.4.10)? I have tried several installations (Python 2.4.4, 2.5 and 2.5.1) all from the official distro sites and others each version has the same major issue.Theproblem is simple to recreate, use any of the simple sample code available here: http://www.pythonware.com/library/tkinter/introduction/x5819-patterns.htm The menu widgets never display...When I literally cut and paste this same code into a VMWare image (windows and linux) the same code executes as you'd expect it, all the widgets display and work properlyliterally the same code cut and pasted from OSX into windows/linux Vmware images, gets different results. -- Zenapse.org -- http://mail.python.org/mailman/listinfo/python-list
Reading a tab delimited text file.
Hi, I would like to read a text file of numbers produced by a data acquisition system into three vectors of doubles. The contents of the file are: +0.000e+0 +2.7645134e+1 +2.7745625e+1 +0.4100041e-1 +2.7637787e+1 +2.7731047e+1 +0.0820008e+0 +2.7645134e+1 +2.7750483e+1 ... or +0.000e+0\t+2.7645134e+1\t+2.7745625e+1\r\n ... I would like to read the first column into time_vec, second into ch1_vec and so on. (I have never programmed in python and am having trouble finding a way to do this). Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: Reading a tab delimited text file.
On Feb 23, 4:06 pm, Tim Chase wrote:
> > I would like to read a text file of numbers produced by a data
> > acquisition system into three vectors of doubles. The contents of the
> > file are:
>
> > +0.000e+0 +2.7645134e+1 +2.7745625e+1
> > +0.4100041e-1 +2.7637787e+1 +2.7731047e+1
> > +0.0820008e+0 +2.7645134e+1 +2.7750483e+1
> > ...
>
> > or
>
> > +0.000e+0\t+2.7645134e+1\t+2.7745625e+1\r\n
> > ...
>
> > I would like to read the first column into time_vec, second into
> > ch1_vec and so on.
>
> > (I have never programmed in python and am having trouble finding a way
> > to do this).
>
> Well, a very terse way of doing it would be something like:
>
> time_vec, ch1_vec, and_so_on = zip(*(
> map(float, line.split())
> for line in file('in.txt')))
>
> If my junior developer authored that, I'm not sure whether I'd
> laud her or fire her. :)
>
> If this isn't homework, there are some less terse versions which
> are a bit easier on the eyes and less like some love-child
> between Perl and Python.
>
> -tkc
haha, no this isn't homework. I'm a mechanical engineering student
working on a research project and this program is for my personal use
to analyze the data.
--
http://mail.python.org/mailman/listinfo/python-list
git_revision issues with scipy/numpy/matplotlib
I installed py27-numpy / scipy / matplotlib using macports, and it ran without
failing.
When I run Python I get the following error:
$>> which python
/Library/Frameworks/Python.framework/Versions/2.7/bin/python
$>> python
Python 2.7.3 (v2.7.3:70274d53c1dd, Apr 9 2012, 20:52:43)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
Traceback (most recent call last):
File "", line 1, in
File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/__init__.py",
line 128, in
from version import git_revision as __git_revision__
ImportError: cannot import name git_revision
I get the same error for all three packages. Is this a MacPorts issue or a
different issue?
I am running OS X 10.6 with the Intel Core i5 architecture. At one point I
thought this was a 64-bit versus 32-bit issue, viz.:
>>> import platform
>>> platform.architecture()
('64bit', '')
but I would have thought the MacPorts install would have resolved that.
Any help would be appreciated.
Thanks!
-s
--
http://mail.python.org/mailman/listinfo/python-list
Re: git_revision issues with scipy/numpy/matplotlib
I think the easiest thing to do would be to remove the python.org Python entirely, kill it from the path (which I've already done), and install directly a MacPorts version of Python. Any caveats or warnings about getting rid of the /Library/Frameworks/Python directory? On Jul 7, 2012, at Jul 7 8:40 AM, Hans Mulder wrote: > On 7/07/12 14:09:56, Ousmane Wilane wrote: >>> "H" == Hans Mulder writes: >> >>H> Or you can explicitly type the full path of the python you want. >> >>H> Or you can define aliases, for example: >> >>H> alias apple_python=/usr/bin/python alias >>H> macport_python=/opt/local/bin/python >> >>H> lfpv=/Library/Frameworks/Python.framework/Versions alias >>H> python_org_python=$lfpv/2.7/bin/python >> >> >> Or alternatively use `port select --set' to make one of the MacPort version >> the >> default: >> >> imac:~ wilane$ port select --list python >> Available versions for python: >> none >> python25-apple >> python26 >> python26-apple >> python27 (active) >> python27-apple >> python32 > > That would work if the OP had /opt/local/bin early in his searcht path. > However, the OP has installed Python27 from python.org, and that has > prepended /Library/Frameworks/Python.framework/Versions/2.7/bin to > his PATH, overriding anything he does with "port select". > > He could, of course, change his PATH and move /opt/local/bin to the > front and then use "port select". > > -- HansM > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
multiprocessing help
I'm looking for some help with multiprocessing. Essentially what I'm trying to do is the following: 1. create a main process that gets daemonized 2. spawn two subprocess that live for the life of the daemon 3. each subprocess creates children that do heavy work and exit when the work is done I am not having issues with creating the processes but I can't get them to die. Sometimes it works and they all die and sometimes they don't. Obviously I do not understand the multiprocessing documentation so I'm hoping that somebody can point out what I'm doing wrong. I also understand that my code might be strict adherence to PEP8 and there might be a number of flaws with the code; all of which would be helpful to know, but I'm particularly looking for help with getting what I'm trying to do to work. I'm starting to lose my mind.. I just want to say all processes that spawned from here $@%@$% DIE. Thanks in advance for anybody that has some spare time to point me in the right direction. I am grateful. Thanks. Very Respectfully, Stephen Bunn scb...@sbunn.org sqlimport.py Description: Binary data daemon.py Description: Binary data maindaemon.py Description: Binary data -- http://mail.python.org/mailman/listinfo/python-list
Embedding Python27 in C++ on Windows: CRT compatibility issues with VS2010?
Hello, I'm a relative python newbie but I've been tasked to figure out how to embed calls to a python library in an Excel XLL add-in. The Python/C API for doing this seems pretty straightforward, but I seem to have read somewhere online that it's important that the C++ program or DLL linking to and embedding Python must be using the same CRT as what the Python implementation dll is using. Is this true, or is the Python API written in such a way that there is no dependency on a common CRT? If there is a dependency, does that mean that I cannot use VS2010 to develop this XLL, but should use VS2008 instead, or are there other workarounds? Thanks for the help, Stephen -- http://mail.python.org/mailman/listinfo/python-list
running multiple scripts -- which way is more elegant?
List, First I'm very new to Python. I usually do this kind of thing with shell scripts, however, I'm trying to move to using python primarily so I can learn the language. I'm attempting to write a script that will check a server for various configuration settings and report and/or change based on those findings. I know there are other tools that can do this, but for various reasons I must script this. I have come up with two ways to accomplish what I'm trying to do and I'm looking for the more elegant solution -- or if there is another solution that I have not thought of. Any input would be greatly appreciated and thanks for your time. method 1: = [master script] def execute_script(cscript): process = subprocess.Popen(cscript, stdout=subprocess.PIPE, stderr=subprocess.PIPE) output_data = process.communicate() if process.returncode == 0: return "OK" elif process.returncode == 90: return "DEFER" elif process.returncode == 80: return "UPDATED" else: return "ERROR" if __name__ == '__main__': # Find all configuration scripts print "Searching for config scripts" cscripts = [] for config_script in os.listdir(BASE_DIR + "/config.d"): cscripts.append(BASE_DIR + '/config.d/' + config_script) print "Found %d configuration scripts" % (len(cscripts)) # Loop through scripts and execute for config_script in cscripts: action_title = "Checking %s" % (config_script[len(BASE_DIR + '/config.d/'):]) print "%-75.75s [ %s ]" % (action_title, execute_script(config_script)) [config script template] #!/usr/bin/env python def check(): # do some checking return results return check() method 2: [master script] if __name__ == '__main__': # Find all configuration scripts print "Searching for config scripts" cscripts = [] for config_script in os.listdir(BASE_DIR + "/config.d"): cscripts.append(BASE_DIR + '/config.d/' + config_script) print "Found %d configuration scripts" % (len(cscripts)) # Loop through scripts and execute for config_script in cscripts: import config_script action_title = "Checking %s" % (config_script[len(BASE_DIR + '/config.d/'):]) print "%-75.75s [ %s ]" % (action_title, config_script.check()) [config script template] #!/usr/bin/env python def check(): # do some stuff return result # return str OK, DEFER, UPDATED or ERROR -- http://mail.python.org/mailman/listinfo/python-list
Re: running multiple scripts -- which way is more elegant?
On Mon, Jun 20, 2011 at 1:26 PM, Chris Angelico wrote: > > I'd be inclined toward the second solution if I'm writing all the code > > myself > On Mon, Jun 20, 2011 at 3:21 PM, Florencio Cano wrote: > I'm with Chris, if the config_scripts are going to be implemented in > Python always, the second solution is better for me as the operative > system is less involved. > Thanks for the replies. I would like to use the second method because I plan to implement everything in python. Unfortunately I have not been able to work out how to get the imports to work. import config_script obviously doesn't work and __import__(config_script) works from the python interpreter but fails in the script (ImportError: Import by filename is not supported.) -- http://mail.python.org/mailman/listinfo/python-list
Re: running multiple scripts -- which way is more elegant?
On Mon, Jun 20, 2011 at 11:19 PM, Florencio Cano
wrote:
> > import config_script obviously doesn't work and __import__(config_script)
> > works from the python interpreter but fails in the script (ImportError:
> > Import by filename is not supported.)
>
> You can use this:
>
> exec("import " + module_name)
>
>
Thanks for the hint. I will give that a try.
On Tue, Jun 21, 2011 at 2:48 AM, Terry Reedy wrote:
>
> The main problem of your second method is that you repeat the check
> function in each script. That will be a problem if you ever want to modify
> it. I might put is into a separate file and import into each script.
>
>
repeating the check function in each script is what I think I want. The
check function is what would scan the system and make sure that compliance
is met. I'm slightly confused about how that would become an issue later and
what you mean about importing each of them
>
> import config_script obviously doesn't work and
>> __import__(config_script) works from the python interpreter but fails in
>> the script (ImportError: Import by filename is not supported.)
>>
>
> Look at builtin function __import__(filename).
> Terry Jan Reedy
I looked into __import__(filename) but that was not working for me, based
upon the error in my previous message. I will give Florencio Cano's solution
of using exec a try. If there are any other ideas out there I'm all ears :)
Thanks everybody for the replies and guidance.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Windows service in production?
On 8/15/11 9:32 PM, snorble wrote: > Anyone know of a Python application running as a Windows service in > production? I'm planning a network monitoring application that runs as > a service and reports back to the central server. Sort of a heartbeat > type agent to assist with "this server is down, go check on it" type > situations. > > If using Visual Studio and C# is the more reliable way, then I'll go > that route. I love Python, but everything I read about Python services > seems to have workarounds ahoy for various situations (or maybe that's > just Windows services in general?). And there seem to be multiple > layers of workarounds, since it takes py2exe (or similar) and there > are numerous workarounds required there, depending on which libraries > and functionality are being used. Overall, reading about Windows > services in Python is not exactly a confidence inspiring experience. > If I knew of a reference example of something reliably running in > production, I'd feel better than copying and pasting some code from a > guy's blog. Belatedly: I run a few quite major windows services which are installed at various customer sites in production, and we have no issues with it being a windows service. I basically only ever ran into two problems: 1. The lack of a console. Your service flat out /does not have/ a console, which is a slightly weird state to be in: writing to sys.stdout will fail. A print statement left in can crash things up -- even if in third-party code. Now, once you realize this is there, its easy to "fix". I end up doing something like this very early on in processing: class FakeFile: def __init__(self, fp): self._fp = fp def write(self, data): try: self._fp.write(data) except: pass # repeat with flush() sys.stdout = FakeFile(sys.stdout) sys.stderr = FakeFile(sys.stderr) That way it'll run from a regular terminal fine and write out fine, but if any stray attempts to print are left in, things will pass through fine when its running as a service. 2. Importing modules with the same names as dlls in system32 can go awry. I don't know if this is still there, I last touched this part of our code a long, long, long time ago: but my service does some manual PATH / PYTHONHOME / PYTHONPATH fiddling to take care of it. Its easy to do. It worked fine, and was stable and once going, everything worked fine. Ultimately, I have since abandoned running things as a real service directly, and wrote a "Metaservice" application we use in our company instead. It runs as a service, and executes any random series of programs beneath it, creating JOB's for each so any subprocesses of they launch all get killed together cleanly, and handling dependencies via between them through various means, and stuff like that. I just got tired of dealing with windows stuff, so. :) -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: try... except with unknown error types
On 8/19/11 12:09 PM, Yingjie Lin wrote: > try: > response = urlopen(urljoin(uri1, uri2)) > except urllib2.HTTPError: > print "URL does not exist!" > > Though "urllib2.HTTPError" is the error type reported by Python, Python > doesn't recognize it as an error type name. > I tried using "HTTPError" alone too, but that's not recognized either. Exceptions are objects like any other, and they are defined in specific places. Only the standard ones are available everywhere; things like IndexError and AttributeError. See the 'exceptions' module for the standard ones. Everything else, you have to 'grab' the object from where it lives -- in this case, in urllib2. > Does anyone know what error type I should put after the except statement? or > even better: is there a way not to specify > the error types? Thank you. You can use a "bare except", like so: try: ... except: ... But avoid it, if you can. Or at least, don't let it become habit-forming: for networking code and interaction with external things, I usually have a bare-except as a final fallback, after trying other more specific things-- but only as a last resort. FWIW, the error hierarchy of url fetching is more then a little bit annoying. My own _request object I end up using for one of our services catches, in order: try: ... except urllib2.HTTPError: except urllib2.URLError: except httplib.BadStatusLine: except httplib.HTTPException: except socket.timeout: except: With each case logging and handling the error in a bit of a different way. (Though most, eventually, resulting in the request being retried -- all in the name of a mandate that this particular bit of code must not, under any circumstances, not ultimately work. Even going so far as to start having hour long waits between retries until the other side is finally up :P) -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1")
On 8/21/11 12:53 PM, Laurent wrote: > >> With 64 bit 3.2.2 on my Win 7 Pentium, the difference was 4% and with >> floats (0.0 and 1.0), 6% > > For floats it is understandable. But for integers, seriously, 4% is a lot. I > would never have thought an interpreter would have differences like this in > syntax for something as fundamental as adding 1. Its, seriously, not even kind of a lot at all. Percentages without context are meaningless: its 4% slower, sure -- but that is 4% of an incredibly small probably constant-time amount of time. Picking "i += 1" over "i = i + 1" based on one being 4% slower is sorta kinda crazy. The difference in speed is probably related to churn and cache as much as anything else (its not as consistent on my machine, for example): or the ceval loop doing a few more case-tests between them as others have mentioned. All in all, if 4% of a nanomicrofraction of a chunk of time is that meaningful, you're probably best served not using Python. :) That said: my advice is always to avoid += like a plague. It is magic and impossible to predict without intimate knowledge of exactly what's on the left-side. i += 1 n += x Those two things look very similar, but they may do -completely- different things depending on just what "n" is. It may or may not do something that is like: n = n + x Or, it may do something that's more akin to n.extend(x) n = n Those aren't even kind of equivalent actions. And things get more complicated if 'n' is say, n[0] (especially if something goes wrong between the extend and the rebinding). Python's usually all explicit and pretty well-defined in how its basic syntax and behaviors operate, and you usually don't really have to know details about how a data-type works to predict exactly what it's doing: in fact, its often beneficial to not pay too much attention to such details, and just assume the data type will work approximately as you'd expect. That way people can slip something-something to you and wink and say of /course/ its a dict, darling. Try it, you'll like it, okay? This sorta thing is encouraged, but it kinda depends on trusting objects to behave a certain way and for things to be predictable in both how they work and how they fail. With "i = i + 1", I know that generally speaking, my "i" is being assigned a new object and that's that, no matter what type "i" is. (Okay: I do know that you could modify __add__ to do something underhanded here, tweaking internal state and then returning self. People going out of their way to behave unpredictably is not my objection: supposedly easy and straight-forward normal Python-fu being inherently unpredictable is). For example: I just /know/ that it doesn't matter who or what may have their own binding to that object before I go and increment it, they won't be affected and everything just will work fine. With augmented assignment, I can't be sure of that. Now, while I admit, you generally do have to keep track in your head of which of your data-types are mutable vs immutable and take care with sharing mutables, the fact that "n += x" is described and generally thought of as merely syntactical sugar for: n = n + x ... lets one easily think that this should be entirely safe, even with mutable objects, because if += were merely syntactical sugar, it would be. But its not! Because += is wiggly. It can do more then one entirely different kind of behavior. Anyways. I've been kinda annoyed at augmented assignment for years now :P -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1")
On 8/21/11 9:14 PM, Steven D'Aprano wrote: >> That said: my advice is always to avoid += like a plague. It is magic >> and impossible to predict without intimate knowledge of exactly what's >> on the left-side. >> >>i += 1 >>n += x >> >> Those two things look very similar, but they may do -completely- >> different things depending on just what "n" is. > > Technically, the *exact same criticism* can be applied to: > > n = n + x > > since either n or x could override __add__ or __radd__ and do anything it > bloody well likes. Including in-place modification of *either* argument > (where possible). I know: I addressed that. :P See, you know I addressed that, because: > [...] >> With "i = i + 1", I know that generally speaking, my "i" is being >> assigned a new object and that's that, no matter what type "i" is. >> (Okay: I do know that you could modify __add__ to do something >> underhanded here, tweaking internal state and then returning self. > > What makes you think that's underhanded? You quoted me addressing that very fact, and responded! :) Its underhanded outside of narrow, well-defined situations such as ORM's and the like where they're doing interesting and novel things with the object model. Underhanded doesn't mean there's no reason one should ever do it, but its very much an unusual thing and objects that do things like that should NOT freely interact with general Python objects: very surprising behavior will result. > To my mind, __add__ modifying self as a side-effect is unusual, but apart > from breaking the general rule of thumb to avoid side-effects, not > particularly evil. (But I would accept this is a code smell.) I didn't really say its evil, just that its underhanded: that's like, sketchy, not evil. :) There's good reasons to do it on occasion, but if an object does something like that then that is a very special kind of object and when using it, you need to be very aware of its unusual semantics. Having objects like that is fine. However, for the /language/ to have unusual (and unpredictable, from something of a distance at least) semantics, rubs me very much the wrong way. >> People going out of their way to behave unpredictably is not my >> objection: supposedly easy and straight-forward normal Python-fu being >> inherently unpredictable is). >> >> For example: I just /know/ that it doesn't matter who or what may have >> their own binding to that object before I go and increment it, they >> won't be affected and everything just will work fine. > > But you can't /know/ that at all, unless you know that the object > isn't "underhanded" (however you define that!). And given some arbitrary > object, how can you know that? I CAN know it with sufficient certainty that I can rely on it, and if I get messed up on it-- its never happened yet-- then I can fire someone or get a new library, after staring at an odd traceback and scratching my head for a minute. Python has very soft rules, I know that. Objects /can/ do all kinds of crazy things. I'm okay with that. But I can rely on certain behaviors being consistent: the basic behavior of the language is very straight-forward. It has hooks where you can do lots of Special stuff, and if objects are Special, they're described as Special. ORM's have a lot of Special objects, for example. That's fine: when messing with ORM objects, I know I have to take care with the operators I use against them, because I know I'm not using a /usual/ Python object. SQLAlchemy for example. This is not a criticism of SQLAlchemy: having magic objects lets it construct SQL in ways that are vastly easier then if they stuck to more regularly behaving objects. But, += is Python itself adding an unpredictable behavior into the core language, with its own base types behaving The *exact same criticism* can NOT be applied to n = n + x Because my criticism isn't about one choosing to do crazy stuff with the object model. I've never advocated Python be strict about rules. But for Python, all by itself, with nothing but built-in and basic types, to have a situation where: a = a + b a += b ... does two very distinctly different actions, even if in many or even most circumstances the end-result is probably the same and probably fine, is my criticism. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1")
On 8/21/11 9:37 PM, Stephen Hansen wrote: > But, += is Python itself adding an unpredictable behavior into the core > language, with its own base types behaving ... very differently to fundamental, basic appearing operators. Editing fail on my part. Similarly: > But for Python, all by itself, with nothing but built-in and basic > types, to have a situation where: > > a = a + b > a += b ... would be clearer if the second example were "x += y". > ... does two very distinctly different actions, even if in many or > even most circumstances the end-result is probably the same and probably > fine, is my criticism. > -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: questions (& answers) about object, type, builtin types, class, metaclass and __getattribute__
of __*__ attributes, which by and large bypass such hooks, as the CPython internals is calling those functions directly on the class instances themselves. > 2) Is the following algorithm describing __getattribute__ correct This is broadly incorrect because it implies that __getattribute__ is an internal protocol that Python uses for attribute-resolution, which is simply untrue. Its a method you may define on new style classes which, if present, is called when an attribute is requested from an object (but NOT in the case of __*__ methods, usually, which are obtained internally by a direct struct access, i.e., mytype->tp_new gets mytype.__new__). If no such attribute exists, it goes along to do its default attribute-resolution process, including the descriptor protocol and dict checking and the like. __getattribute__ is an optional hook that you can define which allows a Python class to /bypass/ the normal mechanism for normal (non-magic) attributes. If you're asking what the normal mechanism is, its broadly: - Check to see if the object's base-classes have a descriptor of the attributes name. If so, call that. - Check to see if the object's instance dict has an attribute of the name. If so, return that. - Check to see if the object's base-classes have an attribute of the name. More or less. I think. I'm probably leaving something out there. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Error when deleting and reimporting subpackages
On 8/22/11 11:51 AM, Matthew Brett wrote: > Hi, > > I recently ran into this behavior: > >>>> import sys >>>> import apkg.subpkg >>>> del sys.modules['apkg'] >>>> import apkg.subpkg as subpkg > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'module' object has no attribute 'subpkg' > > where 'apkg' and 'subpkg' comprise empty __init__.py files to simplify the > example. > > It appears then, that importing a subpackage, then deleting the containing > package from sys.modules, orphans the subpackage in an unfixable state. > > I ran into this because the nose testing framework does exactly this kind of > thing when loading test modules, causing some very confusing errors and > failures. > > Is this behavior expected? Yes. Doing an import of "apkg.subpkg" results in more then just "test1" being cached in sys.modules, and you're removing half of that so leaving Python in a weird state. You also want to del sys.modules["apkg.subpkg"], then you'll be able to re-import apkg.subpkg. I.e: Python 2.7.1 (r271:86882M, Nov 30 2010, 10:35:34) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> import test1.test2 >>> del sys.modules['test1'] >>> del sys.modules['test1.test2'] >>> import test1.test2 as test2 >>> -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Error when deleting and reimporting subpackages
On Mon, Aug 22, 2011 at 12:14 PM, Matthew Brett wrote:
> Yes, sorry, I should have mentioned that I explored these kind of
> variations.
>
> I think I see that there isn't an obvious way for del sys.modules['apkg']
> to know to delete or modify 'apkg.subpkg', because sys.modules is just a
> dict.
>
> However, I could imagine the import machinery being able to recognize that
> 'apkg.subpkg' is broken, and re-import it without error.
> Is that reasonable?
>
Not really, no. Despite the fact that you can sorta do it, and that there's
this "reload" function, Python doesn't really support reloading of modules /
code. If you want to do it, you basically have to go out and _do_ it
yourself.
If you muck about in sys.modules, you need to do so completely. Python and
the import stuff won't really do anything to help you (though it won't go
out of its way to hinder you, either).
Something like:
def remove_module(name):
for mod in sys.modules.keys():
if mod == name or name.startswith(name + "."):
del sys.modules[mod]
Then remove_module("apkg") may work for you. (Code above not tested at all,
not even kinda)
--Ix
--
http://mail.python.org/mailman/listinfo/python-list
Re: Windows No-Install Distribution?
On 8/23/11 8:29 AM, Eric Lemings wrote: > I would like to create/find a Python 3.x distribution that can be > redeployed simply by copying a directory of required files; i.e. Just take the default installer, install it, and then check the Python directory: does it have the python DLL? If not, go look into the system32 directory, grab it, drop it in the Python directory. (If you installed for all-users this will happen, Now copy/zip/whatever that Python directory to another machine where it was not installed. It'll work fine. You'll have to explicitly provide the path to the Python.exe of course; you can't just double-click on a .py or run 'python blah.py', but if your shortcuts/whatever all do C:\Where\You\Installed\Python.exe, everything should just work. We do that at work and never run into any trouble. (We actually provide a MSI but only for convenience of customers who want to auto-install via Group Policy). In most situations, Python's good at "finding itself", i.e. where the python.exe is actually located -- and it boostraps the location of everything else based on that. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Run time default arguments
On 8/25/11 1:54 PM, t...@thsu.org wrote:
> On Aug 25, 10:35 am, Arnaud Delobelle wrote:
>> You're close to the usual idiom:
>>
>> def doSomething(debug=None):
>> if debug is None:
>> debug = defaults['debug']
>> ...
>>
>> Note the use of 'is' rather than '=='
>> HTH
>
> Hmm, from what you are saying, it seems like there's no elegant way to
> handle run time defaults for function arguments,
Well, elegance is in the eye of the beholder: and the above idiom is
generally considered elegant in Python, more or less. (The global nature
of 'defaults' being a question)
> meaning that I should
> probably write a sql-esc coalesce function to keep my code cleaner. I
> take it that most people who run into this situation do this?
>
> def coalesce(*args):
> for a in args:
> if a is not None:
> return a
> return None
>
> def doSomething(debug=None):
> debug = coalesce(debug,defaults['debug'])
> # blah blah blah
Er, I'd say that most people don't do that, no. I'd guess that most do
something more along the lines of "if debug is None: debug = default" as
Arnaud said. Its very common Pythonic code.
In fact, I'm not quite sure what you think you're getting out of that
coalesce function. "Return the first argument that is not None, or
return None"? That's a kind of odd thing to do, I think. In Python at
least.
Why not just:
debug = defaults.get("debug", None)
(Strictly speaking, providing None to get is not needed, but I always
feel odd leaving it off.)
That's generally how I spell it when I need to do run time defaults.
--
Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/
signature.asc
Description: OpenPGP digital signature
--
http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
On 8/27/11 3:21 PM, Emile van Sebille wrote: > On 8/27/2011 2:57 PM Ben Finney said... >> Emile van Sebille writes: >> >>> Code is first and foremost written to be executed. >> > > >> “Programs must be written for people to read, and only >> incidentally for >> machines to execute.” >> —Abelson& Sussman, _Structure and Interpretation of Computer >> Programs_ >> > > That's certainly self-fulfilling -- code that doesn't execute will need > to be read to be understood, and to be fixed so that it does run. Nobody > cares about code not intended to be executed. Pretty it up as much as > you have free time to do so to enlighten your intended audience. Er, you're interpreting the quote... way overboard. No one's talking about code that isn't intended to be executed, I don't think; the quote includes, "and only incidentally for machines to execute." That's still the there, and its still important. It should just not be the prime concern while actually writing the code. The code has to actually do something. If not, obviously you'll have to change it. The Pythonic emphasis on doing readable, pretty code isn't JUST about making code that just looks good; its not merely an aesthetic that the community endorses. And although people often tout the very valid reason why readability counts-- that code is often read more then written, and that coming back to a chunk of code 6 months later and being able to understand fully what its doing is very important... that's not the only reason readability counts. Readable, pretty, elegantly crafted code is also far more likely to be *correct* code. However, this: > Code that runs from the offset may not ever again need to be read, so > the only audience will ever be the processor. > > I find it much to easy to waste enormous amounts of time prettying up > code that works. Pretty it up when it doesn't -- that's the code that > needs the attention. ... seems to me to be a rather significant self-fulfilling prophecy in its own right. The chances that the code does what its supposed to do, accurately, and without any bugs, goes down in my experience quite significantly the farther away from "pretty" it is. If you code some crazy, overly clever, poorly organized, messy chunk of something that /works/ -- that's fine and dandy. But unless you have some /seriously/ comprehensive test coverage then the chances that you can eyeball it and be sure it doesn't have some subtle bugs that will call you back to fix it later, is pretty low. In my experience. Its not that pretty code is bug-free, but code which is easily read and understood is vastly more likely to be functioning correctly and reliably. Also... it just does not take that much time to make "pretty code". It really doesn't. The entire idea that its hard, time-consuming, effort-draining or difficult to make code clean and "pretty" from the get-go is just wrong. You don't need to do a major "prettying up" stage after the fact. Sure, sometimes refactoring would greatly help a body of code as it evolves, but you can do that as it becomes beneficial for maintenance reasons and not just for pretty's sake. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Arrange files according to a text file
On 8/27/11 11:06 AM, Emile van Sebille wrote: > from difflib import SequenceMatcher as SM > > def ignore(x): > return x in ' ,.' > > for filename in filenames: > ratios = [SM(ignore,filename,username).ratio() for username in > usernames] > best = max(ratios) > owner = usernames[ratios.index(best)] > print filename,":",owner It amazes me that I can still find a surprising new tool in the stdlib after all these years. Neat. /pinboards -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Understanding .pth in site-packages
On 8/27/11 3:41 PM, Josh English wrote: > I have .egg files in my system path. The Egg file created by my setup script > doesn't include anything but the introductory text. If I open other eggs I > see the zipped data, but not for my own files. Sounds like your setup.py isn't actually including your source. > > Is having a zipped egg file any faster than a regular package? or does it > just prevent people from seeing the code? IIUC, its nominally very slightly faster to use an egg, because it can skip a lot of filesystem calls. But I've only heard that and can't completely confirm it (internal testing at my day job did not conclusively support this, but our environments are uniquely weird). But that speed boost (if even true) isn't really the point of eggs-as-files -- eggs are just easy to deal with as files is all. They don't prevent people from seeing the code*, they're just regular zip files and can be unzipped fine. I almost always install unzip my eggs on a developer machine, because I inevitably want to go poke inside and see what's actually going on. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ * Although you can make an egg and then go and remove all the .PY files from it, and leave just the compiled .PYC files, and Python will load it fine. At the day job, that's what we do. But, you have to be aware that this ties the egg to a specific version of Python, and its not difficult for someone industrious to disassemble and/or decompile the PYC back to effectively equivalent PY files to edit away if they want. signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Interact with SQL Database using Python 2.4 or lower
On 8/28/11 9:49 PM, Sascha wrote: > My Problem: the webhost runs Python 2.4 so I cannot communicate > with(query or modify) my SQLite3 database. The webhost will not allow > me to install my own version of python or upload modules unless I > upgrade to VPS. Get a new webhost. Seriously. This is a seriously absurd requirement -- it goes past absurd into malicious incompetence, frankly. Not being able to upload your own modules? There has to be another option. Personally, I'm a major fan of Webfaction -- from price to plans to what's supported to actual effectiveness of their tech support. But I don't know if they have a warehouse in Australia, if their latency with any of their various data centers is suitable for you. Maybe, maybe not -- but there /has/ to be a better option then this site... Good hosts these days are not all that uncommon and are fairly competitive. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Interact with SQL Database using Python 2.4 or lower
On 8/28/11 10:23 PM, Chris Angelico wrote: > On Mon, Aug 29, 2011 at 3:09 PM, Stephen Hansen > wrote: >> Get a new webhost. ... >> >> But I don't know if they have a warehouse in Australia, if their latency >> with any of their various data centers is suitable for you. Maybe, maybe >> not -- but there /has/ to be a better option then this site... Good >> hosts these days are not all that uncommon and are fairly competitive. > > Having burnt my fingers with a couple of web hosts, and finally > decided to host my own web site, I have one major piece of advice > regarding this: > > Get a personal recommendation. This is good advice, though with prices as they are in many cases -- provided you don't need to start out immediately solid and have some development wiggle-room -- its not a bad thing to experiment. Just don't get too tied to a certain host until you feel them out. Sending them emails with detailed questions before you sign up is a good thing, for example. Good hosts will respond with detailed, specific answers, from real people. Bad hosts will point you to a vague website or stock reply. Real people, reading your real questions, and answering with real answers is a major, major sign of the kind of company I want to do business with. (Bonus points if they respond to complex, technical and legal questions with specific answers within 24 hours -- bonus++ points if the non-legal questions usually get responses in 1, at absurd times even). > BTW, don't take the fact that I host my own site as a negative > recommendation for every hosting company out there. My requirements > are somewhat unusual - I want to host a MUD, not just a web site. > Hosts that let you do THAT much are usually quite expensive :) Hehe, I don't want to get overly advertising in my comments (so I'm so not including a referrer link anywhere), but amusingly enough, my first Webfaction account was signed up for the MUD reason. They officially don't give a rats ass what you run in the background, provided you're just not using more then your RAM allotment and that its not spiking the CPU to a point that affects the rest of the system. I have one account that runs a mud, one that does often semi-significant background processing regularly via cron jobs (which they mailed me about once when it got out of hand-- but they were entirely professional and nice about it, and I fixed it with some controls so it behaved in a more friendly way towards the rest of the system), and one for my personal site where I run an IRC bouncer on, and all is cool. (Why three accounts? One is paid for by a client, one half by me, one by me -- it was just easier, and no way it all would fit under a single plan) Anyways. I shall not further ramble as a satisfied-customer. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Web hosting when you need to install your own modules (was Re: Interact with SQL Database using Python 2.4 or lower)
On 8/28/11 10:52 PM, Chris Angelico wrote: > * DNS record changes required a support ticket (this was shared web > hosting, so I didn't have control over the BIND files - that's what > they said, anyway) Ouch: I never let a webhost near my domain names. I was burned somewhere around that a long time ago, and now always keep the jobs of managing my DNS record and hosting my sites /totally/ separate. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Threads in Python
On 9/1/11 2:45 PM, George Kovoor wrote: > Hi, > Why doesn't python threads show an associated PID? On spawning python > threads using the threading module I can only see the main thread's pid on > using top or ps unix command, no subprocesses are displayed. In otherwords > top or ps in not aware of any subprocesses created using threading module in > python. > > Whereas in Java , creating threads will result in separate pid , these > subprocesses can be listed using top or ps. Java threads get mapped to the > cores in the system. I think you're confused about what threads and subprocesses are. They are completely different mechanisms for concurrent code. Threads never show up on top or ps, in any language ... or the language isn't offering threads. I don't know Java, so I can't really comment on it much, but it may be misusing the 'thread' word, but I somehow doubt it. I suspect you're just mistaken about what Java is offering. Threads are separate operating ..er, chains-of-instructions within a single process... Notably with threads, they share the same address space so you can easily share objects amongst threads, without any copying and with no overhead ... Also notably with threads, this can be dangerous, so you often end up wrapping lots of locks around those shared objects and have to take extreme care to make sure nothing goes haywire. Subprocesses are different; they are a whole, separate process with its own address space and no shared memory (unless you go out of your way to do it manually). Heck, each subprocess can have any number of threads. Anything you want to share between them you have to take special care to set up and do -- multiprocessing exists to make this easier and make subprocesses easier to use, like threads are. They're very distinct. Threads are a lot more lightweight and start up a lot faster, but doing multithreaded programming right with any sort of shared objects is really, really, really hard to get right. Some say you can't. But, in Python, only one thread actually ever executes actual Python code at any given time. This does not actually make threading useless as some people claim; if you're making a lot of calls into C-code, for instance, the lock gets released while said C-code runs and other Python code can continue along. Its just not useful if your program is CPU-bound and wants to take advantage of multiple cores. But there's lots of other reasons to go concurrent. But if you do need lots of CPU power, multiprocessing lets you chew up multiple cores and does so /fairly/ easily. Communication between the processes can be expensive depending on the types of objects you need to pass back and forth, but it depends on how you're designing your app. They're just different ways of achieving concurrency, and the two primary ways Python provides. (Greenlets is another, available as a third-party module; Twisted's asynch dispatching isn't really exactly concurrency, but it does a better job then concurrency does for some operations; someone's always working on coroutines in some fashion or another, which is another kind of concurrency.) Lots of different ways to go concurrent, depending on your needs. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Detecting Ctrl-Alt-Del in Windows
On 9/1/11 8:52 AM, Den wrote: > Obviously, this is a windows-based question. I know that Ctrl-Alt-Del > is handled deep inside the OS, and I'm not trying to interrupt that. > But is there some way to detect that a C-A-D has been pressed? IIUC, by definition, Ctrl-Alt-Delete can't be responded to in any way. Its the entire point of the sequence: when you type it you can be entirely, totally, 100% certain that what happens next is the true OS and not any app faking things. That's why you have to hit CAD to get to the login form in some versions of Windows. The whole point of that secure sequence is that the OS and only the OS responds. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] allow line break at operators
On 9/3/11 3:33 AM, Yingjie Lan wrote: > but at least we can have such 'freedom' :) Freedom is not and never has been, IMHO, a virtue or goal or even desire in Python. Where it occurs, it is at best a happy coincidence, and even if that happy coincidence happens often, it is not a design feature, IMHO. Simplicity and readability are virtues in Python. Freedom is even declared a vice to be avoided by the Zen, that holy document which defines all things Pythonic in clear and unambiguously absolute terms*. Looking over this whole thread at the various examples -- they add complication (a vice!). Complication to the parser, complication to the language itself and worse, understanding of code (as your head has to parse things too), all for what? So you don't have to use parens, which quite explicitly (another virtue!) do the job, to wrap around a long expression? Escaping newlines is arguably a bit on the ugly side (a vice!), so maybe the proposal has a little weight there, but since you can just avoid that by using parens, that's pretty much nullified. (Since it is also a virtue to offer only the Dutch way of doing things -- at least without hiding the alternatives in modules with a little bit of shame -- and this is clearly a case of the Dutch liking limited use of grouping parens). There just isn't even vaguely enough justification based on Python-virtues (readability, simplicity, explicitness, things like that) to even kind of make it worth the complication. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ * Obvious exaggeration :P signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with simple OOP Python question
On 9/4/11 11:47 PM, Kristofer Tengström wrote: > Hi, I'm having trouble creating objects that in turn can have custom > objects as variables. The code looks like this: > > - > > class A: > sub = dict() You are sharing this single "sub" dictionary with all instances of your A class. If you want to define instance-specific attributes, define them in the __init__ method, like so: class A: def __init__(self): self.sub = dict() def sub_add(self, cls): obj = cls() self.sub[obj.id] = obj -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
builtin max() and weak ordering
The CPython builtins min() and max() both return the first satisfactory object
found. This behaviour is undocumented. Examining the source in bltinmodule.c
shows that min() and max() both result in a call to min_max() with Py_LT and
Py_GT passed respectively.
The behaviour of min() is correct. But with weak orderings of equivalent
objects, surely max() should be using Py_GE ? (the converse of Py_LT). Should I
be reporting a bug, submitting a patch, making feature request or suggesting a
documentation update ?
For a more mathematical consideration (not casual reading):
Stepanov, Alexander and Paul McJones. 2009. Elements of Programming. Addison
Wesley. Pages 52-53
The code below demonstrates the issue. Using the total key gives the correct
result. Using the weak key returns the "incorrect" result. Tested with Python
2.7.1 and 3.1.2 (applies to 3.2)
Stephen Evans
from __future__ import print_function
from operator import attrgetter
class Pair():
def __init__(self, m0, m1):
self.m0, self.m1 = m0, m1
# rich comparisons are not used
def __lt__(self, other): raise NotImplementedError
def __le__(self, other): raise NotImplementedError
def __eq__(self, other): raise NotImplementedError
def __ne__(self, other): raise NotImplementedError
def __gt__(self, other): raise NotImplementedError
def __ge__(self, other): raise NotImplementedError
def __repr__(self):
"""repr() as a tuple"""
return repr((self.m0, self.m1))
@property
def total(self):
return (self.m0, self.m1)
@property
def weak(self):
return self.m0
def test():
"""
demonstrate the failure of the builtin max() to respect the original order
of equivalent objects.
"""
r = [ (0, 1), (0, 2) ]
r = [ Pair(*p) for p in r ]
# verify total and weak ordering
assert r == sorted(r, key=attrgetter('weak')) == sorted(r,
key=attrgetter('total'))
print(r)
# from the sorted list
print(r[0], r[-1])
# using total ordering
print(min(r, key=attrgetter('total')), max(r, key=attrgetter('total')))
# using weak ordering, builtin_min and builtin_max functions in
bltinmodule.c
# min works as expected using Py_LT
# max uses Py_GT rather than the converse of Py_LT (which would be Py_GE)
print(min(r, key=attrgetter('weak')), max(r, key=attrgetter('weak')))
test()
--
http://mail.python.org/mailman/listinfo/python-list
Python programming language vulnerabilities
I chair ISO/IEC/JTC1/SC22/WG23 Programming Language Vulnerabilities. We publish an international technical report, ISO IEC TR 24772 Guide to avoiding programming language vulnerabilities through language selection use. Annex D in this document addresses vulnerabilities in Python. This document is freely available from ISO and IEC. We are updating this technical report, adding a few vulnerabilities and updating language applicability as programming languages evolve. We are also subdividing the document by making the language-specific annexes each their own technical report. For the Python Part, the major portions are written, but we have about 6 potential vulnerabilities left to complete. We need help in finishing the Python TR. We are looking for a few Python experts that have experience in implementing Python language systems, or experts in implementing significant systems in Python (for technical level, persons that provide technical supervision to implementers, or that write and maintain organizational Python coding standards. If you are interested in helping, please reply to this posting. Thank you Stephen Michell Convenor, ISO/IEC/JTC 1/SC 22/WG 23 Programming Language Vulnerabilities -- https://mail.python.org/mailman/listinfo/python-list
Re: Python programming language vulnerabilities
My apologies. I maintain that website. There should have been no broken links. I will fix that. The previous version of TR 24772 had annexes for language-specific material. We have split those out, so the main document (Tr 24772-1) only has language independent material. The last Python document is N0702 at open-std.org/sc22/wg23//docs/documents.html. This document was one that Serihy could not access. That link is fixed, so it can be accessed now. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python programming language vulnerabilities
CORRECTION. My sincere apologies to anyone that tried the link that I posted. The actual link is www.open-std.org/jtc1/sc22/wg23 follow the link to documents, or go directly there via www.open-std.org/jtc1/sc22/wg23/docs/documents.html I was informed that there are some broken links to documents. I believe that they are all fixed now. -- https://mail.python.org/mailman/listinfo/python-list
Re: integer copy
ast, For what it's worth, After a = 5 b = 5 afloat = float(a) bfloat = float(b) afloat is bfloat returns False. Stephen Tucker. On Fri, Oct 20, 2017 at 9:58 AM, ast wrote: > > "ast" a écrit dans le message de > news:59e9b419$0$3602$426a7...@news.free.fr... > > Neither works for large integers which is > even more disturbing > > a = 6555443 > > b = copy.copy(a) > a is b > > True > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Printing Unicode strings in a list
Hi PythonList Members, Consider the following log from a run of IDLE: == Python 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. >>> print (u"\u2551") ║ >>> print ([u"\u2551"]) [u'\u2551'] >>> == Yes, I am still using Python 2.x - I have good reasons for doing so and will be moving to Python 3.x in due course. I have the following questions arising from the log: 1. Why does the second print statement not produce [ ║] or ["║"] ? 2. Should the second print statement produce [ ║] or ["║"] ? 3. Given that I want to print a list of Unicode strings so that their characters are displayed (instead of their Unicode codepoint definitions), is there a more Pythonic way of doing it than concatenating them into a single string and printing that? 4. Does Python 3.x exhibit the same behaviour as Python 2.x in this respect? Thanks in anticipation. Stephen Tucker. -- https://mail.python.org/mailman/listinfo/python-list
Re: Printing Unicode strings in a list
To Cameron Simpson, Thanks for your in-depth and helpful reply. I have noted it and will be giving it close attention when I can. The main reason why I am still using Python 2.x is that my colleagues are still using a GIS system that has a Python programmer's interface - and that interface uses Python 2.x. The team are moving to an updated version of the system whose Python interface is Python 3.x. However, I am expecting to retire over the next 8 months or so, so I do not need to be concerned with Python 3.x - my successor will be doing that. Stephen. On Thu, Apr 28, 2022 at 2:07 PM Cameron Simpson wrote: > On 28Apr2022 12:32, Stephen Tucker wrote: > >Consider the following log from a run of IDLE: > >== > > > >Python 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)] > >on win32 > >Type "copyright", "credits" or "license()" for more information. > >>>> print (u"\u2551") > >║ > >>>> print ([u"\u2551"]) > >[u'\u2551'] > >>>> > >== > > > >Yes, I am still using Python 2.x - I have good reasons for doing so and > >will be moving to Python 3.x in due course. > > Love to hear those reasons. Not suggesting that they are invalid. > > >I have the following questions arising from the log: > >1. Why does the second print statement not produce [ ║] or ["║"] ? > > Because print() prints the str() or each of its arguments, and str() of > a list if the same as its repr(), which is a list of the repr()s of > every item in the list. Repr of a Unicode string looks like what you > have in Python 2. > > >2. Should the second print statement produce [ ║] or ["║"] ? > > Well, to me its behaviour is correct. Do you _want_ to get your Unicode > glyph? in quotes? That is up to you. But consider: what would be sane > output if the list contained the string "], [3," ? > > >3. Given that I want to print a list of Unicode strings so that their > >characters are displayed (instead of their Unicode codepoint definitions), > >is there a more Pythonic way of doing it than concatenating them into a > >single string and printing that? > > You could print them with empty separators: > > print(s1, s2, .., sep='') > > To do that in Python 2 you need to: > > from __future__ import print_function > > at the top of your Python file. Then you've have a Python 3 string print > function. In Python 2, pint is normally a statement and you don't need > the brackets: > > print u"\u2551" > > but print() is genuinely better as a function anyway. > > >4. Does Python 3.x exhibit the same behaviour as Python 2.x in this > respect? > > Broadly yes, except that all strings are Unicode strings and we don't > bothing with the leading "u" prefix. > > Cheers, > Cameron Simpson > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Discerning "Run Environment"
Hi, I am a Windows 10 user still using Python 2.x (for good reasons, I assure you.) I have a Python 2.x module that I would like to be able to use in a variety of Python 2.x programs. The module outputs characters to the user that are only available in the Unicode character set. I have found that the selection of characters in that set that are available to my software depends on whether, for example, the program is being run during an IDLE session or at a Command Prompt. I am therefore needing to include logic in this module that (a) enables it to output appropriate characters depending on whether it is being run during an IDLE session or at a command prompt, and (b) enables it to discern which of these two "run environments" it is running in. Goal (a) is achieved easily by using string.replace to replace unavailable characters with available ones where necessary. The best way I have found so far to achieve goal (b) is to use sys.modules and ascertain whether any modules contain the string "idlelib". If they do, that I assume that the software is being run in an IDLE session. I suspect that there is a more Pythonic (and reliable?) way of achieving goal (b). Can anyone please tell me if there is, and, if there is, what it is? Thanks. Stephen Tucker. -- https://mail.python.org/mailman/listinfo/python-list
Re: on GNU EMACS's python-mode, loading entire buffer
On Sun, 04 Sep 2022 16:47:07 -0300 Meredith Montgomery wrote: > Meredith Montgomery writes: > >> Meredith Montgomery writes: >> >> [...] >> >>> I would also be interested in a command that restarts the REPL afresh >>> and reloads my buffer --- sort of like keyboard's [F5] of the IDLE. >> >> A partial solution for this is the following procedure. >> >> (defun python-revert-and-send-buffer-to-repl () >> "Revert current buffer and sends it to the Python REPL." >> (interactive) >> (revert-buffer "ignore-auto-no" "no-confirm") >> (python-shell-send-buffer)) >> >> We can map this to the F5-key and that improves things. But a restart >> of the REPL would be the ideal. (Sometimes we really want to start >> afresh. Sometimes. Most often we don't want that.) > > It's not easy to restart the REPL. You can send "quit()" to it and > invoke run-python again interactively by typing out one command after > another, but if you write a procedure such as this one below, it doesn't > work: it gives me the impression that there's a timing issue, that is, > perhaps the procedure is too fast and something happens before it > should. > > (defun python-save-send-buffer-to-repl () > (interactive) > (save-buffer) > (python-shell-send-string "quit()") > (run-python) > (python-shell-send-buffer) > (python-shell-switch-to-shell)) It does seem like a timing issue. This works for me: (defun python-save-send-buffer-to-repl () (interactive) (save-buffer) (python-shell-send-string "quit()") (sit-for 0.1) (run-python) (python-shell-send-buffer) (python-shell-switch-to-shell)) But if I decrease the wait to 0.05 it doesn't work. Steve Berman -- https://mail.python.org/mailman/listinfo/python-list
Are these good ideas?
Hi, I have two related issues I'd like comments on. Issue 1 - Global Values Some years ago, I had a situation where (a) I could supply low-level functions that carry out tasks, (b) I needed those functions to communicate with each other, but (c) I had no access to the module that invoked my functions. In order to achieve this, I hit on the idea that I also supply a module that I describe as a "global values" module. This module … (i) … defines the values that the functions use to communicate with each other; (ii) … is the subject of an import statement in each of my functions; (iii) … initialises its values at the start of each run (since the import only carries out an actual import once per session); (iv) … acts as a repository for the values thereafter. This solution works well. Given that I am not particularly concerned about efficiency, (1) Is this a reasonable way to achieve this goal? (2) Do you know of any better ways? Issue 2 - Passed Parameters I am now facing another situation where I am wanting to pass 6 or 7 parameters down through several layers of logic (function A calling function B calling ... ) and for results to be passed back. Having had the idea described above, I am considering using it again to save all the parameter-and-results passing. I see nothing wrong with doing that, but I may well be missing something! Comments, please! Stephen Tucker. -- https://mail.python.org/mailman/listinfo/python-list
file.read Method Documentation (Python 2.7.10)
Dear Python-list, Yes, I know that Python 2.x is no longer supported. I have found that the documentation for this method is misleading when the file being read is UTF-8-encoded: Instead of reading *size* bytes, the method reads *size *UTF-8 byte *sequences*. Has this error been corrected in the Python 3.x documentation? Stephen Tucker. -- https://mail.python.org/mailman/listinfo/python-list
Re: file.read Method Documentation (Python 2.7.10)
Chris - In the Python 2.7.10 documentation, I am referring to section 5. Built-in Types, subsection 5.9 File Objects. In that subsection, I have the following paragraph: file.read([*size*]) Read at most *size* bytes from the file (less if the read hits EOF before obtaining *size* bytes). If the *size* argument is negative or omitted, read all data until EOF is reached. The bytes are returned as a string object. An empty string is returned when EOF is encountered immediately. (For certain files, like ttys, it makes sense to continue reading after an EOF is hit.) Note that this method may call the underlying C function fread() more than once in an effort to acquire as close to *size* bytes as possible. Also note that when in non-blocking mode, less data than was requested may be returned, even if no *size* parameter was given. Note This function is simply a wrapper for the underlying fread() C function, and will behave the same in corner cases, such as whether the EOF value is cached. Stephen. On Mon, Jan 9, 2023 at 6:25 PM Chris Angelico wrote: > On Tue, 10 Jan 2023 at 01:36, Stephen Tucker > wrote: > > > > Dear Python-list, > > > > Yes, I know that Python 2.x is no longer supported. > > > > I have found that the documentation for this method is misleading when > the > > file being read is UTF-8-encoded: > > > >Instead of reading *size* bytes, the method reads *size *UTF-8 byte > > *sequences*. > > > > Has this error been corrected in the Python 3.x documentation? > > > > What documentation is this? The builtin 'file' type doesn't know > anything about encodings, and only ever returns bytes. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: file.read Method Documentation (Python 2.7.10)
Chris,
Thanks for your reply.
I hope the evidence below (taken from IDLE) clarifies my issue:
Stephen.
==
1. Create BOM.txt
-
>>> myfil = open ("BOM.txt", "wb")
>>> myfil.write ("\xef" + "\xbb" + "\xbf")
>>> myfil.close()
2. Input three bytes at once from BOM.txt and print them
>>> myfil = open ("BOM.txt", "rb")
>>> myBOM = myfil.read (3)
>>> myBOM
'\xef\xbb\xbf'
>>> myfil.close()
3. Input three bytes one at a time from BOM.txt and print them
--
>>> myfil = open ("BOM.txt", "rb")
>>> myBOM_1 = myfil.read (1)
>>> myBOM_2 = myfil.read (1)
>>> myBOM_3 = myfil.read (1)
>>> myBOM_1
'\xef'
>>> myBOM_2
'\xbb'
>>> myBOM_3
'\xbf'
>>> myfil.close()
4. Input three bytes at once from BOM.txt and print them
>>> import codecs
>>> myfil = codecs.open ("BOM.txt", mode="rb", encoding="UTF-8")
>>> myBOM = unicode (myfil.read (3))
>>> myBOM
u'\ufeff'
>>> myfil.close ()
5. Attempt to input three bytes one at a time from BOM.txt and print them
-
>>> myfil = codecs.open ("BOM.txt", mode="rb", encoding="UTF-8")
>>> myBOM_4 = myfil.read (1)
>>> myBOM_5 = myfil.read (1)
>>> myBOM_6 = myfil.read (1)
>>> myBOM_4
u'\ufeff'
>>> myBOM_5
u''
>>> myBOM_6
u''
>>> myfil.close()
Notes
A. The attempt at Part 5 actually inputs all three bytes when we ask it to
input just the first one!
B. The outcome from Part 5 shows that, actually, the request to input text
in Part 4 brought about a response from the program something like this:
Input the UTF-8-encoded character as the first "byte";
As expected, after reaching the end of the file, continue supplying an
empty string for each of the requested extra bytes.
==
On Wed, Jan 11, 2023 at 11:00 AM Chris Angelico wrote:
> On Wed, 11 Jan 2023 at 21:31, Stephen Tucker
> wrote:
> >
> > Chris -
> >
> > In the Python 2.7.10 documentation, I am referring to section 5.
> Built-in Types, subsection 5.9 File Objects.
> >
> > In that subsection, I have the following paragraph:
> >
> > file.read([size])
> >
> > Read at most size bytes from the file (less if the read hits EOF before
> obtaining size bytes). If the size argument is negative or omitted, read
> all data until EOF is reached. The bytes are returned as a string object.
> An empty string is returned when EOF is encountered immediately. (For
> certain files, like ttys, it makes sense to continue reading after an EOF
> is hit.) Note that this method may call the underlying C function fread()
> more than once in an effort to acquire as close to size bytes as possible.
> Also note that when in non-blocking mode, less data than was requested may
> be returned, even if no size parameter was given.
> >
>
> Yes, so it should be that number of bytes, which is what it does, isn't it?
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: file.read Method Documentation (Python 2.7.10)
Chris,
Thanks for this clarification.
I have not found documentation that disagrees with you. I simply observe
that the documentation that I have alluded to earlier in this chain
(section 5.9 File Objects) could have been made clearer by the addition of
a note along the lines that the behaviour of a file's read method (in
particular, what the unit of information is that it reads (that is, "byte",
"UTF-8 encoded character", or whatever)) depends on the way in which the
file has been opened.
Thank you, Chris (and others) for your attention to my request. I consider
this enquiry closed.
Stephen.
On Wed, Jan 11, 2023 at 5:36 PM Chris Angelico wrote:
> On Thu, 12 Jan 2023 at 04:31, Stephen Tucker
> wrote:
> > 1. Create BOM.txt
> > 2. Input three bytes at once from BOM.txt and print them
> > 3. Input three bytes one at a time from BOM.txt and print them
>
> All of these correctly show that a file, in binary mode, reads and writes
> bytes.
>
> > 4. Input three bytes at once from BOM.txt and print them
> > >>> import codecs
> > >>> myfil = codecs.open ("BOM.txt", mode="rb", encoding="UTF-8")
>
> This is now a codecs file, NOT a vanilla file object. See its docs here:
>
> https://docs.python.org/2.7/library/codecs.html#codecs.open
>
> The output is "codec-dependent" but I would assume that UTF-8 will
> yield Unicode text strings.
>
> > 5. Attempt to input three bytes one at a time from BOM.txt and print them
> > -
> >
> > >>> myfil = codecs.open ("BOM.txt", mode="rb", encoding="UTF-8")
> > >>> myBOM_4 = myfil.read (1)
> > >>> myBOM_4
> > u'\ufeff'
>
> > A. The attempt at Part 5 actually inputs all three bytes when we ask it
> to input just the first one!
>
> On the contrary; you asked it for one *character* and it read one
> character.
>
> Where were you seeing documentation that disagreed with this?
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
IDLE "Codepage" Switching?
I have four questions.
1. Can anybody explain the behaviour in IDLE (Python version 2.7.10)
reported below? (It seems that the way it renders a given sequence of bytes
depends on the sequence.)
2. Does the IDLE in Python 3.x behave the same way?
3. If it does, is this as it should behave?
4. If it is, then why is it as it should behave?
==
>>> mylongstr = ""
>>> for thisCP in range (157, 169):
mylongstr += chr (thisCP) + " "
>>> print mylongstr
ﾝ ﾞ ﾟ ﾠ ﾡ ﾢ ﾣ ﾤ ﾥ ﾦ ﾧ ﾨ
>>> mylongstr = ""
>>> for thisCP in range (158, 169):
mylongstr += chr (thisCP) + " "
>>> print mylongstr
ž Ÿ ¡ ¢ £ ¤ ¥ ¦ § ¨
>>> mylongstr = ""
>>> for thisCP in range (157, 169):
mylongstr += chr (thisCP) + " "
>>> print mylongstr
ﾝ ﾞ ﾟ ﾠ ﾡ ﾢ ﾣ ﾤ ﾥ ﾦ ﾧ ﾨ
==
Stephen Tucker.
--
https://mail.python.org/mailman/listinfo/python-list
Re: IDLE "Codepage" Switching?
Thanks for these responses.
I was encouraged to read that I'm not the only one to find this all
confusing.
I have investigated a little further.
1. I produced the following IDLE log:
>>> mylongstr = ""
>>> for thisCP in range (1, 256):
mylongstr += chr (thisCP) + " " + str (ord (chr (thisCP))) + ", "
>>> print mylongstr
1, 2, 3, 4, 5, 6, 7, 8, 9,
10, 11, 12,
13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
31, 32, ! 33, " 34, # 35, $ 36, % 37, & 38, ' 39, ( 40, ) 41, * 42, + 43,
, 44, - 45, . 46, / 47, 0 48, 1 49, 2 50, 3 51, 4 52, 5 53, 6 54, 7 55, 8
56, 9 57, : 58, ; 59, < 60, = 61, > 62, ? 63, @ 64, A 65, B 66, C 67, D 68,
E 69, F 70, G 71, H 72, I 73, J 74, K 75, L 76, M 77, N 78, O 79, P 80, Q
81, R 82, S 83, T 84, U 85, V 86, W 87, X 88, Y 89, Z 90, [ 91, \ 92, ] 93,
^ 94, _ 95, ` 96, a 97, b 98, c 99, d 100, e 101, f 102, g 103, h 104, i
105, j 106, k 107, l 108, m 109, n 110, o 111, p 112, q 113, r 114, s 115,
t 116, u 117, v 118, w 119, x 120, y 121, z 122, { 123, | 124, } 125, ~
126, 127, ﾀ 128, ﾁ 129, ﾂ 130, ﾃ 131, ﾄ 132, ﾅ 133, ﾆ 134, ﾇ 135, ﾈ 136, ﾉ
137, ﾊ 138, ﾋ 139, ﾌ 140, ﾍ 141, ﾎ 142, ﾏ 143, ﾐ 144, ﾑ 145, ﾒ 146, ﾓ 147,
ﾔ 148, ﾕ 149, ﾖ 150, ﾗ 151, ﾘ 152, ﾙ 153, ﾚ 154, ﾛ 155, ﾜ 156, ﾝ 157, ﾞ
158, ﾟ 159, ﾠ 160, ﾡ 161, ﾢ 162, ﾣ 163, ﾤ 164, ﾥ 165, ﾦ 166, ﾧ 167, ﾨ 168,
ﾩ 169, ﾪ 170, ﾫ 171, ﾬ 172, ﾭ 173, ﾮ 174, ﾯ 175, ﾰ 176, ﾱ 177, ﾲ 178, ﾳ
179, ﾴ 180, ﾵ 181, ﾶ 182, ﾷ 183, ﾸ 184, ﾹ 185, ﾺ 186, ﾻ 187, ﾼ 188, ﾽ 189,
ﾾ 190, 191, À 192, Á 193, Â 194, Ã 195, Ä 196, Å 197, Æ 198, Ç 199, È
200, É 201, Ê 202, Ë 203, Ì 204, Í 205, Î 206, Ï 207, Ð 208, Ñ 209, Ò 210,
Ó 211, Ô 212, Õ 213, Ö 214, × 215, Ø 216, Ù 217, Ú 218, Û 219, Ü 220, Ý
221, Þ 222, ß 223, à 224, á 225, â 226, ã 227, ä 228, å 229, æ 230, ç 231,
è 232, é 233, ê 234, ë 235, ì 236, í 237, î 238, ï 239, ð 240, ñ 241, ò
242, ó 243, ô 244, õ 245, ö 246, ÷ 247, ø 248, ù 249, ú 250, û 251, ü 252,
ý 253, þ 254, ÿ 255,
>>>
2. I copied and pasted the IDLE log into a text file and ran a program on
it that told me about every byte in the log.
3. I discovered the following:
Bytes 001 to 127 (01 to 7F hex) inclusive were printed as-is;
Bytes 128 to 191 (80 to BF) inclusive were output as UTF-8-encoded
characters whose codepoints were FF00 hex more than the byte values (hence
the strange glyphs);
Bytes 192 to 255 (C0 to FF) inclusive were output as UTF-8-encoded
characters - without any offset being added to their codepoints in the
meantime!
I thought you might just be interested in this - there does seem to be some
method in IDLE's mind, at least.
Stephen Tucker.
On Wed, Jan 18, 2023 at 9:41 AM Peter J. Holzer wrote:
> On 2023-01-17 22:58:53 -0500, Thomas Passin wrote:
> > On 1/17/2023 8:46 PM, rbowman wrote:
> > > On Tue, 17 Jan 2023 12:47:29 +, Stephen Tucker wrote:
> > > > 2. Does the IDLE in Python 3.x behave the same way?
> > >
> > > fwiw
> > >
> > > Python 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] on linux
> > > Type "help", "copyright", "credits" or "license()" for more
> information.
> > > str = ""
> > > for c in range(140, 169):
> > > str += chr(c) + " "
> > >
> > > print(str)
> > > Œ Ž ‘ ’ “ ” • – — ˜ ™ š › œ ž Ÿ ¡ ¢ £ ¤ ¥
> > > ¦ § ¨
> > >
> > >
> > > I don't know how this will appear since Pan is showing the icon for a
> > > character not in its set. However, even with more undefined characters
> > > the printable one do not change. I get the same output running Python3
> > > from the terminal so it's not an IDLE thing.
> >
> > I'm not sure what explanation is being asked for here. Let's take
> Python3,
> > so we can be sure that the strings are in unicode. The font being used
> by
> > the console isn't mentioned, but there's no reason it should have glyphs
> for
> > any random unicode character.
>
> Also note that the characters between 128 (U+0080) and 159 (U+009F)
> inclusive aren't printable characters. They are control characters.
>
> hp
>
> --
>_ | Peter J. Holzer| Story must make more sense than reality.
> |_|_) ||
> | | | h...@hjp.at |-- Charles Stross, "Creative writing
> __/ | http://www.hjp.at/ | challenge!"
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Precision Tail-off?
Hi, I have just produced the following log in IDLE (admittedly, in Python 2.7.10 and, yes I know that it has been superseded). It appears to show a precision tail-off as the supplied float gets bigger. I have two questions: 1. Is there a straightforward explanation for this or is it a bug? 2. Is the same behaviour exhibited in Python 3.x? For your information, the first 20 significant figures of the cube root in question are: 49793385921817447440 Stephen Tucker. -- >>> 123.456789 ** (1.0 / 3.0) 4.979338592181744 >>> 123456.789 ** (1.0 / 3.0) 49.79338592181744 >>> 123456789. ** (1.0 / 3.0) 497.9338592181743 >>> 123456789000. ** (1.0 / 3.0) 4979.338592181743 >>> 12345678900. ** (1.0 / 3.0) 49793.38592181742 >>> 1234567890. ** (1.0 / 3.0) 497933.8592181741 >>> 123456789. ** (1.0 / 3.0) 4979338.59218174 >>> 123456789000. ** (1.0 / 3.0) 49793385.9218174 >>> 12345678900. ** (1.0 / 3.0) 497933859.2181739 >>> 1234567890. ** (1.0 / 3.0) 4979338592.181739 >>> 123456789. ** (1.0 / 3.0) 49793385921.81738 >>> 123456789000. ** (1.0 / 3.0) 497933859218.1737 >>> 12345678900. ** (1.0 / 3.0) 4979338592181.736 >>> 1234567890. ** (1.0 / 3.0) 49793385921817.36 >>> 123456789. ** (1.0 / 3.0) 497933859218173.56 >>> 123456789000. ** (1.0 / 3.0) 4979338592181735.0 >>> 12345678900. ** (1.0 / 3.0) 4.979338592181734e+16 >>> 1234567890. ** (1.0 / 3.0) 4.979338592181734e+17 >>> 123456789. ** (1.0 / 3.0) 4.979338592181733e+18 >>> 123456789000. ** (1.0 / 3.0) 4.979338592181732e+19 >>> 12345678900. ** (1.0 / 3.0) 4.9793385921817313e+20 -- -- https://mail.python.org/mailman/listinfo/python-list
Re: Precision Tail-off?
Thanks, one and all, for your reponses.
This is a hugely controversial claim, I know, but I would consider this
behaviour to be a serious deficiency in the IEEE standard.
Consider an integer N consisting of a finitely-long string of digits in
base 10.
Consider the infinitely-precise cube root of N (yes I know that it could
never be computed unless N is the cube of an integer, but this is a
mathematical argument, not a computational one), also in base 10. Let's
call it RootN.
Now consider appending three zeroes to the right-hand end of N (let's call
it NZZZ) and NZZZ's infinitely-precise cube root (RootNZZZ).
The *only *difference between RootN and RootNZZZ is that the decimal point
in RootNZZZ is one place further to the right than the decimal point in
RootN.
None of the digits in RootNZZZ's string should be different from the
corresponding digits in RootN.
I rest my case.
Perhaps this observation should be brought to the attention of the IEEE. I
would like to know their response to it.
Stephen Tucker.
On Thu, Feb 16, 2023 at 6:49 PM Peter Pearson
wrote:
> On Tue, 14 Feb 2023 11:17:20 +, Oscar Benjamin wrote:
> > On Tue, 14 Feb 2023 at 07:12, Stephen Tucker
> wrote:
> [snip]
> >> I have just produced the following log in IDLE (admittedly, in Python
> >> 2.7.10 and, yes I know that it has been superseded).
> >>
> >> It appears to show a precision tail-off as the supplied float gets
> bigger.
> [snip]
> >>
> >> For your information, the first 20 significant figures of the cube root
> in
> >> question are:
> >>49793385921817447440
> >>
> >> Stephen Tucker.
> >> --
> >> >>> 123.456789 ** (1.0 / 3.0)
> >> 4.979338592181744
> >> >>> 1234567890. ** (1.0 / 3.0)
> >> 49793385921817.36
> >
> > You need to be aware that 1.0/3.0 is a float that is not exactly equal
> > to 1/3 ...
> [snip]
> > SymPy again:
> >
> > In [37]: a, x = symbols('a, x')
> >
> > In [38]: print(series(a**x, x, Rational(1, 3), 2))
> > a**(1/3) + a**(1/3)*(x - 1/3)*log(a) + O((x - 1/3)**2, (x, 1/3))
> >
> > You can see that the leading relative error term from x being not
> > quite equal to 1/3 is proportional to the log of the base. You should
> > expect this difference to grow approximately linearly as you keep
> > adding more zeros in the base.
>
> Marvelous. Thank you.
>
>
> --
> To email me, substitute nowhere->runbox, invalid->com.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Precision Tail-off?
As a follow-up to my previous message, I have just produced the following
log on IDLE, for your information:
--
>>> math.e ** (math.log
(12345678900) / 3)
4.979338592181741e+16
>>> 10 ** (math.log10 (12345678900)
/ 3)
4.979338592181736e+16
>>> 12345678900 ** (1.0 / 3.0)
4.979338592181734e+16
>>> 123456789e42 ** (1.0 / 3.0)
4.979338592181734e+16
------
Stephen Tucker.
On Fri, Feb 17, 2023 at 10:27 AM Stephen Tucker
wrote:
> Thanks, one and all, for your reponses.
>
> This is a hugely controversial claim, I know, but I would consider this
> behaviour to be a serious deficiency in the IEEE standard.
>
> Consider an integer N consisting of a finitely-long string of digits in
> base 10.
>
> Consider the infinitely-precise cube root of N (yes I know that it could
> never be computed unless N is the cube of an integer, but this is a
> mathematical argument, not a computational one), also in base 10. Let's
> call it RootN.
>
> Now consider appending three zeroes to the right-hand end of N (let's call
> it NZZZ) and NZZZ's infinitely-precise cube root (RootNZZZ).
>
> The *only *difference between RootN and RootNZZZ is that the decimal
> point in RootNZZZ is one place further to the right than the decimal point
> in RootN.
>
> None of the digits in RootNZZZ's string should be different from the
> corresponding digits in RootN.
>
> I rest my case.
>
> Perhaps this observation should be brought to the attention of the IEEE. I
> would like to know their response to it.
>
> Stephen Tucker.
>
>
> On Thu, Feb 16, 2023 at 6:49 PM Peter Pearson
> wrote:
>
>> On Tue, 14 Feb 2023 11:17:20 +, Oscar Benjamin wrote:
>> > On Tue, 14 Feb 2023 at 07:12, Stephen Tucker
>> wrote:
>> [snip]
>> >> I have just produced the following log in IDLE (admittedly, in Python
>> >> 2.7.10 and, yes I know that it has been superseded).
>> >>
>> >> It appears to show a precision tail-off as the supplied float gets
>> bigger.
>> [snip]
>> >>
>> >> For your information, the first 20 significant figures of the cube
>> root in
>> >> question are:
>> >>49793385921817447440
>> >>
>> >> Stephen Tucker.
>> >> --
>> >> >>> 123.456789 ** (1.0 / 3.0)
>> >> 4.979338592181744
>> >> >>> 1234567890. ** (1.0 / 3.0)
>> >> 49793385921817.36
>> >
>> > You need to be aware that 1.0/3.0 is a float that is not exactly equal
>> > to 1/3 ...
>> [snip]
>> > SymPy again:
>> >
>> > In [37]: a, x = symbols('a, x')
>> >
>> > In [38]: print(series(a**x, x, Rational(1, 3), 2))
>> > a**(1/3) + a**(1/3)*(x - 1/3)*log(a) + O((x - 1/3)**2, (x, 1/3))
>> >
>> > You can see that the leading relative error term from x being not
>> > quite equal to 1/3 is proportional to the log of the base. You should
>> > expect this difference to grow approximately linearly as you keep
>> > adding more zeros in the base.
>>
>> Marvelous. Thank you.
>>
>>
>> --
>> To email me, substitute nowhere->runbox, invalid->com.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
--
https://mail.python.org/mailman/listinfo/python-list
Python 2.7 range Function provokes a Memory Error
Hi, The range function in Python 2.7 (and yes, I know that it is now superseded), provokes a Memory Error when asked to deiliver a very long list of values. I assume that this is because the function produces a list which it then iterates through. 1. Does the range function in Python 3.x behave the same way? 2. Is there any equivalent way that behaves more like a for loop (that is, without producing a list)? To get round the problem I have written my own software that is used in a for loop. Stephen Tucker. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2.7 range Function provokes a Memory Error
Hi again, I tried xrange, but I got an error telling me that my integer was too big for a C long. Clearly, xrange in Py2 is not capable of dealing with Python (that is, possibly very long) integers. I am raising this because, (a) IF xrange in Py3 is a simple "port" from Py2, then it won't handle Python integers either. AND (b) IF xrange in Py3 is intended to be equivalent to range (which, even in Py2, does handle Python integers) THEN It could be argued that xrange in Py3 needs some attention from the developer(s). Stephen Tucker. On Thu, Mar 2, 2023 at 6:24 PM Jon Ribbens via Python-list < python-list@python.org> wrote: > On 2023-03-02, Stephen Tucker wrote: > > The range function in Python 2.7 (and yes, I know that it is now > > superseded), provokes a Memory Error when asked to deiliver a very long > > list of values. > > > > I assume that this is because the function produces a list which it then > > iterates through. > > > > 1. Does the range function in Python 3.x behave the same way? > > No, in Python 3 it is an iterator which produces the next number in the > sequence each time. > > > 2. Is there any equivalent way that behaves more like a for loop (that > is, > > without producing a list)? > > Yes, 'xrange' in Python 2 behaves like 'range' in Python 3. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Are there Python modules that allow a program to write to the screen?
Hi, I have old software written in GWBASIC that I use to plot diagrams on the screen. In Windows 10, I have to resort to using the DOSBox emulator to run it. I would dearly like to re-write it in Python - ideally Python 2.7. What, if anything, is available? Stephen Tucker. -- https://mail.python.org/mailman/listinfo/python-list
Re: Trying to read from a text file to generate a graph
[Resending to the list only, since I couldn't post it without subscribing.]
On Wed, 28 Jul 2021 11:58:21 -0400 "Steve" wrote:
> I forgot about the no-file rule...
>
>> On 28Jul2021 02:55, Steve wrote:
>> I am going though a struggle with this and just don't see where it
>> fails. I am using the Dual Bar Graph.py program from
>> https://matplotlib.org/stable/gallery/index.html website. The file
>> from the web site works so that shows that all my installations are
>> complete.
>>
>> My program, LibreGraphics 05.py program runs but the graph is all
>> smutched up. I am pulling data from the EXCEL-FILE.txt into the
>> program, selecting three values for each line and creating three
>> variables formatted as is shown in the original demo file.
>>
>> When you run the program, choose 112 when prompted. You will see the
>> values of the variables I want to pass to the graph section of the
>> code. If the values are hardcoded, the graphs look good. When the
>> variables generated by my section of the code, it does not.
The problem is due to the values of Sensors, TestStrips and SampleNumber
being strings; what you want is for them to be lists, as in the
assignments you commented out. And since the data from the file is read
in as strings, you have to cast the elements of the Sensors and
TestStrips lists to integers, since you want the numerical values. The
following code does the job:
Sensors = []
TestStrips = []
SampleNumber = []
x = 1
SensorNumber = input("Enter senaor number: ")
with open("_EXCEL-FILE.txt", 'r') as infile:
for lineEQN in infile:
if (lineEQN[0:1]== "."):
SN = lineEQN[44:48].strip()
if (SensorNumber == SN):
SN = x
SampleNumber.append(SN)
sv = lineEQN[25:29].strip()
Sensors.append(int(sv))
tv = lineEQN[32:37].strip()
TestStrips.append(int(tv))
x += 1
labels = SampleNumber
Add the rest of your code from the second half to make the desired bar
chart.
Steve Berman
--
https://mail.python.org/mailman/listinfo/python-list
Is there a better way to create a list of None objects?
Hi, I thought I'd share the following piece of code that I have recently written (a) to check that what I have done is reasonable - even optimum, (b) to inform others who might be wanting to do similar things, and (c) to invite comment from the community. --- # # Yes: Create an empty list of Band Limits for this language # # Note. The rather complicated logic on the right-hand side of the # assignment below is used here because none of the following # alternatives had the desired effect: # # Logic Effect # # [None * 8]TypeError: unsupported operand type(s) for *: ... # [(None) * 8] TypeError: unsupported operand type(s) for *: ... # [((None)) * 8]TypeError: unsupported operand type(s) for *: ... # [(None,) * 8] [(None, None, None, None, None, None, None, None)] # list ((None) * 8) TypeError: unsupported operand type(s) for *: ... # diclll_BLim [thisISO_] = list ((None,) * 8) --- Thanks in anticipation. Stephen Tucker. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a better way to create a list of None objects?
Thanks for this feedback, Chris, Matthieu. Both are spot on - and thanks for the timing comparison, Matthieu. I suppose I didn't think to try the solution you suggest because I didn't think that I would end up with a single list, but 8 of them. OK, I'll stop wriggling. Stephen. On Thu, Aug 12, 2021 at 10:22 AM Matthieu Dartiailh wrote: > You can achieve the same result by writing: > [None] * 8 > > Comparing both cases in IPython I get: > > In [1]: %timeit list((None,)*8) > 110 ns ± 0.785 ns per loop (mean ± std. dev. of 7 runs, 1000 loops > each) > > In [2]: %timeit [None] * 8 > 88.2 ns ± 0.432 ns per loop (mean ± std. dev. of 7 runs, 1000 loops > each) > > So the list multiplication appears a bit faster. > > Best > > Matthieu > > Le 8/12/2021 à 10:57 AM, Stephen Tucker a écrit : > > Hi, > > > > I thought I'd share the following piece of code that I have recently > written > > (a) to check that what I have done is reasonable - even optimum, > > (b) to inform others who might be wanting to do similar things, and > > (c) to invite comment from the community. > > > > --- > > > > # > > > > # Yes: Create an empty list of Band Limits for this language > > > > # > > > > # Note. The rather complicated logic on the right-hand side of the > > > > # assignment below is used here because none of the following > > > > # alternatives had the desired effect: > > > > # > > > > # Logic Effect > > > > # > > > > # [None * 8]TypeError: unsupported operand type(s) for *: ... > > > > # [(None) * 8] TypeError: unsupported operand type(s) for *: ... > > > > # [((None)) * 8]TypeError: unsupported operand type(s) for *: ... > > > > # [(None,) * 8] [(None, None, None, None, None, None, None, None)] > > > > # list ((None) * 8) TypeError: unsupported operand type(s) for *: ... > > > > # > > > > diclll_BLim [thisISO_] = list ((None,) * 8) > > > > > > --- > > > > Thanks in anticipation. > > > > Stephen Tucker. > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: degrees and radians.
For what it's worth, mathematicians naturally work with angles in radians. The mathematics of the trignonmetric functions works naturally when the angle is expressed in radians. For the older among us, logarithms also have a "natural" base, and that is the number e. Back in those days, however, even the mathematicians would use logarithm tables where the values were shown to base 10. On Wed, Aug 24, 2016 at 6:26 AM, Steven D'Aprano < steve+comp.lang.pyt...@pearwood.info> wrote: > On Wednesday 24 August 2016 14:26, Gary Herron wrote: > > > Do you really need anything more complex than this? > > > > >>> toRadians = math.pi/180.0 > > > > >>> math.sin(90*toRadians) > > 1.0 > > > > Perhaps I'm not understanding what you mean by "clunky", but this seems > > pretty clean and simple to me. > > The math module has two conversion functions, math.radians() and > math.degrees(). > > > Some other languages (Julia, by memory, and perhaps others) have dedicated > sind(), cosd(), tand() or possibly dsin(), dcos(), dtan() functions which > take > their argument in degrees and are more accurate than doing a conversion to > radians first. I'd like to see that. > > I've also seen languages with sinp() etc to calculate the sine of x*pi > without > the intermediate calculation. > > But if I were designing Python from scratch, I'd make sin(), cos() and > tan() > call dunder methods __sin__ etc: > > > def sin(obj): > if hasattr(type(obj), '__sin__'): > y = type(obj).__sin__() > if y is not NotImplemented: > return y > elif isinstance(obj, numbers.Number): > return float.__sin__(float(obj)) > raise TypeError > > Likewise for asin() etc. > > Then you could define your own numeric types, such as a Degrees type, a > PiRadians type, etc, with their own dedicated trig function > implementations, > without the caller needing to care about which sin* function they call. > > > > > -- > Steve > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Doubled backslashes in Windows paths
Hi Oz,
This might only be tangential to your actual issue, but, there again, it
might be the tiny clue that you actually need.
In Python, I use raw strings and single backslashes in folder hierarchy
strings to save the problem of the backslash in ordinary strings. Even with
this policy, however, there is a slight "gotcha": Although it is claimed
that r" ... " suspends the escape interpretation of the backslash in the
string, a raw string cannot end with a backslash:
myraw = "\a\b\"
provokes the error message:
SyntaxError: EOL while scanning string literal
To see how well this approach deals with folder hierarchies with spaces in
their names, I created the following file:
c:\Python27\ArcGIS10.4\Lib\idlelib\sjt\sp in\test.txt
Note the space in the folder name sp in .
In IDLE, I then issued the following statement:
infile= open (r"c:\Python27\ArcGIS10.4\Lib\idlelib\sjt\sp in\test.txt", "r")
Note that I didn't need to get enclosing quotes into my folder hierarchy
string. It begins with c and ends with t .
The statement worked as you might expect, and granted me access to the
lines in the file.
It seems that it is only necessary to enclose a folder hierarchy string in
quotes when defining the string in a situation in which spaces would
otherwise be interpreted as terminators. The classis case of this is in a
command with parameters in a batch file. If the string has been defined
before it is presented to the Windows Command interpreter, the spaces are
accepted as part of it without the need then of enclosing quotes.
Hope this helps.
Yours,
Stephen Tucker.
On Fri, Oct 7, 2016 at 6:30 AM, Oz-in-DFW wrote:
> I'm using Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC
> v.1900 32 bit (Intel)] on Windows 7
>
> I'm trying to write some file processing that looks at file size,
> extensions, and several other things and I'm having trouble getting a
> reliably usable path to files.
>
> The problem *seems* to be doubled backslashes in the path, but I've read
> elsewhere that this is just an artifact of the way the interpreter
> displays the strings.
>
> I'm getting an error message on an os.path.getsize call;
>
> Path: -
> "C:\Users\Rich\Desktop\2B_Proc\2307e60da6451986dd8d23635b845386.jpg" -
> Traceback (most recent call last):
> File "C:\Users\Rich\workspace\PyTest\test.py", line 19, in
> if os.path.getsize(path)>1:
> File "C:\Python32\lib\genericpath.py", line 49, in getsize
> return os.stat(filename).st_size
> WindowsError: [Error 123] The filename, directory name, or volume
> label syntax is incorrect:
> '"C:\\Users\\Rich\\Desktop\\2B_Proc\\2307e60da6451986dd8d23635b8453
> 86.jpg"'
>
> From (snippet)
>
> path = '"'+dirpath+name+'"'
> path = os.path.normpath(path)
> print("Path: -",path,"-")
> if os.path.getsize(path)>1:
> print("Path: ",path," Size:
> ",os.path.getsize(dirpath+name))
>
> but if I manually use a console window and cut and paste the path I
> print, it works;
>
> C:\>dir
> "C:\Users\Rich\Desktop\2B_Proc\2307e60da6451986dd8d23635b845386.jpg"
> Volume in drive C is Windows7_OS
>
> Directory of C:\Users\Rich\Desktop\2B_Proc
>
> 10/03/2016 08:35 AM59,200
> 2307e60da6451986dd8d23635b845386.jpg
>1 File(s) 59,200 bytes
>0 Dir(s) 115,857,260,544 bytes free
>
> So the file is there and the path is correct. I'm adding quotes to the
> path to deal with directories and filenames that have spaces in them.
> If I drop the quotes, everything works as I expect *until* I encounter
> the first file/path with spaces.
>
> I'll happily RTFM, but I need some hints as to which FM to R
>
> --
> mailto:o...@ozindfw.net
> Oz
> POB 93167
> Southlake, TX 76092 (Near DFW Airport)
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Quick way to calculate lines of code/comments in a collection of Python scripts?
Tomasz, How about using the command prompt command FIND /C on each of your source files as follows: FIND/C "#" >NumbersOfLinesContainingPythonComments.dat FIND/C /V "#" >NumbersOfLinesNotContainingPythonComments.dat You would end up with two files each with a column of line counts; Import these lines into an Excel Spreadsheet and calculate whatever you like with them. Stephen. On Sun, Oct 23, 2016 at 9:51 PM, Tomasz Rola wrote: > On Wed, Oct 05, 2016 at 01:56:59PM -0400, Malcolm Greene wrote: > > Looking for a quick way to calculate lines of code/comments in a > > collection of Python scripts. This isn't a LOC per day per developer > > type analysis - I'm looking for a metric to quickly judge the complexity > > of a set of scripts I'm inheriting. > > > > Thank you, > > Malcolm > > A bit more than what you asked for (and sorry for being late) but I > find sloccount quite good. Or at least interesting (computes sloc and > some stats about project, given project dir or a single file with > code): > > http://www.dwheeler.com/sloccount/ > > -- > Regards, > Tomasz Rola > > -- > ** A C programmer asked whether computer had Buddha's nature. ** > ** As the answer, master did "rm -rif" on the programmer's home** > ** directory. And then the C programmer became enlightened... ** > ** ** > ** Tomasz Rola mailto:tomasz_r...@bigfoot.com ** > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: calling a program from Python batch file
This might be totally irrelevant, but, if (a) the data to be read by the program during a given run is known when the program is run/launched, (b) that data is purely textual and (c) that data can be read by the program from the stdin channel, then my idea is (1) before the launch, put that data into a file named, say, inputfile.dat, and then (2) launch the program with a command like call program.bat outputfile.dat Finally, if the program can read its data from a given file and possibly needs to output its data, again, to a named file, and those files' names can be read from the parameters to the call, then call program.bat inputfile.dat outputfile.dat can be used. On Wed, Dec 7, 2016 at 6:23 PM, Michael Torrie wrote: > On 12/07/2016 10:59 AM, John Gordon wrote: > > In Karim > Farokhnia writes: > > > >> Hi there, > > > >> I am writing a batch file in Python. The batch file, in part, calls a > >> program named "oq-console.bat" to run. Then once the program comes up > >> (it looks like windows CMD), I need the batch file to type some commands > >> to make it run (just like I would do it by myself). > > > > If you need to start up a program, provide interactive input to it, and > > perhaps examine its interactive output, then you want the "pexpect" > module: > > > > Pexpect is a pure Python module for spawning child applications; > > controlling them; and responding to expected patterns in their > output. > > Pexpect allows your script to spawn a child application and control > it > > as if a human were typing commands. > > > > https://pexpect.readthedocs.io/en/stable/ > > Does Pexpect work on Windows? > > In the OP's case it looks like the standard in pipe is sufficient. > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Ruby parens-free function calls [was Re: Accessing parent objects]
On Mon, Mar 26, 2018, at 2:19 PM, Rick Johnson wrote: >Sure, the behavior that Steven > uncovered is odd, but it could be that Maz harbors a strong > disliking for undisciplined pupils, and thus, he designed > and placed this little trap in the hopes the pain it induced > might encourage the petulant little meat-heads to follow > some sensible styling rules. My god, I've been away from this list for quite awhile, but we're still entertaining this fool? -- Stephen Hansen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: Learning Python
I have found Learning Python by Mark Lutz helpful. I have the 4th edition (2009). Its ISBN is 978-0-596-15806-4. A lot will depend on your learning style. This book reads more like a set of course notes than a reference book, but it does contain tables and summaries, too. On Tue, Jun 5, 2018 at 5:51 PM, T Berger wrote: > Can someone learn Python through a book such as Head Start Python? Would > an online course from MIT or google be better? > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Question about floating point
Hi Frank, One difference is that, in order to carry out the instructions embodied in the first example, the computer has to perform arithmetic. And it adds the binary approximation of 1.1 (which is very slightly wrong) to the binary approximation of 2.2 (which, again, is very slightly wrong). It then prints the denary equivalent to the sum of those two which happens to be very slightly more than 3.3. When you type 3.3, it stores that as the binary approximation of 3.3 (which is y at that stage, to answer your question, and is, again, no surprise, also very slightly wrong) and then prints the denary equivalent of that binary approximation which happens to end up sufficiently close to 3.3 so as to cause it to print 3.3. I hope that helps. The experts around here (of which I am not one) may well point you to the decimal package which allows better handling of such arithmetic, if you are want the computer to behave more like you would want it to behave. Regards, Stephen Tucker. On Tue, Aug 28, 2018 at 3:11 PM, Frank Millman wrote: > Hi all > > I know about this gotcha - > > x = 1.1 + 2.2 >>>> x >>>> >>> 3.3003 > > According to the docs, the reason is that "numbers like 1.1 and 2.2 do not > have exact representations in binary floating point." > > So when I do this - > > y = 3.3 >>>> y >>>> >>> 3.3 > > what exactly is happening? What is 'y' at this point? > > Or if I do this - > > z = (1.1 + 2.2) * 10 / 10 >>>> z >>>> >>> 3.3 > > What makes it different from the first example? > > Thanks > > Frank Millman > > > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Array
On Wed, Mar 30, 2016, at 10:34 PM, tdspe...@gmail.com wrote: > as you can see the option element was added third but is the first one > displayed. > > Is this just standard - I am using Python 3.5 The order of items in dictionaries is based on the hash value -- which while stable, should be considered random and not reliable. If you want to maintain insertion order, consider using an OrderedDict: https://docs.python.org/3.5/library/collections.html#collections.OrderedDict -- https://mail.python.org/mailman/listinfo/python-list
Re: Strange range
On Sat, Apr 2, 2016, at 02:40 PM, Marko Rauhamaa wrote: > That's why I was looking for counterexamples in the standard library This entire bent of an argument seems flawed to me. The standard library has never been a beacon for best practices or idiomatic uses of Python. That a use exists in the standard library, or that one does not, doesn't really tell you anything meaningful about Python itself or good practices with the language. The standard library is under uniquely conservative constraints that enshrine compatibility and reliability from one point release to another over any kind of innovation. That code exists in the standard library is, itself, an incredibly strong reason why it should stay as IS: changes for style, idiom, best practices, modern techniques, those are all valid but *weak* arguments to change the standard library. The stdlib works and its continuing to work tomorrow is its most important burden. Just look at how much of the stdlib is not PEP8 compliant. Changing it to be PEP8 compliant is seen as a worse thing to do then the possibility of introducing bugs by doing such a sweeping change in the interest of good practices and style. The stdlib exists as a bastion of stability above all else. Its standards aren't a reason to make a change (or, not to make a change, either). That doesn't mean its not useful to look at the standard library, but you should not enshrine it as the example of good or idiomatic code to measure decisions against. Most code exists outside the stdlib. --- Stephen Hansen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode normalisation [was Re: [beginner] What's wrong?]
On Sat, Apr 9, 2016, at 12:25 PM, Mark Lawrence via Python-list wrote: > Again, where is the relevance to Python in this discussion, as we're on > the main Python mailing list? Please can the moderators take this stuff > out, it is getting beyond the pale. You need to come to grip with the fact that python-list is only moderated in the vaguest sense of the word. Quote: https://www.python.org/community/lists/ "Pretty much anything Python-related is fair game for discussion, and the group is even fairly tolerant of off-topic digressions; there have been entertaining discussions of topics such as floating point, good software design, and other programming languages such as Lisp and Forth." If you don't like it, sorry. We all have our burdens to bear. --S -- https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
On Sun, Apr 10, 2016, at 03:51 PM, Fillmore wrote:
>
> let's look at this:
>
> $ python3.4
> Python 3.4.0 (default, Apr 11 2014, 13:05:11)
> [GCC 4.8.2] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> line1 = '"String1" | bla'
> >>> parts1 = line1.split(" | ")
> >>> parts1
> ['"String1"', 'bla']
> >>> tokens1 = eval(parts1[0])
> >>> tokens1
> 'String1'
> >>> tokens1[0]
> 'S'
>
> and now this
>
> >>> line2 = '"String1","String2" | bla'
> >>> parts2 = line2.split(" | ")
> >>> tokens2 = eval(parts2[0])
I *THINK* what you're asking is why this returns a tuple, where in the
first eval you got a string. The answer is because commas create tuples
(not parens), so:
"String1", "String2"
is a tuple expression. Whereas:
"String1"
is a string expression.
> the question is: at which point did the language designers decide to
> betray the
> "path of least surprise" principle and create a 'discontinuity' in the
> language?
There's nothing inconsistent or surprising going on besides you doing
something vaguely weird and not really expressing what you find
surprising.
--Stephen
m e @ i x o k a i . i o
--
https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]
On Sun, Apr 10, 2016, at 05:13 PM, Fillmore wrote:
> I guess that the answer to my question is: there is no such thing as a
> one-element tuple,
> and Python will automatically convert a one-element tuple to a string...
> hence the
> behavior I observed is explained...
>
> >>> a = ('hello','bonjour')
> >>> b = ('hello')
> >>> b
> 'hello'
> >>> a
> ('hello', 'bonjour')
> >>>
>
>
> Did I get this right this time?
No, you didn't. Your mistake is again -- parens don't make tuples,
commas do.
A one element tuple is:
>>> b = ("hello,)
The parens are optional, I always put them in because:
>>> b = "hello",
The parens group an expression, they don't make a type.
--
Stephen Hansen
m e @ i x o k a i . i o
--
https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]
On Sun, Apr 10, 2016, at 05:18 PM, Stephen Hansen wrote: > The parens are optional, I always put them in because: > >>> b = "hello", Ahem, "because its easy to miss the trailing comma" is what I meant to say here. -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]
On Sun, Apr 10, 2016, at 05:22 PM, Fillmore wrote:
> Hold on a sec! it turns up that there is such thing as single-element
> tuples in python:
>
> >>> c = ('hello',)
> >>> c
> ('hello',)
> >>> c[0]
> 'hello'
> >>> c[1]
> Traceback (most recent call last):
>File "", line 1, in
> IndexError: tuple index out of range
> >>>
>
> So, my original question makes sense. Why was a discontinuation point
> introduced by the language designer?
What discontinuation point?
You keep masterfully managing to *not explain what you're asking*. What
is surprising to you?
--S
--
https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
On Sun, Apr 10, 2016, at 05:17 PM, Fillmore wrote: > On 04/10/2016 07:30 PM, Stephen Hansen wrote: > > > There's nothing inconsistent or surprising going on besides you doing > > something vaguely weird and not really expressing what you find > > surprising. > > well, I was getting some surprising results for some of my data, so I can > guarantee that I was surprised! The point is you are not saying *what* is surprising. Nothing in your example code looks the least bit surprising to me, but I've been using Python for ages. If you're surprised by something, say *what* surprises you at the very least. But to repeat what I said that you didn't quote: the thing you need to understand is that parentheses do not create tuples, commas do. Parentheses only group things together. --Stephen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask])
On Sun, Apr 10, 2016, at 05:45 PM, Ben Finney wrote: > So, let's please stop saying “parens don't create a tuple”. They do, and > because of that I've stopped saying that false over-simplification. I stand by "parens don't make a tuple", with the caveat that I should have mentioned the empty tuple exception that proves the rule. The only time you need parens is to resolve ambiguity. To suggest that parens do make tuples confuses the issue, given things like this: >>> a = 1,2,3 >>> b = (1, 2, 3) -- Stephen Hansen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples
On Sun, Apr 10, 2016, at 05:48 PM, Fillmore wrote: > On 04/10/2016 08:31 PM, Ben Finney wrote: > > Can you describe explicitly what that “discontinuation point” is? I'm > > not seeing it. > > Here you go: > > >>> a = '"string1"' Here, "a" is a string that contains a double quoted string. So if you evaluate it, you get a string. > >>> b = '"string1","string2"' Here, "b" is a string that contains two double quoted strings separated by a comma. So if you evaluate it, you get a tuple of two strings. > >>> c = '"string1","string2","string3"' This is as above, but with three items. With that in mind: > >>> ea = eval(a) > >>> eb = eval(b) > >>> ec = eval(c) > >>> type(ea) > > >>> type(eb) > > >>> type(ec) > This should all be expected. The commas, when you evaluate them, are in B&C making tuples. There's only a single string in A, so you get a string. If you wanted a one item tuple, you would have written: >>> a = '"string1",' Note the trailing comma. > I can tell you that it exists because it bit me in the butt today... > > and mind you, I am not saying that this is wrong. I'm just saying that it > surprised me. If the above doesn't explain it, then I still don't understand what you're finding surprising and what you'd expect otherwise. ---Stephen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
On Sun, Apr 10, 2016, at 09:03 PM, Fillmore wrote: > and the (almost always to be avoided) use of eval() FWIW, there's ast.literal_eval which is safe and there's no reason to avoid it. You'll still have to deal with the fact that a single string on a line will return a string while multiples will return a tuple, but how you're doing that (checking the type of the result) is fine. --Stephen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples
On Sun, Apr 10, 2016, at 09:43 PM, Fillmore wrote: > I thought I had made the point clear with the REPL session below. Considering how many people expressed repeatedly they didn't know what was surprising, it wasn't clear at all. In general you need to explain these things with your words: code is good, show code, don't get me wrong, but you need to express your expectations and how the difference between what happened and what you expected surprised you. Both parts, the code and the expression of your thoughts, are really important to getting help around here :) --- Stephen Hansen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
On Sun, Apr 10, 2016, at 10:18 PM, Rustom Mody wrote:
> On Monday, April 11, 2016 at 10:17:13 AM UTC+5:30, Stephen Hansen wrote:
> > On Sun, Apr 10, 2016, at 09:03 PM, Fillmore wrote:
> > > and the (almost always to be avoided) use of eval()
> >
> > FWIW, there's ast.literal_eval which is safe and there's no reason to
> > avoid it.
>
> Its error reporting is clunky:
>
> >>> from ast import literal_eval as le
> >>> le("(1)")
> 1
> >>> le("(1,)")
> (1,)
> >>> le("1")
> 1
> >>> le("{1:x}")
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python2.7/ast.py", line 80, in literal_eval
> return _convert(node_or_string)
> File "/usr/lib/python2.7/ast.py", line 63, in _convert
> in zip(node.keys, node.values))
> File "/usr/lib/python2.7/ast.py", line 62, in
> return dict((_convert(k), _convert(v)) for k, v
> File "/usr/lib/python2.7/ast.py", line 79, in _convert
> raise ValueError('malformed string')
> ValueError: malformed string
So? Worst case scenario, someone puts invalid data into the file and it
throws an exception. Could it be more specific? Maybe, but I don't see
why it needs to be. If your input isn't reliably formatted, catch
ValueError and log it and fix (either what wrote it or change how you
read it).
--S
--
https://mail.python.org/mailman/listinfo/python-list
Re: The reason I uninstalled Python 3.5.1 (32-bit) for Windows
On Tue, Apr 12, 2016, at 07:57 PM, Jason Honeycutt wrote: > I am providing feedback as to why I just uninstalled Python. I could not > use pip. My command line would not recognize pip.exe as a file, even > though > I could see the file listed when I type "dir" in the Scripts folder. If you can't use pip while in the same directory as pip.exe, I don't even know what is wrong. That said, you can access pip via 'python -m pip args' instead of using the pip executable. -- Stephen Hansen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: hourly weather forecast data
On Tue, Apr 12, 2016, at 08:36 PM, kamaraju kusumanchi wrote: > Is there a way to get hourly weather forecast data (temperature, > chance of precipitation) from the command line in Debian Linux? Personally, the last time I wanted to do something like this, I used the requests library to fetch a RSS feed from Wunderground. But that was awhile ago and I don't see the obvious RSS links banymore. Did you see: https://www.wunderground.com/weather/api/d/docs -- Stephen Hansen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: How to XOR a byte output?
On Wed, Apr 13, 2016, at 06:51 AM, durgadevi1 wrote:
> I would like to check with you whether using binascii.hexlify() to
> convert the series of bytes into alphabets and integers is correct.
To be clear, they already are integers.The \x notation is how you
naively represent a byte out of the printable range in ASCII. A byte is
a number from 0 to 255, which can also be thought of as 0x00 to 0xFF..
The 'printable range' is those bytes which represent normal characters
instead of control codes and such.
Computers like showing raw byte data in hex \x (which shouldn't be
confused with binascii.hexify) because then each byte concisely fills up
exactly 2 (well, 4, counting the \x) characters, instead of some bytes
being only one character (1), some being two (10), and some being three
(100).
You can see the integer value, consider:
>>> data = b'$//W?\xc0\x829\xa2\xb9\x13\x8c\xd5{\\'
>>> print data[0]
36
>>> print data[10]
19
>>> list(data)
[36, 47, 47, 87, 63, 192, 130, 57, 162, 185, 19, 140, 213, 123, 92]
binascii is almost certainly not what you want: that converts arbitrary
bytes into an ASCII encoded string, at which point its no longer bytes
(and before you did something to it besides displaying it, you'd want to
decode it back to bytes again, probably).
--Stephen
m e @ i x o k a i . i o
--
https://mail.python.org/mailman/listinfo/python-list
Re: sys.exit(1) vs raise SystemExit vs raise
> * You can use named constants from ‘os’ for the purpose of specifying > exit status numbers. Only on *nix. Even then it varies from platform to platform which constants you can use. I'd prefer to document the return status and use numbers/my own constants directly, that way supporting any platform (even windows, where its %ERRORLEVEL% --S -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Sat, Apr 16, 2016, at 01:51 AM, Marko Rauhamaa wrote: > Chris Angelico : > > > On Sat, Apr 16, 2016 at 6:06 PM, Marko Rauhamaa wrote: > >> It doesn't really matter one way or another. The true WTF is that it's > >> been changed. > > > > Why? Was PEP 8 inscribed on stone tablets carried down from a mountain? > > In a way, yes. > > I don't follow PEP 8 to the tee; probably nobody does. However, I don't > see the point of turning truckloads of exemplary Python code into > truckloads of substandard Python code. This attitude is part of the problem: not following PEP8 does not make code "substandard". PEP8 was never meant to be an authoritative metric of 'good'. Its a set of guidelines that are subject to change over time (this isn't even KINDA the first change!) and represent the core devs taste and particular needs, and it goes out of its way to say that it is only a suggestion and other concerns (especially local consistency) override its advice. --- Stephen Hansen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2.7
On Fri, Apr 15, 2016, at 03:48 PM, a3a95797 wrote: > > Sirs(s) > > I wish to have python 2.7 on a computer. I have not been able to get a > working copy to work on my machine. I am prepared to follow instructions > or to pay someone to install Python on my computer. Either the Debian or > the Windows operating system is satisfactory. I am prepared to pay a > company or person to reach my goal of programming with Python. Define "not been ablke to get a working copy on my machine". For windows, just go to python.org and download it. For debian, it should come pre-installed. --- Stephen Hansen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: How much sanity checking is required for function inputs?
On Sun, Apr 17, 2016, at 12:34 PM, Christopher Reimer wrote:
> if color not in [VARS['COLOR_BLACK'], VARS['COLOR_WHITE']]:
> raise Exception("Require \'{}\' or \'{}\' for input value, got
> \'{}\' instead.".format(VARS['COLOR_BLACK'], VARS['COLOR_WHITE'], color))
Do you think it likely you'll receive a 'color' value not in the list of
black and white? Are you accepting colors from users? If you are, I'd
sanity check *at user input*. Users are crazy, sanitize and check the
heck out of their stuff.
Your code, though? Your time and effort is better spent putting in a
docstring documenting what's valid in color, and if some other coder
puts in red, why, they'll get a KeyError, and it'll point to precisely
what line is wrong, and be able to figure it out.
Unit tests are where you try feeding invalid data into functions and see
how they react-- and the correct reaction to bad data is usually
exceptions. In this case, a KeyError thrown by [VARS['COLOR_BLACK'],
VARS['COLOR_WHITE']][color] is more descriptive then your verbose
Exception.
(What's with the VARS business? Something smells bad there. You're doing
something weird there)
> How much sanity checking is too much in Python?
IMHO, you've got too much.
But that's a fuzzy question, there's no solid and clear answer. Did you
see Ethan's response? I largely agree with his trinity:
On Sun, Apr 17, 2016, at 10:26 PM, Ethan Furman wrote:
> I sanity check for three reasons:
>
> 1) raise a nicer error message
>
> 2) keep the point of failure close to the error
>
> 3) the consequences of bad data are Bad Bad Things (tm)
With a 4)th that exceptions aren't for users, only programmers. But
ultimately, I'd rather a user see an exception if something weird goes
wrong because they can send it to me and I can diagnose it and push an
update. So I also:
4) Attempt to make sure all user errors result in user error messages,
not exceptions.
Note, 1) doesn't mean I always raise a nicer message, it means if
"KeyError" is ambiguious or odd, I raise a better and more informative
one. But you're getting nothing swapping out KeyError for
Exception(lotsofwords).
I use 1) more to be less 'nicer' and more, er, 'more specific'. Since I
don't like exceptions to rise to the user level where niceness is
needed.
--Stephen
m e @ i x o k a i . i o
--
https://mail.python.org/mailman/listinfo/python-list
Re: How much sanity checking is required for function inputs?
On Tue, Apr 19, 2016, at 11:09 PM, Ethan Furman wrote: > On 04/19/2016 10:51 PM, Stephen Hansen wrote: > > I use 1) more to be less 'nicer' and more, er, 'more specific'. Since I > > don't like exceptions to rise to the user level where niceness is > > needed. > > Yeah, that's a better phrasing for (1); I meant more appropriate or > informative, such as swapping an internal error (such as KeyError) for a > more meaningful FieldNotFound error (or whatever) -- largely library > code concerns. Yeah, and what the OP is doing is going the exact opposite-- from a more-specific exception (KeyError) to a more generic one (Exception). To me that's (usually) an anti-pattern. --S -- https://mail.python.org/mailman/listinfo/python-list
Re: Running lpr on windows from python
On Wed, Apr 20, 2016, at 06:57 AM, loial wrote: > process = subprocess.Popen(commandline, shell=True, > stdout=subprocess.PIPE, stderr=subprocess.PIPE) > > where command line is > C:/windows/system32/lpr.exe -S 172.28.84.38 -P RAW C:/john/myfile Try making command line: commandline = r"C:\windows\system32\lpr.exe -S 172.28.84.38 -P RAW C:\john\myfile" The r in front of the string makes it a raw string so you don't have to double up the slashes. --- Stephen Hansen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
