[ANNOUNCE] PySide 1.0.6.1 - Minor Release
Hi All, Due some problems with PySide + Qt 4.6 compilation we are releasing this minor update, which contains the fix for this problem. Since this version only contains the fix for Qt. 4.6 bug, the update is not required for those who are using Qt. 4.7. You can get the latest PySide version from the download page[1]. [1]http://developer.qt.nokia.com/wiki/Category:LanguageBindings::PySide::Downloads Thanks All, PySide Team -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: bash command, get stdErr
Il Thu, 25 Aug 2011 01:52:25 -0700, Chris Rebert ha scritto: On Thu, Aug 25, 2011 at 1:25 AM, Tracubik affdfsdfds...@b.com wrote: Hi all! cut Untested: from subprocess import Popen, PIPE sudo = Popen(sudo las, shell=True, stderr=PIPE) tee = Popen([tee, /dev/stderr], stdin=sudo.stderr, stdout=PIPE) # Read from tee.stdout to get any error messages Further info: http://en.wikipedia.org/wiki/Tee_%28command%29 Cheers, Chris mmm, it doesn't seem to work... any other hints guys? -- http://mail.python.org/mailman/listinfo/python-list
Re: bash command, get stdErr
On Fri, Aug 26, 2011 at 12:56 AM, Tracubik affdfsdfds...@b.com wrote: Il Thu, 25 Aug 2011 01:52:25 -0700, Chris Rebert ha scritto: On Thu, Aug 25, 2011 at 1:25 AM, Tracubik affdfsdfds...@b.com wrote: Hi all! cut Untested: from subprocess import Popen, PIPE sudo = Popen(sudo las, shell=True, stderr=PIPE) tee = Popen([tee, /dev/stderr], stdin=sudo.stderr, stdout=PIPE) # Read from tee.stdout to get any error messages Further info: http://en.wikipedia.org/wiki/Tee_%28command%29 mmm, it doesn't seem to work... How so? Seems to work in an admittedly dirt simple test where I do tee.stdout.read(). You might need to fiddle with buffering settings depending on how you're processing the output. Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: bash command, get stdErr
Il Thu, 25 Aug 2011 08:25:59 +, Tracubik ha scritto:
Hi all!
i'ld like to execute via Python this simple bash command:
sudo las
las is intended to be a typo for ls
the point is that i want to see in the terminal the stderr message (that
is sorry, try again if i insert the wrong password or sudo: las:
command not found otherwise)
i can simply do it with subprocess.POpen() or subprocess.Call() but as
far as i know i have two choice:
1) s = subprocess.Popen('sudo las', shell=True, stderr=subprocess.PIPE)
in this way i catch the stderr messages BUT they are not printed in
the terminal
2) s = subprocess.Popen('sudo las', shell=True, stderr=none)
in this way i print the message in the terminal but i can retrieve
they (the error messages) when the command is executed
maybe i've solved it:
sudo las 21 | tee tmp.txt
in this way i redirect stderr to stdout (the terminal) and i tee it in
tmp.txt.
The only problem is the output and error messages are joined togheter but
i think i can deal with it.
:-D
MedeoTL
--
http://mail.python.org/mailman/listinfo/python-list
How to handle application level errors
Hi Guys, Not sure if this is the place to ask, but I am trying find out a way to handle application level errors from a global config. Any help would be really appreciated. Regards, Nav -- http://mail.python.org/mailman/listinfo/python-list
Re: bash command, get stdErr
Il Fri, 26 Aug 2011 01:20:02 -0700, Chris Rebert ha scritto: On Fri, Aug 26, 2011 at 12:56 AM, Tracubik affdfsdfds...@b.com wrote: Il Thu, 25 Aug 2011 01:52:25 -0700, Chris Rebert ha scritto: On Thu, Aug 25, 2011 at 1:25 AM, Tracubik affdfsdfds...@b.com wrote: Hi all! cut Untested: from subprocess import Popen, PIPE sudo = Popen(sudo las, shell=True, stderr=PIPE) tee = Popen([tee, /dev/stderr], stdin=sudo.stderr, stdout=PIPE) # Read from tee.stdout to get any error messages Further info: http://en.wikipedia.org/wiki/Tee_%28command%29 mmm, it doesn't seem to work... How so? Seems to work in an admittedly dirt simple test where I do tee.stdout.read(). You might need to fiddle with buffering settings depending on how you're processing the output. oh, yeah! now it work thanks! don't really know why it wasn't working yesterday, i've retried today and it work very well :-D MedeoTL -- http://mail.python.org/mailman/listinfo/python-list
Re: PUT with proxy-support
Running pycurl-7.19.0/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-2ZCa8v/pycurl-7.19.0/egg-dist-tmp-DyHFls
Using curl-config (libcurl 7.12.1)
src/pycurl.c:42:20: Python.h: No such file or directory
src/pycurl.c:43:22: pythread.h: No such file or directory
src/pycurl.c:58:4: #error Need Python version 2.2 or greater to
compile pycurl.
src/pycurl.c:61:4: #error Need libcurl version 7.19.0 or greater to
compile pycurl.
[... Error Clipped]
error: Setup script exited with error: command '/usr/bin/gcc' failed
with exit status 1
I'm not familiar with red hat. But looks like this is now a sysadmin
problem. I could install pycurl under freebsd and ubuntu too.
I have some code that might be able to PUT through a proxy for you.
Please look at the attached file.
You can setup a proxy this way:
import MozzillaEmulator
MozzillaEmulator.DEFAULT_PROXIES = {
'http':'http://user:passw...@proxy.host.com:3128',
'https':'http://user:passw...@proxy.host.com:3128',
}
And here is how you use it:
dl = MozillaEmulator.MozillaEmulator()
put_url = http://some_url_to_put_to;
headers = {'Content-Type':'application/xml;charset=UTF-8'}
data = open(some_file,rb).read()
response = dl.download(put_url,data,headers,put_method=True)
If you don't set the put_method flag, then it will POST instead. (But in
that case, post data must be a valid post data field fields and values.)
If you don't give post_data then it will GET. The PUT method was tested
without a proxy, and the GET and POST methods were tested with and
without proxy.
Actually I have tried to do PUT through a proxy, but it didn't work. But
it was a restriction on the proxy side. (As far as I can recall, the
error message came from the proxy server, something about unsupported
request?). So it *might* work for you, with the right proxy server that
supports PUT requests.
Also be aware that this version uses urllib2. Although it can use https
protocol, it doesn't check the server's certificate.
Good luck,
Laszlo
#--
#
# Author: Laszlo Nagy
#
# Copyright: (c) 2005 by Szoftver Messias Bt.
# Licence: BSD style
#
# Setup urllib so it will use Mozilla user agent settings.
#
#
#--
import os
import hashlib
import urllib
import urllib2
import mimetypes
#from gzip import GzipFile
import cStringIO
from cPickle import loads,dumps
import cookielib
DEFAULT_PROXIES = None
class MozillaCacher(object):
A dictionary like object, that can cache results on a storage device.
def __init__(self,cachedir='.cache'):
self.cachedir = cachedir
if not os.path.isdir(cachedir):
os.mkdir(cachedir)
def name2fname(self,name):
return os.path.join(self.cachedir,name)
def __getitem__(self,name):
if not isinstance(name,str):
raise TypeError()
fname = self.name2fname(name)
if os.path.isfile(fname):
return file(fname,'rb').read()
else:
raise IndexError()
def __setitem__(self,name,value):
if not isinstance(name,str):
raise TypeError()
fname = self.name2fname(name)
if os.path.isfile(fname):
os.unlink(fname)
f = file(fname,'wb+')
try:
f.write(value)
finally:
f.close()
def __delitem__(self,name):
if not isinstance(name,str):
raise TypeError()
fname = self.name2fname(name)
if os.path.isfile(fname):
os.unlink(fname)
def __iter__(self):
raise NotImplementedError()
def has_key(self,name):
return os.path.isfile(self.name2fname(name))
class MozillaEmulator(object):
def __init__(self,cacher={},trycount=0,proxies=None):
Create a new MozillaEmulator object.
@param cacher: A dictionary like object, that can cache search results on a storage device.
You can use a simple dictionary here, but it is not recommended.
You can also put None here to disable caching completely.
@param trycount: The download() method will retry the operation if it fails. You can specify -1 for infinite retrying.
A value of 0 means no retrying. A value of 1 means one retry. etc.
:param proxies: It must be a dict like this:
{
'http': 'http://user:pas...@www.example.com:3128/',
'https': 'http://user:pas...@www.example.com:3128/',
}
If you pass None then DEFAULT_PROXIES will be used. To force
direct connection, use an empty dict.
This is a simplified version of urllib2 proxy handling.
To use direct connection, call with proxies=None.
Look at the example here:
http://docs.python.org/release/2.5.2/lib/urllib2-examples.html
Re: is there any principle when writing python function
In article c2fe3168-92b1-46a1-a176-0914f0ba9...@19g2000vbv.googlegroups.com, t...@thsu.org wrote: On Aug 23, 7:59 am, smith jack thinke...@gmail.com wrote: i have heard that function invocation in python is expensive, but make lots of functions are a good design habit in many other languages, so is there any principle when writing python function? for example, how many lines should form a function? My suggestion is to think how you would test the function, in order to get 100% code coverage. I'm not convinced 100% code coverage is an achievable goal for any major project. I was once involved in a serious code coverage program. We had a large body of code (100's of KLOC of C++) which we were licensing to somebody else. The customer was insisting that we do code coverage testing and set a standard of something like 80% coverage. There was a dedicated team of about 4 people working on this for the better part of a year. They never came close to 80%. More like 60%, and that was after radical surgery to eliminate dead code and branches that couldn't be reached. The hard parts are testing the code that deals with unusual error conditions caused by interfaces to the external world. The problem is, it's just damn hard to simulate all the different kinds of errors that can occur. This was network intensive code. Every call that touches the network can fail in all sorts of ways that are near impossible to simulate. We also had lots of code that tried to deal with memory exhaustion. Again, that's hard to simulate. I'm not saying code coverage testing is a bad thing. Many of the issues I mention above could have been solved with additional abstraction layers, but that adds complexity of its own. Certainly, designing a body of code to be testable from the get-go is a far superior to trying to retrofit tests to an existing code base (which is what we were doing). The parts of the function that are difficult to test, those are the parts that you want to pull out into their own separate function. For example, a block of code within a conditional statement, where the test condition cannot be passed in, is a prime example of a block of code that should be pulled out into a separate function. Maybe. In general, it's certainly true that a bunch of smallish functions, each of which performs exactly one job, is easier to work with than a huge ball of spaghetti code. On the other hand, interfaces are a common cause of bugs. When you pull a hunk of code out into its own function, you create a new interface. Sometimes that adds complexity (and bugs) of its own. Obviously, there are times where this is not practical - exception handling comes to mind - but that should be your rule of thumb. If a block of code is hard to test, pull it out into it's own function, so that it's easier to test. In general, that's good advice. You'll also usually find that code which is easy to test is also easy to understand and easy to modify. -- http://mail.python.org/mailman/listinfo/python-list
Mastering Python... Best Resources?
I know the Python syntax pretty well. I know a lot of the libraries and tools. When I see professional Python programmer's code, I am often blown away with the code. I realized that even though I know the language, I know nothing about using it effectively. I would like to start using Python more in my professional career. Where can I find resources that will take my skills to the next level? I would prefer to watch a streaming video series, if possible. I've read quite a few books about Python. They cover a lot of topics, but none of them covered common conventions or hacks. I mean, I got good at C++ reading books by Scott Meyers, who concentrated on common idioms, things to avoid, the proper way to do things, etc. Right now, I am at that point where I know how to do write just about anything in the language. However, I still have that hesitation I get when I'm just not sure what's the right way. -- http://mail.python.org/mailman/listinfo/python-list
Re: Mastering Python... Best Resources?
On Fri, Aug 26, 2011 at 10:33 PM, Travis Parks jehugalea...@gmail.com wrote: I know the Python syntax pretty well. I know a lot of the libraries and tools. When I see professional Python programmer's code, I am often blown away with the code. I realized that even though I know the language, I know nothing about using it effectively. I would say that there are three aspects to using Python effectively: 1) Understanding the syntax, which you've mastered. 2) Understanding the philosophy 3) Knowing algorithms. The second is more or less what you're asking for, but the language-independent third may be more useful to you. This is correct Python syntax (#1), and decently Pythonic style (#2), but a hopelessly flawed algorithm (#3): def fib(x): return fib(x-1) + fib(x-2) if x2 else 1 Or: def fib(x): if x3: return 1 return fib(x-1) + fib(x-2) Both versions are clean and easy to read, but neither would be what I'd call brilliant code. You can get books on algorithms from all sorts of places, and with a very few exceptions, everything you learn with apply to Python and also to every other language you use. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: PUT with proxy-support
On Fri, Aug 26, 2011 at 3:15 PM, Laszlo Nagy gand...@shopzeus.com wrote:
Running pycurl-7.19.0/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-2ZCa8v/**pycurl-7.19.0/egg-dist-tmp-**DyHFls
Using curl-config (libcurl 7.12.1)
src/pycurl.c:42:20: Python.h: No such file or directory
src/pycurl.c:43:22: pythread.h: No such file or directory
src/pycurl.c:58:4: #error Need Python version 2.2 or greater to compile
pycurl.
src/pycurl.c:61:4: #error Need libcurl version 7.19.0 or greater to
compile pycurl.
[... Error Clipped]
error: Setup script exited with error: command '/usr/bin/gcc' failed with
exit status 1
I'm not familiar with red hat. But looks like this is now a sysadmin
problem. I could install pycurl under freebsd and ubuntu too.
I have some code that might be able to PUT through a proxy for you. Please
look at the attached file.
You can setup a proxy this way:
import MozzillaEmulator
MozzillaEmulator.DEFAULT_**PROXIES = {
'http':'http://user:password@**proxy.host.com:3128http://user:passw...@proxy.host.com:3128
',
'https':'http://user:password@**proxy.host.com:3128http://user:passw...@proxy.host.com:3128
',
}
And here is how you use it:
dl = MozillaEmulator.**MozillaEmulator()
put_url = http://some_url_to_put_to;
headers = {'Content-Type':'application/**xml;charset=UTF-8'}
data = open(some_file,rb).read()
response = dl.download(put_url,data,**headers,put_method=True)
If you don't set the put_method flag, then it will POST instead. (But in
that case, post data must be a valid post data field fields and values.) If
you don't give post_data then it will GET. The PUT method was tested without
a proxy, and the GET and POST methods were tested with and without proxy.
Actually I have tried to do PUT through a proxy, but it didn't work. But it
was a restriction on the proxy side. (As far as I can recall, the error
message came from the proxy server, something about unsupported request?).
So it *might* work for you, with the right proxy server that supports PUT
requests.
Also be aware that this version uses urllib2. Although it can use https
protocol, it doesn't check the server's certificate.
Mozilla Emulator works like a charm.
Also managed to install pycurl and the same works too.
Thanks. :)
~Shashwat
--
http://mail.python.org/mailman/listinfo/python-list
Re: Learning python reading software source code
Thanks Michael :) . I will keep your suggestions in mind. On Fri, Aug 26, 2011 at 9:01 AM, Chetan Harjani chetan.harj...@gmail.comwrote: Hello friends, I have learned the basic syntax of python through the book HOW TO THINK LIKE A COMPUTER SCIENTIST n by reading first 10-11 chapters of Apress-BEGINNING PROGRAMMING FROM NOVICE TO PROFESSIONAL. (btw it was really very boring) I am looking forward to learn further by understanding source code of applications built in python. I guess i will begin with reading the source code of MIRO http://www.getmiro.com/ . So I am looking for suggestions on how one can understand the code better. Any specific references I should look in as I stumble upon libraries n functions while reading or just the python official docs would be enough? thanking you -- Chetan H Harjani -- Chetan H Harjani -- http://mail.python.org/mailman/listinfo/python-list
Re: Mastering Python... Best Resources?
Chris Angelico wrote: [ ... ] You can get books on algorithms from all sorts of places, and with a very few exceptions, everything you learn with apply to Python and also to every other language you use. I liked _Programming Pearls_ by Jon Bentley. No reference to Python -- that would be the O.P.'s job. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: Mastering Python... Best Resources?
On Aug 26, 8:44 am, Chris Angelico ros...@gmail.com wrote: On Fri, Aug 26, 2011 at 10:33 PM, Travis Parks jehugalea...@gmail.com wrote: I know the Python syntax pretty well. I know a lot of the libraries and tools. When I see professional Python programmer's code, I am often blown away with the code. I realized that even though I know the language, I know nothing about using it effectively. I would say that there are three aspects to using Python effectively: 1) Understanding the syntax, which you've mastered. 2) Understanding the philosophy 3) Knowing algorithms. The second is more or less what you're asking for, but the language-independent third may be more useful to you. This is correct Python syntax (#1), and decently Pythonic style (#2), but a hopelessly flawed algorithm (#3): def fib(x): return fib(x-1) + fib(x-2) if x2 else 1 Or: def fib(x): if x3: return 1 return fib(x-1) + fib(x-2) Both versions are clean and easy to read, but neither would be what I'd call brilliant code. You can get books on algorithms from all sorts of places, and with a very few exceptions, everything you learn with apply to Python and also to every other language you use. ChrisA Well, I think I am going more for #2. I know about things like data structures and algorithms... in your case memoization. Here is a good example of what I am talking about. Someone took the time to write quicksort in a single line of code: def qsortr(list): return [] if list==[] else qsortr([x for x in list[1:] if x list[0]]) + [list[0]] + qsortr([x for x in list[1:] if x = list[0]]) I would never even think to use list comprehensions and splicing like that. I would write this code the same way I'd write it in C++/C#. I'm aware that writing code like the above example is probably bad practice (and that the implementation here has some major inefficiencies), but it is the mentality that goes into it. I haven't gotten to the point where I can truly use the language features to my full advantage. I haven't seen enough tricks to be effective. I feel like there is so much of the language I am not utilizing because I'm still thinking in terms of a less powerful language. I was hoping to find a series that would familiarize me with how real Python programmers get things done. -- http://mail.python.org/mailman/listinfo/python-list
Re: Mastering Python... Best Resources?
On Fri, Aug 26, 2011 at 10:58 PM, Travis Parks jehugalea...@gmail.com wrote: I haven't gotten to the point where I can truly use the language features to my full advantage. I haven't seen enough tricks to be effective. I feel like there is so much of the language I am not utilizing because I'm still thinking in terms of a less powerful language. I was hoping to find a series that would familiarize me with how real Python programmers get things done. Ah! Then I recommend poking around with the standard library. No guarantees that it's ALL good code, but it probably will be. In any case, it sounds like you're well able to evaluate code in your own head and recognize the good from the ugly. In the source distribution (I'm looking at the latest straight from hg, but presumably it's the same everywhere), there's a whole lot of .py files in ./Lib - there's sure to be some good examples in there somewhere. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Mastering Python... Best Resources?
On Fri, Aug 26, 2011 at 2:28 PM, Chris Angelico ros...@gmail.com wrote: On Fri, Aug 26, 2011 at 10:58 PM, Travis Parks jehugalea...@gmail.com wrote: I haven't gotten to the point where I can truly use the language features to my full advantage. I haven't seen enough tricks to be effective. I feel like there is so much of the language I am not utilizing because I'm still thinking in terms of a less powerful language. I was hoping to find a series that would familiarize me with how real Python programmers get things done. Ah! Then I recommend poking around with the standard library. No guarantees that it's ALL good code, but it probably will be. In any case, it sounds like you're well able to evaluate code in your own head and recognize the good from the ugly. In the source distribution (I'm looking at the latest straight from hg, but presumably it's the same everywhere), there's a whole lot of .py files in ./Lib - there's sure to be some good examples in there somewhere. ChrisA As a rule of thumb, I have learnt to always make the python source my best resource. -- http://mail.python.org/mailman/listinfo/python-list -- Odeyemi 'Kayode O. http://www.sinati.com. t: @charyorde -- http://mail.python.org/mailman/listinfo/python-list
Re: Mastering Python... Best Resources?
On Aug 26, 9:28 am, Chris Angelico ros...@gmail.com wrote: On Fri, Aug 26, 2011 at 10:58 PM, Travis Parks jehugalea...@gmail.com wrote: I haven't gotten to the point where I can truly use the language features to my full advantage. I haven't seen enough tricks to be effective. I feel like there is so much of the language I am not utilizing because I'm still thinking in terms of a less powerful language. I was hoping to find a series that would familiarize me with how real Python programmers get things done. Ah! Then I recommend poking around with the standard library. No guarantees that it's ALL good code, but it probably will be. In any case, it sounds like you're well able to evaluate code in your own head and recognize the good from the ugly. In the source distribution (I'm looking at the latest straight from hg, but presumably it's the same everywhere), there's a whole lot of .py files in ./Lib - there's sure to be some good examples in there somewhere. ChrisA I've been thinking about going through the docs on the main website. Cool thing is it has links to the actual lib files. I was checking out string.py yesterday. I was searching all over youtube for good videos of some type. Google has an intro course, but it didn't really do much for me. Microsoft has these series called 'Going Deep' that occasionally runs something super in-depth. The videos on C++ and the STL are really excellent. I was hoping someone had taken the time to create a similar series for Python. I can't help but remember my one professor in college, who really made pointers, bitwise arithmetic and low level OS operations make sense. He explained to us a lot about how the STL worked and showed us tons of C++/STL hacks. I probably learned more in the 2 years I had classes with him than I have in all the time I've programmed. To get that type of insight into another language, like Python, would be the ultimate gift for someone like me. Personally, I am tired of working in languages that don't strongly support functional paradigms. -- http://mail.python.org/mailman/listinfo/python-list
Python IDE/Eclipse
I'm looking for a good IDE -- easy to setup, easy to use -- for Python. Any suggestions? I use Eclipse for other projects and have no problem with using it for Python, except that I can't get PyDev to install. It takes forever, then produces an error that makes no sense. An error occurred while installing the items session context was:(profile=PlatformProfile, phase=org.eclipse.equinox.internal.provisional.p2.engine.phases.Install, operand=null -- [R]org.eclipse.cvs 1.0.400.v201002111343, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction). Cannot connect to keystore. This trust engine is read only. The artifact file for osgi.bundle,org.eclipse.cvs,1.0.400.v201002111343 was not found. Any suggestions on getting this to work? Thanks, Dave -- http://mail.python.org/mailman/listinfo/python-list
dpkg
I downloaded cx_oracle for installation to Ubuntu 11.04 64bit this morning, and the alien and dpkg operations worked fine, but on testing the import, the error msg shows that the oracle client lib is missing. I found a thread that mentioned installing the oracle instant client on 11.04 to resolve this, and alien and dpkg worked fine. Yet, when I go into python (runing 2.7) and import cx_Oracle, I get ImportError: libclntsh.so.11.1: cannot open shared object file: No such file or directory. Looking for this with find / -name libclntsh.so.11.1 -print produces /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 I'm confused as to why Python doesn't see it... -- http://mail.python.org/mailman/listinfo/python-list
Re: Mastering Python... Best Resources?
In article
2309ec4b-e9a3-4330-9983-1c621ac16...@ea4g2000vbb.googlegroups.com,
Travis Parks jehugalea...@gmail.com wrote:
I know the Python syntax pretty well. I know a lot of the libraries
and tools. When I see professional Python programmer's code, I am
often blown away with the code. I realized that even though I know the
language, I know nothing about using it effectively.
In a sense, I'm in the same boat as you. I've been using Python since
before the 2.0 series, and I tend to think of the language in much the
same way as I did back then. Which is to say I don't use the language,
as it currently exists, as effectively as I might.
Here's some things I suggest you look at:
Iterators. This is such a powerful concept. When I started with the
language, iterators largely meant the difference between range() and
xrange(). Now we've got a whole ecosystem which has grown up around
them (x + comprehension for x in {'list', 'dictionary', 'set'}), not
to mention generators and generator expressions. And the itertools
library.
Decorators. Another powerful concept. We use these in our web servers
for all sorts of cool things. Adding cacheing. Imposing prerequisites
on route calls. I still don't think of using these immediately, but I
do see the notational convenience they provide for many things.
Context Managers. One of the (very few) things that I always found
lacking in Python compared to C++ was deterministic object destruction.
Context managers give you this. I'm still exploring all the neat things
you can do with them.
The full range of containers. I started with lists, tuples, and
dictionaries. Now we've got sets, frozensets, named tuples, deques,
Counters, defaultdicts (I love those), heaps, and I'm sure a few others
I've missed. List and dicts are such well designed containers, you can
do almost anything with just those two, but all the other new ones often
make things quicker, simpler, and more obvious.
The profiler. Most people obsess about performance early on and don't
realize that most of their guesses about what's fast and what's slow are
probably wrong. Learn to use the profiler and understand what it's
telling you.
Unittest. Testing is, in general, a neglected practice in most software
development shops, and that's a shame. Python has some really good
capabilities to support testing which you should get familiar with.
Unittest is just one of them. There's also doctest, nose, and a bunch
of other contributed modules. Look at them all, learn at least one of
them well, and use it for everything you write.
I've read quite a few books about Python. They cover a lot of topics,
but none of them covered common conventions or hacks. I mean, I got
good at C++ reading books by Scott Meyers, who concentrated on common
idioms, things to avoid, the proper way to do things, etc.
Ugh. The problem with Meyers's books is that they are needed in the
first place. C++ is such a horribly complicated language, you really
can't use it without making a serious study of it. There's too many
gotchas that you MUST know to avoid disaster with even the most basic
programs.
Python isn't that way. You can learn a small, basic subset of the
language and get a lot done. You may not be doing things the most
effective way, but you're also not going to be looking at memory
corruption because you didn't understand the details of object lifetimes
or how type promotion, function overloading, and implicit temporary
object construction all interact.
--
http://mail.python.org/mailman/listinfo/python-list
Re: dpkg
On Fri, Aug 26, 2011 at 10:43 AM, Verde Denim tdl...@gmail.com wrote: Looking for this with find / -name libclntsh.so.11.1 -print produces /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 I'm confused as to why Python doesn't see it... Try running sudo ldconfig. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/Eclipse
I've honestly always used either PyDev or IDLE. However, Python is pretty easy to usd without a big IDE slowing you down, so you could also use a developer's text editor like Notepad++ or gedit and still be good. -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
On Aug 26, 6:15 am, Roy Smith r...@panix.com wrote: Maybe. In general, it's certainly true that a bunch of smallish functions, each of which performs exactly one job, is easier to work with than a huge ball of spaghetti code. Obviously you need to google the definition of spaghetti code. When you move code out of one function and create another function you are contributing to the spaghetti-ness of the code. Think of plate of spaghetti and how the noodles are all intertwined and without order. Likewise when you go to one function and have to follow the trial of one or more helper functions you are creating a twisting and unordered progression of code -- sniff-sniff, do you smell what i smell? Furthermore: If you are moving code out of one function to ONLY be called by that ONE function then you are a bad programmer and should have your editor taken away for six months. You should ONLY create more func/methods if those func/methods will be called from two or more places in the code. The very essence of func/meths is the fact that they are reusable. It might still be spaghetti under that definition (of which ALL OOP code actually is!) however it will be as elegant as spaghetti can be. On the other hand, interfaces are a common cause of bugs. When you pull a hunk of code out into its own function, you create a new interface. Sometimes that adds complexity (and bugs) of its own. Which is it? You cannot have it both ways. You're straddling the fence here like a dirty politician. Yes, this subject IS black and white! -- http://mail.python.org/mailman/listinfo/python-list
Re: dpkg
On Fri, Aug 26, 2011 at 11:17 AM, Ken Watford kwatf...@gmail.com wrote: On Fri, Aug 26, 2011 at 10:43 AM, Verde Denim tdl...@gmail.com wrote: Looking for this with find / -name libclntsh.so.11.1 -print produces /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 I'm confused as to why Python doesn't see it... Try running sudo ldconfig. That was the missing link - thanks! works fine now. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/Eclipse
I like Aptana Studio http://www.aptana.com/products/studio3 2011/8/26 Dave Boland dbola...@fastmail.fm: I'm looking for a good IDE -- easy to setup, easy to use -- for Python. Any suggestions? I use Eclipse for other projects and have no problem with using it for Python, except that I can't get PyDev to install. It takes forever, then produces an error that makes no sense. An error occurred while installing the items session context was:(profile=PlatformProfile, phase=org.eclipse.equinox.internal.provisional.p2.engine.phases.Install, operand=null -- [R]org.eclipse.cvs 1.0.400.v201002111343, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction). Cannot connect to keystore. This trust engine is read only. The artifact file for osgi.bundle,org.eclipse.cvs,1.0.400.v201002111343 was not found. Any suggestions on getting this to work? Thanks, Dave -- http://mail.python.org/mailman/listinfo/python-list -- Atte. Moisés Alberto Lindo Gutarra Asesor - Desarrollador Java / Open Source Linux Registered User #431131 - http://counter.li.org/ Cel: (511) 995081720 - Rpm: *548913 EMail: mli...@gmail.com MSN: mli...@tumisolutions.com -- http://mail.python.org/mailman/listinfo/python-list
Unit test failing please help
Hi I am new to python I am at bit lost as to why my unit test is
failing below is the code and the unit test:
class Centipede(object):
legs, stomach
def __init__(self):
def __str__(self):
return ','.join(self.stomach)
def __call__(self,*args):
[self.stomach.append(arg) for arg in args]
#self.stomach.append(args)
def __repr__(self):
return ','.join(self.legs)
def __setattr__(self, key, value):
print(setting %s to %s % (key, repr(value)))
if key in ([]):
self.legs.append(key)
super(Centipede, self).__setattr__(self, key,value)
unit test code:
import unittest
from centipede import Centipede
class TestBug(unittest.TestCase):
def test_stomach(self):
ralph = Centipede()
ralph('chocolate')
ralph('bbq')
ralph('cookies')
ralph('salad')
self.assertEquals(ralph.__str__(),
'chocolate,bbq,cookies,salad')
def test_legs(self):
ralph = Centipede()
ralph.friends = ['Steve', 'Daniel', 'Guido']
ralph.favorite_show = Monty Python's Flying Circus
ralph.age = '31'
self.assertEquals(ralph.__repr__(),'friends,favorite_show,age' )
if __name__ == __main__:
unittest.main()
error message generated when running the test:
AttributeError: 'Centipede' object has no attribute 'legs'
AttributeError: 'Centipede' object has no attribute 'stomach'
Any suggestions as to where I am going wrong?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Mastering Python... Best Resources?
On Aug 26, 11:12 am, Roy Smith r...@panix.com wrote:
In article
2309ec4b-e9a3-4330-9983-1c621ac16...@ea4g2000vbb.googlegroups.com,
Travis Parks jehugalea...@gmail.com wrote:
I know the Python syntax pretty well. I know a lot of the libraries
and tools. When I see professional Python programmer's code, I am
often blown away with the code. I realized that even though I know the
language, I know nothing about using it effectively.
In a sense, I'm in the same boat as you. I've been using Python since
before the 2.0 series, and I tend to think of the language in much the
same way as I did back then. Which is to say I don't use the language,
as it currently exists, as effectively as I might.
Here's some things I suggest you look at:
Iterators. This is such a powerful concept. When I started with the
language, iterators largely meant the difference between range() and
xrange(). Now we've got a whole ecosystem which has grown up around
them (x + comprehension for x in {'list', 'dictionary', 'set'}), not
to mention generators and generator expressions. And the itertools
library.
Decorators. Another powerful concept. We use these in our web servers
for all sorts of cool things. Adding cacheing. Imposing prerequisites
on route calls. I still don't think of using these immediately, but I
do see the notational convenience they provide for many things.
Context Managers. One of the (very few) things that I always found
lacking in Python compared to C++ was deterministic object destruction.
Context managers give you this. I'm still exploring all the neat things
you can do with them.
The full range of containers. I started with lists, tuples, and
dictionaries. Now we've got sets, frozensets, named tuples, deques,
Counters, defaultdicts (I love those), heaps, and I'm sure a few others
I've missed. List and dicts are such well designed containers, you can
do almost anything with just those two, but all the other new ones often
make things quicker, simpler, and more obvious.
The profiler. Most people obsess about performance early on and don't
realize that most of their guesses about what's fast and what's slow are
probably wrong. Learn to use the profiler and understand what it's
telling you.
Unittest. Testing is, in general, a neglected practice in most software
development shops, and that's a shame. Python has some really good
capabilities to support testing which you should get familiar with.
Unittest is just one of them. There's also doctest, nose, and a bunch
of other contributed modules. Look at them all, learn at least one of
them well, and use it for everything you write.
I've read quite a few books about Python. They cover a lot of topics,
but none of them covered common conventions or hacks. I mean, I got
good at C++ reading books by Scott Meyers, who concentrated on common
idioms, things to avoid, the proper way to do things, etc.
Ugh. The problem with Meyers's books is that they are needed in the
first place. C++ is such a horribly complicated language, you really
can't use it without making a serious study of it. There's too many
gotchas that you MUST know to avoid disaster with even the most basic
programs.
Python isn't that way. You can learn a small, basic subset of the
language and get a lot done. You may not be doing things the most
effective way, but you're also not going to be looking at memory
corruption because you didn't understand the details of object lifetimes
or how type promotion, function overloading, and implicit temporary
object construction all interact.
Thanks for the input.
I had been writing my Compass project (http://compass.codeplex.com) in
Pythonese. I was planning on implementing a lot of the features of MS'
LINQ in Python iterators, too. I am surprised that there aren't a ton
of Python libraries for general purpose algorithms. yield is one of
my favorite keywords. :-)
I will take a look at decorators especially. I see them being used for
properties and other coolness. I started playing with unittest the
other day.
unittest.main(exit=False) -- took me a while to find
I will look at the containers, too. I have been trying to push tuple
syntax support in C# for years now. Named tuples are so useful.
I agree that C++ is too complicated. Bjarne should have cared less
about backward compatibility with C and fixed some of the issues with
it. He should have also made some of the defaults more intuitive -
like ctor initializers being reorganized to the same order as the
backing fields... that'll getcha. Function argument order evaluation.
Oh no! It might run .1 seconds slower on a Sparc machine! I think
anal programmers like me gravitate towards C++ because we like to show
how smart we are by naming off some arbitrary fact. Sure, it doesn't
make development any better, but it gives us something to waste memory
with. I find myself getting super excited when I get to use
Re: is there any principle when writing python function
In 7b47ca17-d3f1-4d91-91d1-98421e870...@ea4g2000vbb.googlegroups.com rantingrick rantingr...@gmail.com writes: Furthermore: If you are moving code out of one function to ONLY be called by that ONE function then you are a bad programmer and should have your editor taken away for six months. You should ONLY create more func/methods if those func/methods will be called from two or more places in the code. The very essence of func/meths is the fact that they are reusable. That's one very important aspect of functions, yes. But there's another: abstraction. If I'm writing a module that needs to fetch user details from an LDAP server, it might be worthwhile to put all of the LDAP-specific code in its own method, even if it's only used once. That way the main module can just contain a line like this: user_info = get_ldap_results(cn=john gordon,ou=people,dc=company,dc=com) The main module keeps a high level of abstraction instead of descending into dozens or even hundreds of lines of LDAP-specific code. -- John Gordon A is for Amy, who fell down the stairs gor...@panix.com B is for Basil, assaulted by bears -- Edward Gorey, The Gashlycrumb Tinies -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/Eclipse
On Aug 26, 2011 11:39 AM, Moises Alberto Lindo Gutarra mli...@gmail.com wrote: I like Aptana Studio http://www.aptana.com/products/studio3 FYI, Aptana is just a set of extensions for Eclipse. Aptana Studio is just Eclipse with all of the Aptana extensions (including PyDev) preinstalled. 2011/8/26 Dave Boland dbola...@fastmail.fm: I'm looking for a good IDE -- easy to setup, easy to use -- for Python. Any suggestions? I use Eclipse for other projects and have no problem with using it for Python, except that I can't get PyDev to install. It takes forever, then produces an error that makes no sense. An error occurred while installing the items session context was:(profile=PlatformProfile, phase=org.eclipse.equinox.internal.provisional.p2.engine.phases.Install, operand=null -- [R]org.eclipse.cvs 1.0.400.v201002111343, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction). Cannot connect to keystore. This trust engine is read only. The artifact file for osgi.bundle,org.eclipse.cvs,1.0.400.v201002111343 was not found. Any suggestions on getting this to work? Thanks, Dave -- http://mail.python.org/mailman/listinfo/python-list -- Atte. Moisés Alberto Lindo Gutarra Asesor - Desarrollador Java / Open Source Linux Registered User #431131 - http://counter.li.org/ Cel: (511) 995081720 - Rpm: *548913 EMail: mli...@gmail.com MSN: mli...@tumisolutions.com -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
Furthermore: If you are moving code out of one function to ONLY be called by that ONE function then you are a bad programmer and should have your editor taken away for six months. You should ONLY create more func/methods if those func/methods will be called from two or more places in the code. The very essence of func/meths is the fact that they are reusable. While I understand and agree with that basic tenet, I think that the capitalized 'ONLY' is too strong. I do split out code into function for readability, even when the function will only be called from the place from which I split it out. I don't think that this adds to the 'spaghetti' factor. It can make my life much easier when I go to debug my own code years later. In python, I use a small function to block out an idea as a sort of pseudo code, although it's valid python. Then I just define the supporting functions, and the task is done: def validate_registrants(): for dude in get_registrants(): id = get_id(dude) amount_paid = get_amount_paid(dude) amount_owed = get_amount_owed(dude) if amount_paid != amount_owed(): flag(dude) I get that this cries out for a 'dude' object, but I'm just making a point. When I go back to this code, I can very quickly see what the overall flow is, and jump to the problem area by function name. The above block might expand to a couple of hundred lines if I didn't split it out like this. -- http://mail.python.org/mailman/listinfo/python-list
Hot Bollwood Actresses and Hot Football Players of Spain Soccer Team
Hot Bollywood Actresses and Hot Football Players of Spain Nation Soccer Team. http://bollywoodactresseshotdresses.blogspot.com/ http://spainnationalfootballteamwallpapers.blogspot.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Unit test failing please help
In ccbce61b-77e3-44fc-bbb8-fbd700732...@w28g2000yqw.googlegroups.com lblake treleven.ll...@gmail.com writes: Hi I am new to python I am at bit lost as to why my unit test is failing below is the code and the unit test: class Centipede(object): legs, stomach You aren't assigning any values to legs or stomach here. From your later code, it seems like you intend these items to start out as empty lists. This code might work better: class Centipede(object): legs = [] stomach = [] (In fact, since you aren't *assigning* anything to legs or stomach but you're simply *referencing them*, this code should have been an error because those names do not yet exist.) def __init__(self): This __init__() method does nothing at all. It doesn't even have a pass statement, which means it isn't legal python. Your code should have produced an error here. def __setattr__(self, key, value): print(setting %s to %s % (key, repr(value))) if key in ([]): self.legs.append(key) super(Centipede, self).__setattr__(self, key,value) How will this if statement ever be true? You're checking if 'key' is a member of an empty list. -- John Gordon A is for Amy, who fell down the stairs gor...@panix.com B is for Basil, assaulted by bears -- Edward Gorey, The Gashlycrumb Tinies -- http://mail.python.org/mailman/listinfo/python-list
Re: Design principles: no bool arguments
Ian Kelly wrote: Thomas 'PointedEars' Lahn wrote: Both variants work (even in Py3) if you only define [a named argument]. You have to define [a keyword argument, e.g. `kwargs']. so that data1.merge_with(data2, True); is a syntax error (TypeError: merge_with() takes exactly 2 arguments (3 given)). IOW, this advantage of Python in readability is not only caused by API definition, but also by how the API is used. It might turn into a disadvantage if key lookups make the code expensive memory- and runtime wise. And you will still have to know the underlying signature to name the argument. Worse, with keyword arguments you *have to* look up the documentation (i. e., it needs to be well-documented as well) to know its name (as the compiler can only tell you kwargs). Note though that Python 3 adds actual keyword-only arguments, which address all of your points: class Data: def merge_with(self, bar, *, overwrite_duplicates): pass data1.merge_with(data2, True) TypeError: merge_with() takes exactly 2 positional arguments (3 given) data1.merge_with(data2) TypeError: merge_with() needs keyword-only argument overwrite_duplicates data1.merge_with(data2, overwrite_duplicates=True) That's good to know. Thanks. Of course, in Python 2 that definition would be a syntax error, so you can't really take advantage of it if you need compatibility. ACK. Regards, -- PointedEars Bitte keine Kopien per E-Mail. / Please do not Cc: me. -- http://mail.python.org/mailman/listinfo/python-list
Why PyImport_ExecCodeModule takes char*?
Hi, I'm wondering, why PyImport_ExecCodeModule function takes char* instead of const char*? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
On Sat, Aug 27, 2011 at 1:48 AM, Tobiah tob...@teranews.com wrote: While I understand and agree with that basic tenet, I think that the capitalized 'ONLY' is too strong. I do split out code into function for readability, even when the function will only be called from the place from which I split it out. This can be good and can be bad. It's good when it aids readability; it's bad when you need to pass practically the entire locals() as function arguments and/or return values. I would split the function only when both halves (caller and callee) can be given short and useful names - if you can't explain what a block of code does in a few words, it's probably a poor choice for splitting out into a function. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/Eclipse
You can get a lot done, if not everything, with a simple editor however for me an IDE is awesome for digging around in the django internals to see how it all works. I used PyDev initially then onto emacs but finally I settled on PyCharm - it's just like PyDev except that everything works. Stuart I like Aptana Studio http://www.aptana.com/products/studio3 2011/8/26 Dave Boland dbola...@fastmail.fm: I'm looking for a good IDE -- easy to setup, easy to use -- for Python. Any suggestions? I use Eclipse for other projects and have no problem with using it for Python, except that I can't get PyDev to install. It takes forever, then produces an error that makes no sense. An error occurred while installing the items session context was:(profile=PlatformProfile, phase=org.eclipse.equinox.internal.provisional.p2.engine.phases.Install, operand=null -- [R]org.eclipse.cvs 1.0.400.v201002111343, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction). Cannot connect to keystore. This trust engine is read only. The artifact file for osgi.bundle,org.eclipse.cvs,1.0.400.v201002111343 was not found. Any suggestions on getting this to work? Thanks, Dave -- http://mail.python.org/mailman/listinfo/python-list -- Atte. Moisés Alberto Lindo Gutarra Asesor - Desarrollador Java / Open Source Linux Registered User #431131 - http://counter.li.org/ Cel: (511) 995081720 - Rpm: *548913 EMail: mli...@gmail.com MSN: mli...@tumisolutions.com -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Unit test failing please help
On Fri, 2011-08-26 at 08:35 -0700, lblake wrote: Hi I am new to python I am at bit lost as to why my unit test is failing below is the code and the unit test: class Centipede(object): legs, stomach This doesn't do what you think it does. legs, stomach is a statement and is not defining any variables at all. Presumably you've also got variables named legs and stomach in the module's scope - as I'd expect to see a NameError : name 'legs' is not defined. (I'd also expect a SyntaxError from having an empty __init__ function body) You probably want do write something like this: class Centipede(object): def __init__(self): self.legs = [] self.stomach = [] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/Eclipse
Dave Boland wrote: I'm looking for a good IDE -- easy to setup, easy to use -- for Python. Any suggestions? PyDev (currently 2.2.1.2011073123, from the Aptana Studio 3.0.4 Plugin; but I can see that 2.2.2 has been released). I use Eclipse for other projects and have no problem with using it for Python, except that I can't get PyDev to install. It takes forever, then produces an error that makes no sense. An error occurred while installing the items session context was:(profile=PlatformProfile, phase=org.eclipse.equinox.internal.provisional.p2.engine.phases.Install, operand=null -- [R]org.eclipse.cvs 1.0.400.v201002111343, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction). Cannot connect to keystore. This trust engine is read only. The artifact file for osgi.bundle,org.eclipse.cvs,1.0.400.v201002111343 was not found. Any suggestions on getting this to work? Your Eclipse version is apparently a bit old (note the build/sign date of the requested CVS package). Although PyDev is documented to work with Eclipse 3.2 to 3.7, try a newer version (but make a backup of your workspace before). Indigo (3.7) was released on 2011-06-22 CE. The corresponding CVS package version is (perhaps with updates) 3.3.400.I20110510-0800. If you use PyDev from Aptana, you have to uninstall standalone PyDev first. I can still recommend using Aptana for Eclipse 3.7 on GNU/Linux, where it is running without problems so far. However, in Eclipse 3.7 on Windows 7, after the latest Aptana update (3.0.4), PDT collided in their Content-Type settings with Aptana PHP Editor, so I had to uninstall the Aptana plugin in order to get any PHP editor working again. -- PointedEars Bitte keine Kopien per E-Mail. / Please do not Cc: me. -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
Tobiah wrote:
Furthermore: If you are moving code out of one function to ONLY be
called by that ONE function then you are a bad programmer and should
have your editor taken away for six months. You should ONLY create
more func/methods if those func/methods will be called from two or
more places in the code. The very essence of func/meths is the fact
that they are reusable.
While I understand and agree with that basic tenet, I think
that the capitalized 'ONLY' is too strong. I do split out
code into function for readability, even when the function
will only be called from the place from which I split it out.
In other words, you disagree. Which is good, because the text you quote is
terrible advice, and it is ironic that the person you quote judges others
as bad programmers when his advice is so bad.
I can think of at least five reasons apart from re-use why it might be
appropriate to pull out code into its own function or method even if it is
used in one place only:
(1) Extensibility. Just earlier today I turned one method into three:
def select(self):
response = input(self)
if response:
index = self.find(response)
else:
index = self.default
return self.menuitems[index-1]
turned into:
def choose(self, response):
if response:
index = self.find(response)
else:
index = self.default
return self.menuitems[index-1]
def raw_select(self):
return input(self)
def select(self):
return self.choose(self.raw_select())
I did this so that subclasses could override the behaviour of each component
individually, even though the caller is not expected to call raw_select or
choose directly. (I may even consider making them private.)
(2) Testing. It is very difficult to reach into the middle of a function and
test part of it. It is very difficult to get full test coverage of big
monolithic blocks of code: to ensure you test each path through a big
function, the number of test cases rises exponentially. By splitting it
into functions, you can test each part in isolation, which requires much
less work.
(3) Fault isolation. If you have a 100 line function that fails on line 73,
that failure may have been introduced way back in line 16. By splitting the
function up into smaller functions, you can more easily isolate where the
failure comes from, by checking for violated pre- and post-conditions.
(4) Maintainability. It's just easier to document and reason about a
function that does one thing, than one that tries to do everything. Which
would you rather work with, individual functions for:
buy_ingredients
clean_kitchen_work_area
wash_vegetables
prepare_ingredients
cook_main_course
fold_serviettes
make_desert
serve_meal
do_washing_up
etc., or one massive function:
prepare_and_serve_five_course_meal
Even if each function is only called once, maintenance is simpler if the
code is broken up into more easily understood pieces.
(5) Machine efficiency. This can go either way. Code takes up memory too,
and it may be easier for the compiler to work with 1000 small functions
than 1 big function. I've actually seen somebody write a single function so
big that Python couldn't import the module, because it ran out of memory
trying to compile it! (This function was *huge* -- the source code was many
megabytes in size.) I don't remember the details, but refactoring the
source code into smaller functions fixed it.
On the other hand, if you are tight for memory, 1 big function may have less
overhead than 1000 small functions; and these days, with even entry level
PCs often having a GB or more of memory, it is rare to come across a
function so big that the size of code matters. Even a 10,000 line function
is likely to be only a couple of hundred KB in size:
text = '\n'.join('print x+i' for i in range(1, 10001))
code = compile(text, '', 'exec')
sys.getsizeof(code.co_code) # size in bytes
90028
So that's four really good reasons for splitting code into functions, and
one borderline one, other than code re-use. There may be others.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Record seperator
Is there an equivelent for the AWK RS in Python? as in RS='\n\n' will seperate a file at two blank line intervals -- maus . . ... NO CARRIER -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
On Aug 26, 10:40 am, John Gordon gor...@panix.com wrote: In 7b47ca17-d3f1-4d91-91d1-98421e870...@ea4g2000vbb.googlegroups.com rantingrick rantingr...@gmail.com writes: Furthermore: If you are moving code out of one function to ONLY be called by that ONE function then you are a bad programmer and should have your editor taken away for six months. You should ONLY create more func/methods if those func/methods will be called from two or more places in the code. The very essence of func/meths is the fact that they are reusable. That's one very important aspect of functions, yes. But there's another: abstraction. [...] The main module keeps a high level of abstraction instead of descending into dozens or even hundreds of lines of LDAP-specific code. Exactly. I am not arguing against creating intuitive and simplistically elegant interfaces. I mean, lists *could* have only one method called apply(process, *args, **kw) which takes an argument like (append, value) or (index, 42) and has a long block of logic to handle the inputs however that would be a horrible interface. So in that respect i agree. We must weigh the entire interface from an empirical perspective. However i can be sure of one point: As you increase the number of methods you also increase the mental load required to understand that particular interface. An interface with a small number of methods will not suffer too terribly from one or two extra methods however at some point more methods just equals more confusion. It is a delicate balancing act that many programmers are not agile enough to juggle elegantly. Take for instance the interface for Grep, Search, and Replace dialogs in the idlelib which span two separate modules and have a mind numbing number of methods for such remedial things as creating buttons and entrys. All three dialogs look very similar and share many similarities. Now take a look at MY simple ONE module solution. It has JUST enough methods and NOT a single more! Yes the create widgets method is fairly long (weighing in at 80+ lines with comments!) however all of this code needs to be contained in ONE and ONLY one method. Heck if i wanted to get pendantic i could replace the five cb_*() methods with partials however MY interface is so intuitive there is no need. # START CODE class FindReplaceDialog(object): def __init__(self, textbox): [...] def create_widgets(self, type_): # Create toplevel dialog window. [...] # Create widgets belonging to both # search AND replace dialogs dialogs. [...] if type_ == 'replace': # Add widgets unique to replace # dialogs. [...] elif type_ == 'grep': # Add widgets unique to grep # dialogs. [...] # Load any initial values and states. [...] def show(self, type_='find'): self.create_widgets(type_) # Do any initial setup. def close(self, event=None): # destroy the dialog. def find_again(self, event=None): # Event callback bound to textbox. def find(self, target): # Search the buffer for target and # hilight if found. def replace(self, action='replace'): # Fetch the old and new strings and # mediate the work depending on the # action. [...] if action == 'replace+find': [...] elif action == 'replaceall': [...] def grep(): [...] def cb_grepbutton(self, event=None): self.grep(target.entry.get()) def cb_findbutton(self, event=None): self.find(target.entry.get()) def cb_replacebutton(self): self.replace(action='replace') def cb_replacefindbutton(self): self.replace(action='replace+find') def cb_replaceallbutton(self): self.replace(action='replaceall') # END CODE Now look at the three modules in idlelib (Grep Dialog, Search Dialog, and Replace Dialog) and ask yourself which is cleaner? Which is more intuiitve? Which is more professional? Which would you rather debug? *scholl-bell-rings* -- http://mail.python.org/mailman/listinfo/python-list
Re: Record seperator
On 26 Aug 2011 18:39:07 GMT greymaus greyma...@mail.com wrote: Is there an equivelent for the AWK RS in Python? as in RS='\n\n' will seperate a file at two blank line intervals open(file.txt).read().split(\n\n) -- D'Arcy J.M. Cain da...@druid.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Catch and name an exception in Python 2.5 +
In Python 3, you can catch an exception and bind it to a name with: try: ... except ValueError, KeyError as error: pass In Python 2.5, that is written: try: ... except (ValueError, KeyError), error: pass and the as error form gives a SyntaxError. Python 2.6 and 2.7 accept either form. Is there any way to catch an exception and bind it to a name which will work across all Python versions from 2.5 onwards? I'm pretty sure there isn't, but I thought I'd ask just in case. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Catch and name an exception in Python 2.5 +
On 26/08/11 21:56, Steven D'Aprano wrote: In Python 3, you can catch an exception and bind it to a name with: try: ... except ValueError, KeyError as error: pass In Python 2.5, that is written: try: ... except (ValueError, KeyError), error: pass and the as error form gives a SyntaxError. Python 2.6 and 2.7 accept either form. Is there any way to catch an exception and bind it to a name which will work across all Python versions from 2.5 onwards? I'm pretty sure there isn't, but I thought I'd ask just in case. It's not elegant, and I haven't actually tested this, but this should work: try: ... except (ValueError, KeyError): error = sys.exc_info()[2] -- Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
On Sat, Aug 27, 2011 at 4:05 AM, rantingrick rantingr...@gmail.com wrote: Now take a look at MY simple ONE module solution. It has JUST enough methods and NOT a single more! I disagree - create_widgets() is completely unnecessary in the presence of show(), unless it's possible to show the dialog, hide it, and then re-show it without recreating the widgets. On Sat, Aug 27, 2011 at 4:16 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I can think of at least five reasons apart from re-use why it might be appropriate to pull out code into its own function or method even if it is used in one place only: I'm glad you say might be, because your five reasons aren't always reasons for refactoring. I'll play devil's advocate for a moment, because discussion is both fun and informative: :) (1) Extensibility. Just earlier today I turned one method into three: I did this so that subclasses could override the behaviour of each component individually, even though the caller is not expected to call raw_select or choose directly. (I may even consider making them private.) Definitely, but it's no value if you make every tiny thing into your own function. Sometimes the best way to code is to use lower-level functionality directly (not wrapping input() inside raw_select() for instance), and letting someone monkey-patch if they want to change your code. A judgment call. (2) Testing. It is very difficult to reach into the middle of a function and test part of it. ... By splitting it into functions, you can test each part in isolation, which requires much less work. Yes, but 100% coverage isn't that big a deal. If the function does precisely one logical thing, then you don't _need_ to test parts in isolation - you can treat it as a black box and just ensure that it's doing the right thing under various circumstances. However, this ties in nicely with your next point... (3) Fault isolation. If you have a 100 line function that fails on line 73, that failure may have been introduced way back in line 16. By splitting the function up into smaller functions, you can more easily isolate where the failure comes from, by checking for violated pre- and post-conditions. ... and here's where #2 really shines. If you break your function in two, the natural thing to do is to test each half separately, with the correct preconditions, and examine its output. If your fault was on line 16, your test for that half of the function has a chance of detecting it. I don't have a Devil's Advocate put-down for this one, save the rather weak comment that it's possible to check pre- and post-conditions without refactoring. :) (4) Maintainability. It's just easier to document and reason about a function that does one thing, than one that tries to do everything. Which would you rather work with, individual functions for: ... omnomnom ... Even if each function is only called once, maintenance is simpler if the code is broken up into more easily understood pieces. Yes, as long as you do the job intelligently. Goes back to what I said about naming functions - in your kitchen example, every function has a self-documenting name, which means you've broken it out more-or-less correctly. (I'd still want to have prepare_and_serve_five_course_meal() of course, but it would be calling on all the others.) Breaking something out illogically doesn't help maintainability at all - in fact, it'll make it worse. So this function does what, exactly? And if I need to add a line of code, ought I to do it here, or over there? Does anyone else actually call this function? MIGHT someone be reaching into my module and calling this function directly? I'd better keep it... ugh. (5) Machine efficiency. This can go either way. And that's the very best thing to say about efficiency. Ever. In C, I can write static functions and let the compiler inline them; in Java, I tried to do the same thing, and found ridiculous overheads. Ended up making a monolith rather than go through Java's overhead. But if I'd changed what VM I was running it on, that might well have changed. Profile, profile, profile. So that's four really good reasons for splitting code into functions, and one borderline one, other than code re-use. There may be others. I'm sure there are. But let's face it: We're programming in PYTHON. Not C, not Erlang, not Pike, not PHP. Python. If this has been the right choice, then we should assume that efficiency isn't king, but readability and maintainability probably are; so the important considerations are not will it take two extra nanoseconds to execute but can my successor understand what the code's doing and will he, if he edits my code, have a reasonable expectation that he's not breaking stuff. These are always important. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
The RAISE_VARARGS opcode in Python 3
Hi all, Here is an extract from the dis module doc [1] RAISE_VARARGS(argc) Raises an exception. argc indicates the number of parameters to the raise statement, ranging from 0 to 3. The handler will find the traceback as TOS2, the parameter as TOS1, and the exception as TOS. OTOH, looking at PEP 3109: In Python 3, the grammar for raise statements will change from [2] raise_stmt: 'raise' [test [',' test [',' test]]] to raise_stmt: 'raise' [test] So it seems that RAISE_VARARGS's argument can only be 0 or 1 in Python 3, whereas it could be up to 3 in Python 2. Can anyone confirm that this is the case? In this case, I guess the dis docs need to be updated. Thank you, Arnaud [1] http://docs.python.org/py3k/library/dis.html#opcode-RAISE_VARARGS [2] http://www.python.org/dev/peps/pep-3109/#grammar-changes -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
On Aug 26, 4:45 pm, Chris Angelico ros...@gmail.com wrote:
On Sat, Aug 27, 2011 at 4:05 AM, rantingrick rantingr...@gmail.com wrote:
Now take a look at MY simple ONE module solution. It has JUST enough
methods and NOT a single more!
I disagree - create_widgets() is completely unnecessary in the
presence of show(),
Well since you cannot see the underlying code i won't be too harsh on
you :), but yes, i can assure you that create widgets IS necessary for
readability. show() calls self.create_widgets() then adds a special
hit tag to the text widget and sets up a modal behavior of the dialog,
it's only 5-7 lines of setup code but i think the separation is
warranted.
Could i have rolled all the create_widgets() code into the show()
method? Of course, however i do see a good reason for separation here
for the sake of readability. Although i must admit, had the interface
been much larger i most assuredly would have rolled it together.
unless it's possible to show the dialog, hide it,
and then re-show it without recreating the widgets.
Yes the instance lives on between session to save state. Also the
find_again binding of the text widget calls the
SearchReplaceDialog.find_again() method when {CONTROL+G} event fires.
I'm sure there are. But let's face it: We're programming in PYTHON.
Not C, not Erlang, not Pike, not PHP. Python. If this has been the
right choice, then we should assume that efficiency isn't king, but
readability and maintainability probably are; so the important
considerations are not will it take two extra nanoseconds to
execute but can my successor understand what the code's doing and
will he, if he edits my code, have a reasonable expectation that
he's not breaking stuff. These are always important.
Bravo! That has to be most lucid and intelligent statement from you to
date. And i must say the warm fuzzies i got from imagining the defeat
D'Aprano must have felt whist reading it left me with a nice feeling.
How do like them apples, D'Aprano? :-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
On Aug 26, 1:16 pm, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: (3) Fault isolation. If you have a 100 line function that fails on line 73, that failure may have been introduced way back in line 16. By splitting the function up into smaller functions, you can more easily isolate where the failure comes from, by checking for violated pre- and post-conditions. What's wrong Steven, are track backs too complicated for you? # START DUMMY SCRIPT def very_long_function(): max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(object) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) # print 'blah' print 'blah' print 'blah-blah' very_long_function() # END DUMMY SCRIPT Traceback (most recent call last): File C:/Python27/test3.py, line 48, in module very_long_function() File C:/Python27/test3.py, line 26, in very_long_function max(object) TypeError: 'type' object is not iterable Oh the humanity! -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
Chris Angelico wrote: On Sat, Aug 27, 2011 at 4:16 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I can think of at least five reasons apart from re-use why it might be appropriate to pull out code into its own function or method even if it is used in one place only: I'm glad you say might be, because your five reasons aren't always reasons for refactoring. I'll play devil's advocate for a moment, because discussion is both fun and informative: :) Naturally :) I say might be because I mean it: these arguments have to be weighed up against the argument against breaking code out of functions. It's easy to imagine an extreme case where there are a billion *tiny* functions, each of which does one micro-operation: def f1(x): return x + 1 def f2(x): return 3*x def f3(x): return f2(f1(x)) # instead of 3*(x+1) ... If spaghetti code (GOTOs tangled all through the code with no structure) is bad, so is ravioli code (code bundled up into tiny parcels and then thrown together higgledy-piggledy). Both cases can lead to an unmaintainable mess. Nobody is arguing that More Functions Is Always Good. Sensible coders understand that you should seek a happy medium and not introduce more functions just for the sake of having More! Functions!. But I'm not arguing with you, we're in agreement. One last comment though: [...] Definitely, but it's no value if you make every tiny thing into your own function. Sometimes the best way to code is to use lower-level functionality directly (not wrapping input() inside raw_select() for instance), and letting someone monkey-patch if they want to change your code. A judgment call. I agree on the first part (don't split *everything* into functions) but I think that the monkey-patch idea is tricky and dangerous in practice. The first problem is, how do you know what needs to be monkey-patched? You may not have access to the source code to read, and it may not be as obvious as oh, it gets input from the user, so it must be calling input(). Second, even if you know what to monkey-patch, it's really hard to isolate the modification to just the method you want. By their nature, monkey- patches apply globally to the module. And if you patch the builtins module, they apply *everywhere*. So while monkey-patching can work, it's tricky to get it right and it should be left as a last resort. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
On Sat, Aug 27, 2011 at 11:26 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I say might be because I mean it: these arguments have to be weighed up against the argument against breaking code out of functions. It's easy to imagine an extreme case where there are a billion *tiny* functions, each of which does one micro-operation: def f1(x): return x + 1 def f2(x): return 3*x def f3(x): return f2(f1(x)) # instead of 3*(x+1) This fails the give it a decent name test. Can you name these functions according to what they do, as opposed to how they do it? For instance: def add_flagfall(x): return x + 1 # add a $1 flagfall to the price def add_tax(x): return 3*x # this is seriously nasty tax def real_price(x): return add_tax(add_flagfall(x)) # instead of 3*(x+1) This would be acceptable, because each micro-operation has real meaning. I'd prefer to do it as constants rather than functions, but at least they're justifying their names. And you're absolutely right about monkey-patching. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Catch and name an exception in Python 2.5 +
Thomas Jollans wrote: On 26/08/11 21:56, Steven D'Aprano wrote: Is there any way to catch an exception and bind it to a name which will work across all Python versions from 2.5 onwards? I'm pretty sure there isn't, but I thought I'd ask just in case. It's not elegant, and I haven't actually tested this, but this should work: try: ... except (ValueError, KeyError): error = sys.exc_info()[2] Great! Thanks for that, except I think you want to use [1], not [2]. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
[issue12831] 2to3 and integer division
Mark Dickinson dicki...@gmail.com added the comment: / 2 is an integer division, so it should be // 3 in Python 3. No, I don't think that's right: 2to3 has no way of knowing that the programmer intended an integer division here (self.maxstars could be a float). Instead, you should always use '//' in Python 2 code where an integer division is intended. -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12831] 2to3 and integer division
Changes by Mark Dickinson dicki...@gmail.com: -- nosy: +benjamin.peterson resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12844] Support more than 255 arguments
Martin v. Löwis mar...@v.loewis.de added the comment: The approach looks fine to me. Would you like to work on a patch? -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12808] Coverage of codecs.py
Tennessee Leeuwenburg tleeuwenb...@gmail.com added the comment: Here is a stab at updated documentation. I would suggest that if further changes are recommended to the documentation, that a core committer go ahead and make them. I'm absolutely more than happy to keep taking stabs at it, but ultimately I probably don't understand the purpose of these classes as well as some of the rest of you, and I don't feel best placed to decide exactly how this should read -- Added file: http://bugs.python.org/file23049/codecs.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12808 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12831] 2to3 and integer division
Alexander Rødseth rods...@gmail.com added the comment: Even though it's hard to cover every case, it should be possible in quite a few cases: self.maxstars = 4 half = self.maxstars / 2 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12845] PEP-3118: C-contiguity with zero strides
New submission from Stefan Krah stefan-use...@bytereef.org: Numpy and PyBuffer_IsContiguous() have different ideas of C-contiguity if there is a zero in strides (this is allowed, I asked Pauli Virtanen). from numpy import * nd = ndarray(shape=[10], strides=[0]) nd.flags C_CONTIGUOUS : True F_CONTIGUOUS : False OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False from _testbuffer import ndarray as pyarray from _testbuffer import PyBUF_FULL_RO x = pyarray(nd, getbuf=PyBUF_FULL_RO) x.c_contiguous False -- assignee: skrah components: Interpreter Core messages: 143005 nosy: skrah priority: normal severity: normal status: open title: PEP-3118: C-contiguity with zero strides type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12831] 2to3 and integer division
Raymond Hettinger raymond.hettin...@gmail.com added the comment: Running python with the -3 command line option will warn about Python 3.x incompatibilities that 2to3 cannot trivially fix. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12820] Tests for Lib/xml/dom/minicompat.py
John Chandler therealmetal...@gmail.com added the comment: Cool, thanks for the feedback! :-) I'll make the appropriate changes to the tests and add some coverage for defproperty as soon as I can. John -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12820 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12846] unicodedata.normalize turkish letter problem
New submission from Cem YILDIZ c...@fizy.com:
unicodedata.normalize cannot convert turkish letter ı into i:
import unicodedata
s = uüfürükçü ağaç ve ıslıkçı çeşme
print(shoehorn_unicode_into_ascii(s))
print unicodedata.normalize('NFKD', s).encode('ascii','ignore')
ufurukcu agac ve slkc cesme
but the result should be
ufurukcu agac ve islikci cesme
--
components: Unicode
messages: 143008
nosy: fizymania
priority: normal
severity: normal
status: open
title: unicodedata.normalize turkish letter problem
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12846
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12846] unicodedata.normalize turkish letter problem
Changes by Cem YILDIZ c...@fizy.com: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12846] unicodedata.normalize turkish letter problem
Cem YILDIZ c...@fizy.com added the comment:
unicodedata.normalize cannot convert turkish letter ı into i:
import unicodedata
s = uüfürükçü ağaç ve ıslıkçı çeşme
print unicodedata.normalize('NFKD', s).encode('ascii','ignore')
ufurukcu agac ve slkc cesme
but the result should be
ufurukcu agac ve islikci cesme
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12846
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9302] distutils API Reference: setup() and Extension parameters' description not correct.
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 96f0ccb9716d by Éric Araujo in branch '3.2': Fix type information in distutils API reference (#9302). http://hg.python.org/cpython/rev/96f0ccb9716d New changeset a410b857efe3 by Éric Araujo in branch 'default': Merge from 3.2 (#9302 fix and other changes) http://hg.python.org/cpython/rev/a410b857efe3 New changeset 59b3f845f7a3 by Éric Araujo in branch 'default': Synchronize packaging docs with distutils’ (includes fix for #9302) http://hg.python.org/cpython/rev/59b3f845f7a3 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9302 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9302] distutils API Reference: setup() and Extension parameters' description not correct.
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 78b26e7720c0 by Éric Araujo in branch '2.7': Fix type information in distutils API reference (#9302). http://hg.python.org/cpython/rev/78b26e7720c0 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9302 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12678] test_packaging and test_distutils failures under Windows
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 8ad1670c0f1f by Éric Araujo in branch '2.7': Try to fix test_distutils on Windows (#12678) http://hg.python.org/cpython/rev/8ad1670c0f1f -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12678 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11360] In documentation of getopt, advertise argparse instead of optparse
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 40f7a6e71930 by Éric Araujo in branch '3.2': Remove outdated pointer to optparse (fixes #11360). http://hg.python.org/cpython/rev/40f7a6e71930 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11360 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11360] In documentation of getopt, advertise argparse instead of optparse
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 6d3c645fa52f by Éric Araujo in branch '2.7': Remove outdated pointer to optparse (fixes #11360). http://hg.python.org/cpython/rev/6d3c645fa52f -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11360 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12833] raw_input misbehaves when readline is imported
Éric Araujo mer...@netwok.org added the comment: Maybe you need to call sys.stdin.flush() before raw_input? In any way, 2.6 is in security mode, so we need to reproduce this with current versions: 2.7, 3.2 or 3.3. -- components: +IO, Interpreter Core -Library (Lib) nosy: +eric.araujo, pitrou stage: - test needed versions: -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12842] Docs: first parameter of tp_richcompare() always has the correct type
Changes by Éric Araujo mer...@netwok.org: -- keywords: +needs review stage: - patch review versions: -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12842 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9302] distutils API Reference: setup() and Extension parameters' description not correct.
Éric Araujo mer...@netwok.org added the comment: Improved and committed, thanks again! -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9302 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12759] (?P=) input for Tools/scripts/redemo.py raises unnhandled exception
Éric Araujo mer...@netwok.org added the comment: I can reproduce in 3.3 (the file has been moved to Tools/demo/redemo.py). The Tk application does not crash but there is a traceback. Would you like to work on a patch? If so, there are good guidelines in the devguide. -- keywords: +easy nosy: +eric.araujo stage: - needs patch title: (?P=) input for Tools/scripts/redemo.py throw an exception - (?P=) input for Tools/scripts/redemo.py raises unnhandled exception versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12759 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12806] argparse: Hybrid help text formatter
Éric Araujo mer...@netwok.org added the comment: Steven: What do you think? GraylinKim: You can open a feature request for message preview on the metatracker (see “Report Tracker Problem” in the sidebar). -- nosy: +bethard, eric.araujo type: - feature request versions: +Python 3.3 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12768] docstrings for the threading module
Éric Araujo mer...@netwok.org added the comment: I have made a review on Rietveld. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12768 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12195] Little documentation of annotations
Changes by Éric Araujo mer...@netwok.org: -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12195 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12742] Add support for CESU-8 encoding
Ezio Melotti ezio.melo...@gmail.com added the comment: Can you provide some example? The page you linked says It should be used exclusively for internal processing and never for external data exchange., so I'm not sure why these APIs would want to use it. -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12742 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12195] Little documentation of annotations
Raymond Hettinger raymond.hettin...@gmail.com added the comment: some simple examples showing the syntax would go a long way. Sorry, there as just too many ways to go and we are intentionally not stating which way is preferred. I've seen many variants a:[Integral] for a list of integers, a:(int,str) for a 2-tuple of an int and a string, a:(str,file,None) for something that is a string or a file or None, a:'light_years' to indicate units of measure, a:range_check(10.5, 20.1) for range validation, and some variants for converters, adapters, factory functions, documentation aids, etc. If you want to advance the state of the art, perhaps write a blog post on what you consider to be a best practice. If a consensus emerges, we will follow. -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12195 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12768] docstrings for the threading module
Eli Bendersky eli...@gmail.com added the comment: Éric, yeah I received an email. Hopefully Graeme did too. It's a shame a new review isn't notified in the tracker instead. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12768 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12802] Windows error code 267 should be mapped to ENOTDIR, not EINVAL
Antoine Pitrou pit...@free.fr added the comment: Brian, Tim, I'd feel more comfortable if any of you confirmed this isn't a stupid proposal on my part :) -- components: +Interpreter Core stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12802] Windows error code 267 should be mapped to ENOTDIR, not EINVAL
Brian Curtin br...@python.org added the comment: I could see how they'd use EINVAL, but to me ENOTDIR makes more sense here. However, I'm not sure if anyone is depending on this (or what they could depend on it for). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12833] raw_input misbehaves when readline is imported
Idan Kamara idank...@gmail.com added the comment: Reproduced on 2.7. (flushing stdin/out doesn't help) -- versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12802] Windows error code 267 should be mapped to ENOTDIR, not EINVAL
Antoine Pitrou pit...@free.fr added the comment: I could see how they'd use EINVAL, but to me ENOTDIR makes more sense here. However, I'm not sure if anyone is depending on this (or what they could depend on it for). Right now I'm not sure, but if PEP 3151 is accepted it will make much more sense to get a NotADirectoryError. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12802] Windows error code 267 should be mapped to ENOTDIR, not EINVAL
Brian Curtin br...@python.org added the comment: With that PEP likely to be accepted, I say go ahead with the change for that benefit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12802] Windows error code 267 should be mapped to ENOTDIR, not EINVAL
Tim Golden m...@timgolden.me.uk added the comment: Obviously someone's code would break if it were relying on the Unix errno only in a Windows-only situation to determine the situation of opening a directory which isn't one. But that combination of events doesn't seem terribly likely. Speaking for myself, since the exception is a WindowsError with the winerror attribute prominent, [Error 267] I'd be far more likely to be trapping that. I say go ahead -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12802] Windows error code 267 should be mapped to ENOTDIR, not EINVAL
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Note that this file is not written by hand. It's generated by PC/generrmap.c, which uses the _dosmaperr() function provided by the msvcrt. If we want to modify it, this should be clearly marked somewhere. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12802] Windows error code 267 should be mapped to ENOTDIR, not EINVAL
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: If you have a copy of Visual Studio, you can see the code of _dosmaperr() in VC/crt/src/dosmap.c. Otherwise the Google query inurl:dosmap.c returns some online copies of this file. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9262] IDLE: Use tabbed shell and edit windows
Roger Serwy roger.se...@gmail.com added the comment: Attached is an extension which provides tabbed windows for IDLE. It supports drag-and-drop reordering and separate windows. The implementation relies on monkey-patching a few subroutines and duck-typing for the toplevel window. The extension emulates each tab as if it were its own toplevel object. There can be flickering when switching tabs due to swapping the toplevel menu bar. This seems to be a limitation of Tk. -- Added file: http://bugs.python.org/file23050/TabExtension.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9262 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11913] sdist should allow for README.rst
resc thomat...@gmail.com added the comment: Just wanted to note that this confuses other people too... http://stackoverflow.com/questions/4384796/readme-extension-for-python-projects Is this something that could be changed in 'distribute'? -- nosy: +Thomas.Smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11913 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug
Guido van Rossum gu...@python.org added the comment: Wow. A very educational discussion. We will be referencing this issue for many years to come. As long as the buck stops with me, I feel strongly that *today* changing indexing from O(1) to O(log N) is a bad idea, partly for technical reasons, partly because the Python culture isn't ready. In 5 or 10 years we need to revisit this, and it wouldn't hurt if in the mean time we started seriously thinking about how to change our APIs so that O(1) indexing is not relied upon so much. This may include rewriting tutorials to nudge users in the direction of using different idioms for text processing. In the meantime, I think our best option is to switch CPython to the PEP 393 string implementation. Despite its disadvantages (I understand the spoiler issue) is is generally no worse than a wide build, and there is working code today that we can optimize before 3.3 is released. For Python implementations where this is not an option (I'm thinking Jython and IronPython, both of which are closely tied to a system string type that behaves like UTF-16) I hope that at least the regular expression behavior can be fixed so that . matches a surrogate pair. (Possibly they already behave that way, if they use a native regex library.) In all cases, for future Python versions, we should tighten the codecs to reject data that the Unicode standard considers invalid (and we should offer separate non-strict codecs for situations where such invalid data needs to be processed). I wish we could fix the codecs and the regex . issue on narrow builds for Python versions before 3.3 (esp. 3.2 and 2.7), but I fear that this is considered too backwards incompatible (though for each specific fix we should consider this carefully). -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12729 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12728] Python re lib fails case insensitive matches on Unicode data
Guido van Rossum gu...@python.org added the comment: This bug could do with a little less attitude. That said, I think it is a bug and should be fixed, at the very least for Python 3.3. As always, it is a matter of much debate to what extent bugs can be fixed in previous Python versions (specifically, 2.7 and 3.2) without breaking more code than it fixes, and I don't want to jump the gun on that issue. Let's first see what it takes to fix this for 3.3. -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12728 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12735] request full Unicode collation support in std python library
Guido van Rossum gu...@python.org added the comment: Sounds like a fair feature request for Python 3.3, as long as the intention is that users must import some module from the standard library and use functions defined in that module. The operations and methods defined for str instances (e.g. ==, , etc.) should not change their behavior. Is there an existing 3rd party library that we could adopt (even if it isn't perfect yet)? -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12735 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12736] Request for python casemapping functions to use full not simple casemaps per Unicode's recommendation
Guido van Rossum gu...@python.org added the comment: I presume this applies to builtin str methods like .lower(), right? I think it is a good thing to do for Python 3.3. We'd need to define what should happen in edge cases, e.g. when (against all odds) a string happens to contain a lone surrogate or some other code point or sequence of code points that the Unicode standard considers illegal. I think it should not fail but just leave those code points alone. Does this require us to import more data files from the Unicode standard? By itself that doesn't scare me. Would this also affect .islower() and friends? -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12736 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12749] lib re cannot match non-BMP ranges (all versions, all builds)
Guido van Rossum gu...@python.org added the comment: We should at least get this fixed in 3.3. Then we can discuss the benefits of backporting the fixes to 2.7 and 3.2 (though it sounds to me like the backports will fix more than they will break, since it is pretty much impossible to do the right thing in those versions today). -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12749 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12737] str.title() is overzealous by upcasing combining marks inappropriately
Guido van Rossum gu...@python.org added the comment: Yeah, this should be fixed in 3.3 and probably backported to 3.2 and 2.7. (There is already no guarantee that len(s) == len(s.title()), right?) -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12737 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12746] normalization is affected by unicode width
Guido van Rossum gu...@python.org added the comment: Yeah, we should fix this. At least in 3.3, but (without knowing what exactly is involved) I think backporting to 2.7 and 3.2 makes sense too. -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12746 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12731] python lib re uses obsolete sense of \w in full violation of UTS#18 RL1.2a
Guido van Rossum gu...@python.org added the comment: Really? The re module cannot be salvaged and we should add regex but keep the (buggy) re? That does not make a lot of sense to me. I think it should just be fixed in the re module. Or the re module should be *replaced* by the code from the regex module (but renamed to re, and with certain backwards compatibilities restored, probably). But I really hope the re module (really: the _sre extension module) can be fixed. We should also make a habit in our docs of citing specific versions of the Unicode standard, and specific TR numbers and versions where they apply. (And hopefully we can supply URLs to the Unicode consortium's canonical copies of those documents.) -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12731 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12733] Request for grapheme support in Python re lib
Guido van Rossum gu...@python.org added the comment: Again, I would be disappointed if the re (_sre) module could not be fixed. It is a reasonable feature request. -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12733 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12734] Request for property support in Python re lib
Guido van Rossum gu...@python.org added the comment: +1 on adding the feature to 3.3 in whichever way makes sense. -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12734 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12753] \N{...} neglects formal aliases and named sequences from Unicode charnames namespace
Guido van Rossum gu...@python.org added the comment: +1 on the feature request. -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12753 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12735] request full Unicode collation support in std python library
Tom Christiansen tchr...@perl.com added the comment: Sounds like a fair feature request for Python 3.3, as long as the intention is that users must import some module from the standard library and use functions defined in that module. The operations and methods defined for str instances (e.g. ==, , etc.) should not change their behavior. Is there an existing 3rd party library that we could adopt (even if it isn't perfect yet)? I *think* you could use ICU's. I'm pretty sure the Parrot people use ICU libraries. --tom -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12735 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12735] request full Unicode collation support in std python library
Guido van Rossum gu...@python.org added the comment: I know I sound like NIH, but I'm always reluctant to add a big 3rd party lib like ICU to the permanent dependencies of all future Python distros. If people want to use ICU they already can. OTOH I don't have a better idea. :-( -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12735 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
