Re: Removing items from a list
Le 10/02/12 21:48, Thomas Philips a écrit : Thanks for the insight. I saw the behavious as soon as I extended x with a bunch of 0's x = list(range(10)) x.extend([0]*10) x [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] for i in reversed(x): if i % 2 == 0: x.remove(i) x [1, 3, 5, 7, 9] x = list(range(10)) x.extend([0]*10) x [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] for i in x: if i % 2 == 0: x.remove(i) x [1, 3, 5, 7, 9, 0, 0, 0, 0, 0] Not a good example, with reversed(), you're not iterating on the list x but on an another list. More precisely a 'listreverseiterator object. -- Vincent V.V. Oqapy . Qarte+7 . PaQager -- http://mail.python.org/mailman/listinfo/python-list
Re: Postpone evaluation of argument
Righard van Roy writes: > Hello, > > I want to add an item to a list, except if the evaluation of that item > results in an exception. > I could do that like this: > > def r(x): > if x > 3: > raise(ValueError) > > try: > list.append(r(1)) > except: > pass > try: > list.append(r(5)) > except: > pass > > This looks rather clumbsy though, and it does not work with i.e. list > comprehensions. > > I was thinking of writing a decorator like this: > > def tryAppendDecorator(fn): > def new(*args): > try: > fn(*args) > except: > pass > return new > > @tryAppendDecorator > def tryAppend(list, item): > list.append(item) > > tryAppend(list, r(1)) > tryAppend(list, r(5)) > > This does not work however because the 'item' argument gets evaluated > before the decorator does it's magic. > > Is there a way to postpone the evaluation of 'item' till it gets used > inside the decorator. Like it is possible to quote a form in Lisp. That's not considered good practice in Lisp either. One would use a lambda expression to delay the computation, as others have suggested. You might be able to arrange your program so that tryAppend is called with the error-raising function and its arguments separately. I mean like this: def r(x): if x > 3: raise(ValueError) return x def tryAppendDecorator(fn): def new(xs, f, *args): try: fn(xs, f(*args)) except: pass return new @tryAppendDecorator def tryAppend(items, item): items.append(item) sub3 = [] tryAppend(sub3, r, 3) tryAppend(sub3, r, 1) tryAppend(sub3, r, 4) tryAppend(sub3, r, 1) tryAppend(sub3, r, 5) Maybe you should only ignore some specific type of exception, like ValueError if you are specifically using r as a filter whose task it is to raise a ValueError. -- http://mail.python.org/mailman/listinfo/python-list
Orphanage Funds
Hi, I am Mithra. Me and my friends joined together ti help the orphanage people after visiting their home once. There are nearly 100 students interested in studies but they dont have enough fund to be provided for their studies. Please help them by donating as much as you can. Thanks for your help. Please forward this mail for your friends. Please click the following link to donate : http://www.gofundme.com/dij30 Thanks in Advance -- http://mail.python.org/mailman/listinfo/python-list
Re: round down to nearest number
Terry Reedy writes: > On 2/9/2012 8:23 PM, noydb wrote: >> So how would you round UP always? Say the number is 3219, so you want (//100+1)*100 > 3400 Note that that doesn't work for numbers that are already round: >>> (3300//100+1)*100 3400# 3300 would be correct I'd go with Chris Rebert's (x + 99) // 100. -- http://mail.python.org/mailman/listinfo/python-list
Re: Postpone evaluation of argument
在 2012年2月11日星期六UTC+8上午7时57分56秒，Paul Rubin写道： > Righard van Roy > writes: > > I want to add an item to a list, except if the evaluation of that item > > results in an exception. > > This may be overkill and probably slow, but perhaps most in the spirit > that you're asking. > > from itertools import chain > > def r(x): > if x > 3: > raise(ValueError) > return x > > def maybe(func): > try: > yield func() > except: > return > I am wondering at which level to yield in a nested decorated function is more controllable. It is definitely wrong to yield in manny levels decorated. > def p(i): return maybe(lambda: r(i)) > > your_list = list(chain(p(1), p(5))) > print your_list -- http://mail.python.org/mailman/listinfo/python-list
Twisted 12.0.0 released
On behalf of Twisted Matrix Laboratories, I am honored to announce the release of Twisted 12.0. 47 tickets are closed by this release, among them: * A fix to the GTK2 reactor preventing unnecessary wake-ups * Preliminary support of IPV6 on the server side * Several fixes to the new protocol-based TLS implementation * Improved core documentation's main page Twisted no longer supports Python 2.4, the latest supported version is 2.5. For more information, see the NEWS file here: http://twistedmatrix.com/Releases/Twisted/12.0/NEWS.txt Download it now from: http://pypi.python.org/packages/source/T/Twisted/Twisted-12.0.0.tar.bz2 or http://pypi.python.org/packages/2.5/T/Twisted/Twisted-12.0.0.win32-py2.5.msi or http://pypi.python.org/packages/2.6/T/Twisted/Twisted-12.0.0.win32-py2.6.msi or http://pypi.python.org/packages/2.7/T/Twisted/Twisted-12.0.0.win32-py2.7.msi Thanks to the supporters of the Twisted Software Foundation and to the many contributors for this release. -- Thomas -- http://mail.python.org/mailman/listinfo/python-list
ANN: Sarge, a library wrapping the subprocess module, has been released.
Sarge, a cross-platform library which wraps the subprocess module in
the standard library, has been released.
What does it do?
Sarge tries to make interfacing with external programs from your
Python applications easier than just using subprocess alone.
Sarge offers the following features:
* A simple way to run command lines which allows a rich subset of Bash-
style shell command syntax, but parsed and run by sarge so that you
can run on Windows without cygwin (subject to having those commands
available):
>>> from sarge import capture_stdout
>>> p = capture_stdout('echo foo | cat; echo bar')
>>> for line in p.stdout: print(repr(line))
...
'foo\n'
'bar\n'
* The ability to format shell commands with placeholders, such that
variables are quoted to prevent shell injection attacks.
* The ability to capture output streams without requiring you to
program your own threads. You just use a Capture object and then you
can read from it as and when you want.
Advantages over subprocess
---
Sarge offers the following benefits compared to using subprocess:
* The API is very simple.
* It's easier to use command pipelines - using subprocess out of the
box often leads to deadlocks because pipe buffers get filled up.
* It would be nice to use Bash-style pipe syntax on Windows, but
Windows shells don't support some of the syntax which is useful, like
&&, ||, |& and so on. Sarge gives you that functionality on Windows,
without cygwin.
* Sometimes, subprocess.Popen.communicate() is not flexible enough for
one's needs - for example, when one needs to process output a line at
a time without buffering the entire output in memory.
* It's desirable to avoid shell injection problems by having the
ability to quote command arguments safely.
* subprocess allows you to let stderr be the same as stdout, but not
the other way around - and sometimes, you need to do that.
Python version and platform compatibility
-
Sarge is intended to be used on any Python version >= 2.6 and is
tested on Python versions 2.6, 2.7, 3.1, 3.2 and 3.3 on Linux,
Windows, and Mac OS X (not all versions are tested on all platforms,
but sarge is expected to work correctly on all these versions on all
these platforms).
Finding out more
You can read the documentation at
http://sarge.readthedocs.org/
There's a lot more information, with examples, than I can put into
this post.
You can install Sarge using "pip install sarge" to try it out. The
project is hosted on BitBucket at
https://bitbucket.org/vinay.sajip/sarge/
And you can leave feedback on the issue tracker there.
I hope you find Sarge useful!
Regards,
Vinay Sajip
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Sarge, a library wrapping the subprocess module, has been released.
On Fri, Feb 10, 2012 at 2:28 PM, Vinay Sajip wrote:
> Sarge, a cross-platform library which wraps the subprocess module in
> the standard library, has been released.
>
> What does it do?
>
>
> Sarge tries to make interfacing with external programs from your
> Python applications easier than just using subprocess alone.
>
> Sarge offers the following features:
>
> * A simple way to run command lines which allows a rich subset of Bash-
> style shell command syntax, but parsed and run by sarge so that you
> can run on Windows without cygwin (subject to having those commands
> available):
>
>>>> from sarge import capture_stdout
>>>> p = capture_stdout('echo foo | cat; echo bar')
>>>> for line in p.stdout: print(repr(line))
>...
>'foo\n'
>'bar\n'
>
> * The ability to format shell commands with placeholders, such that
> variables are quoted to prevent shell injection attacks.
>
> * The ability to capture output streams without requiring you to
> program your own threads. You just use a Capture object and then you
> can read from it as and when you want.
>
> Advantages over subprocess
> ---
>
> Sarge offers the following benefits compared to using subprocess:
>
> * The API is very simple.
>
> * It's easier to use command pipelines - using subprocess out of the
> box often leads to deadlocks because pipe buffers get filled up.
>
> * It would be nice to use Bash-style pipe syntax on Windows, but
> Windows shells don't support some of the syntax which is useful, like
> &&, ||, |& and so on. Sarge gives you that functionality on Windows,
> without cygwin.
>
> * Sometimes, subprocess.Popen.communicate() is not flexible enough for
> one's needs - for example, when one needs to process output a line at
> a time without buffering the entire output in memory.
>
> * It's desirable to avoid shell injection problems by having the
> ability to quote command arguments safely.
>
> * subprocess allows you to let stderr be the same as stdout, but not
> the other way around - and sometimes, you need to do that.
>
> Python version and platform compatibility
> -
>
> Sarge is intended to be used on any Python version >= 2.6 and is
> tested on Python versions 2.6, 2.7, 3.1, 3.2 and 3.3 on Linux,
> Windows, and Mac OS X (not all versions are tested on all platforms,
> but sarge is expected to work correctly on all these versions on all
> these platforms).
>
> Finding out more
>
>
> You can read the documentation at
>
> http://sarge.readthedocs.org/
>
> There's a lot more information, with examples, than I can put into
> this post.
>
> You can install Sarge using "pip install sarge" to try it out. The
> project is hosted on BitBucket at
>
> https://bitbucket.org/vinay.sajip/sarge/
>
> And you can leave feedback on the issue tracker there.
>
> I hope you find Sarge useful!
>
> Regards,
>
>
This is pretty cool I think ill check it out! I really hate working with
subprocess it just seems a bit too low level for my taste.
>
> Vinay Sajip
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
MySQL: AttributeError: cursor
Hi All, I'm using Python 2.7 and having a problem creating the cursor below. Any suggestions would be appreciated! import sys import _mysql print "cursor test" db = _mysql.connect(host="localhost",user="root",passwd="mypw",db="python- test") cursor = db.cursor() >>> cursor test Traceback (most recent call last): File "C:\Python27\dbconnect.py", line 8, in cursor = db.cursor() AttributeError: cursor -- http://mail.python.org/mailman/listinfo/python-list
Re: problems with shelve(), collections.defaultdict, self
On Fri, Feb 10, 2012 at 7:48 PM, 7stud <[email protected]> wrote: > But I cannot get a class that inherits from collections.defaultdict to > shelve itself: > > > import collections as c > import shelve > > class Dog(c.defaultdict): > def __init__(self): > super().__init__(int, Joe=0) > print('', self) > > def save(self): > my_shelve = shelve.open('data22.shelve') > my_shelve['dd'] = self > my_shelve.close() > > def load(self): > my_shelve = shelve.open('data22.shelve') > data = my_shelve['dd'] > my_shelve.close() > > print(data) > > > d = Dog() > d.save() > d.load() > > --output:-- > > defaultdict(, {'Joe': 30}) > Traceback (most recent call last): > File "/Library/Frameworks/Python.framework/Versions/3.2/lib/ > python3.2/shelve.py", line 111, in __getitem__ > value = self.cache[key] > KeyError: 'dd' > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): > File "3.py", line 95, in > d.load() > File "3.py", line 87, in load > data = my_shelve['dd'] > File "/Library/Frameworks/Python.framework/Versions/3.2/lib/ > python3.2/shelve.py", line 114, in __getitem__ > value = Unpickler(f).load() > TypeError: __init__() takes exactly 1 positional argument (2 given) > > > > I deleted all *.shelve.db files between program runs. I can't figure > out what I'm doing wrong. The problem is that defaultdict defines a custom __reduce__ method which is used by the pickle protocol to determine how the object should be reconstructed. It uses this to reconstruct the defaultdict with the same default factory, by calling the type with a single argument of the default factory. Since your subclass's __init__ method takes no arguments, this results in the error you see. There are a couple of ways you could fix this. The first would be to change the signature of the __init__ method to take an optional argument accepting the default factory instead of hard-coding it, like this: def __init__(self, default_factory=int): super().__init__(default_factory, Joe=0) The other would be to just fix the __reduce__ method to not pass the default factory to your initializer, since it is hard-coded. That would look like this: def __reduce__(self): return (type(self), ()) Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: problems with shelve(), collections.defaultdict, self
On Sat, Feb 11, 2012 at 10:46 AM, Ian Kelly wrote: > The problem is that defaultdict defines a custom __reduce__ method > which is used by the pickle protocol to determine how the object > should be reconstructed. It uses this to reconstruct the defaultdict > with the same default factory, by calling the type with a single > argument of the default factory. Since your subclass's __init__ > method takes no arguments, this results in the error you see. > > There are a couple of ways you could fix this. The first would be to > change the signature of the __init__ method to take an optional > argument accepting the default factory instead of hard-coding it, like > this: > > def __init__(self, default_factory=int): > super().__init__(default_factory, Joe=0) > > The other would be to just fix the __reduce__ method to not pass the > default factory to your initializer, since it is hard-coded. That > would look like this: > > def __reduce__(self): > return (type(self), ()) It occurs to me that there's also an option 3: you don't really need a defaultdict to do what you're trying to do here. You just need a dict with a custom __missing__ method. That could look something like this: class Dog(dict): def __missing__(self): return 0 And then you don't have to worry about the weird pickle behavior of defaultdict at all. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: problems with shelve(), collections.defaultdict, self
On Sat, Feb 11, 2012 at 10:54 AM, Ian Kelly wrote: > class Dog(dict): > > def __missing__(self): > return 0 Sorry, that should have been: class Dog(dict): def __missing__(self, key): return 0 Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: MySQL: AttributeError: cursor
On Sat, 2012-02-11 at 09:40 -0800, Kevin Murphy wrote: > Hi All, > I'm using Python 2.7 and having a problem creating the cursor below. > Any suggestions would be appreciated! > > import sys > import _mysql > > print "cursor test" > > db = > _mysql.connect(host="localhost",user="root",passwd="mypw",db="python- > test") > > cursor = db.cursor() > > >>> > cursor test > > Traceback (most recent call last): > File "C:\Python27\dbconnect.py", line 8, in > cursor = db.cursor() > AttributeError: cursor You are using the low-level C API wrapper (not sure why). Most people, I believe, would use the pythonic API: >>> import MySQLdb >>> db = MySQLdb.connect(host='localhost', user='root', passwd='mypw', db='python-test') >>> cursor = db.cursor() The low-level API is... well.. for when you want to do low-level stuff. You probably want the pythonic API. -a -- http://mail.python.org/mailman/listinfo/python-list
Stopping a looping computation in IDLE 3.2.x
How do you stop a looping computation with IDLE 3.2.x on MacOS-X Lion ? It hangs with the colored wheel... Ctl-C does not work. Thanks, franck -- http://mail.python.org/mailman/listinfo/python-list
Re: problems with shelve(), collections.defaultdict, self
On Feb 11, 10:56 am, Ian Kelly wrote: > On Sat, Feb 11, 2012 at 10:54 AM, Ian Kelly wrote: > > class Dog(dict): > > > def __missing__(self): > > return 0 > > Sorry, that should have been: > > class Dog(dict): > > def __missing__(self, key): > return 0 > > Cheers, > Ian Thanks Ian! -- http://mail.python.org/mailman/listinfo/python-list
Building a debug version of Python 3.2.2 under Windows
I tried to build Python 3.2.2 with VS 2008, but it seems I'm missing some header files (e.g. sqlite3, openssl). Is there a nice little package with all the dependencies, or do I need to grab source code packages for each program from their respective websites, or something else entirely? -- CPython 3.2.2 | Windows NT 6.1.7601.17640 -- http://mail.python.org/mailman/listinfo/python-list
Re: ldap proxy user bind
sajuptpm wrote: I have developed a LDAP auth system using python-ldap module. Using that i can validate username and password, fetch user and groups info from LDAP directory. Now i want to implement ldap proxy user bind to the ldap server. What do you mean exactly? Are you talking about LDAPv3 proxy authorization (see http://tools.ietf.org/html/rfc4370)? If yes, then pass an instance of class ldap.controls.simple.ProxyAuthzControl to the LDAPObject methods when sending your LDAP requests. This is usable no matter how your proxy user has bound the directory. Another option is to send a SASL authz-ID along with the initial SASL bind request of your proxy user. No matter what you have to get your LDAP server configuration right for this to work. Which LDAP server is it? I googled and find this http://ldapwiki.willeke.com/wiki/LDAPProxyUser AFAICS this web page talks about the proxy user for eDirectory's LDAP gateway to NDS. It's unlikely that this is relevant to your needs. But i don't have any idea about how implement it usng python-ldap. [..] I want to add following 2 new flags ldap_proxy_user = ldap_proxy ldap_proxy_pwd = secret Hmm, please don't take it personally but my impression is that you're not totally clear on what you need. Could you please try to explain what you want to achieve? Ciao, Michael. -- http://mail.python.org/mailman/listinfo/python-list
[ANNOUNCE] greenlet 0.3.4
Hi, I have uploaded greenlet 0.3.4 to PyPI: http://pypi.python.org/pypi/greenlet What is it? --- The greenlet module provides coroutines for python. coroutines allow suspending and resuming execution at certain locations. concurrence[1], eventlet[2] and gevent[3] use the greenlet module in order to implement concurrent network applications. Documentation can be found here: http://greenlet.readthedocs.org The code is hosted on github: https://github.com/python-greenlet/greenlet Changes in version 0.3.4 The NEWS file lists these changes for release 0.3.4: * Use plain distutils for install command, this fixes installation of the greenlet.h header. * Enhanced arm32 support * Fix support for Linux/S390 zSeries * Workaround compiler bug on RHEL 3 / CentOS 3 [1] http://opensource.hyves.org/concurrence/ [2] http://eventlet.net/ [3] http://www.gevent.org/ -- Cheers Ralf Schmitt -- http://mail.python.org/mailman/listinfo/python-list
Re: Building a debug version of Python 3.2.2 under Windows
On 2/11/2012 3:02 PM, Andrew Berg wrote: I tried to build Python 3.2.2 with VS 2008, but it seems I'm missing some header files (e.g. sqlite3, openssl). Is there a nice little package with all the dependencies, or do I need to grab source code packages for each program from their respective websites, or something else entirely? The readme file in PCBuild supposedly has all the info needed, though I know one thing out of date. Trying to follow the instructions is on my todo list ;-). -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Python usage numbers
Does anyone have (or know of) accurate totals and percentages on how Python is used? I'm particularly interested in the following groupings: - new development vs. stable code-bases - categories (web, scripts, "big data", computation, etc.) - "bare metal" vs. on top of some framework - regional usage I'm thinking about this partly because of the discussion on python-ideas about the perceived challenges of Unicode in Python 3. All the rhetoric, anecdotal evidence, and use-cases there have little meaning to me, in regards to Python as a whole, without an understanding of who is actually affected. For instance, if frameworks (like django and numpy) could completely hide the arguable challenges of Unicode in Python 3--and most projects were built on top of frameworks--then general efforts for making Unicode easier in Python 3 should go toward helping framework writers. Not only are such usage numbers useful for the Unicode discussion (which I wish would get resolved and die so we could move on to more interesting stuff :) ). They help us know where efforts could be focused in general to make Python more powerful and easier to use where it's already used extensively. They can show us the areas that Python isn't used much, thus exposing a targeted opportunity to change that. Realistically, it's not entirely feasible to compile such information at a comprehensive level, but even generally accurate numbers would be a valuable resource. If the numbers aren't out there, what would some good approaches to discovering them? Thanks! -eric -- http://mail.python.org/mailman/listinfo/python-list
Can anyone send me the last version of psycopg2 by email?
I have a minor trouble here with my Internet connection. Can anyone send me the last version of psycopg2 to this email? Thanks a lot for the help. Regards and best wishes -- Marcos Luis Ortíz Valmaseda Sr. Software Engineer (UCI) http://marcosluis2186.posterous.com http://www.linkedin.com/in/marcosluis2186 Twitter: @marcosluis2186 Fin a la injusticia, LIBERTAD AHORA A NUESTROS CINCO COMPATRIOTAS QUE SE ENCUENTRAN INJUSTAMENTE EN PRISIONES DE LOS EEUU! http://www.antiterroristas.cu http://justiciaparaloscinco.wordpress.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Building a debug version of Python 3.2.2 under Windows
On 2/11/2012 3:01 PM, Terry Reedy wrote: > The readme file in PCBuild supposedly has all the info needed, though I > know one thing out of date. Trying to follow the instructions is on my > todo list ;-). > I didn't notice the readme in there. I was following instructions from here: http://docs.python.org/devguide/ Looks like the build process is a bit more complicated than just "Build Solution". Thanks. -- CPython 3.2.2 | Windows NT 6.1.7601.17640 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python usage numbers
Eric Snow, 11.02.2012 22:02: > - categories (web, scripts, "big data", computation, etc.) No numbers, but from my stance, the four largest areas where Python is used appear to be (in increasing line length order): a) web applications b) scripting and tooling c) high-performance computation d) testing (non-Python/embedded/whatever code) I'm sure others will manage to remind me of the one or two I forgot... Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python usage numbers
On 2/11/2012 3:02 PM, Eric Snow wrote: > I'm thinking about this partly because of the discussion on > python-ideas about the perceived challenges of Unicode in Python 3. > For instance, if frameworks (like django and numpy) could completely > hide the arguable challenges of Unicode in Python 3--and most projects > were built on top of frameworks--then general efforts for making > Unicode easier in Python 3 should go toward helping framework writers. Huh? I'll admit I'm a novice, but isn't Unicode mostly trivial in py3k compared to 2.x? Or are you referring to porting 2.x to 3.x? I've been under the impression that Unicode in 2.x can be painful at times, but easy in 3.x. I've been using 3.2 and Unicode hasn't been much of an issue. -- CPython 3.2.2 | Windows NT 6.1.7601.17640 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python usage numbers
On 11/02/2012 21:02, Eric Snow wrote: Does anyone have (or know of) accurate totals and percentages on how Python is used? I'm particularly interested in the following groupings: - new development vs. stable code-bases - categories (web, scripts, "big data", computation, etc.) - "bare metal" vs. on top of some framework - regional usage I'm thinking about this partly because of the discussion on python-ideas about the perceived challenges of Unicode in Python 3. All the rhetoric, anecdotal evidence, and use-cases there have little meaning to me, in regards to Python as a whole, without an understanding of who is actually affected. For instance, if frameworks (like django and numpy) could completely hide the arguable challenges of Unicode in Python 3--and most projects were built on top of frameworks--then general efforts for making Unicode easier in Python 3 should go toward helping framework writers. Not only are such usage numbers useful for the Unicode discussion (which I wish would get resolved and die so we could move on to more interesting stuff :) ). They help us know where efforts could be focused in general to make Python more powerful and easier to use where it's already used extensively. They can show us the areas that Python isn't used much, thus exposing a targeted opportunity to change that. Realistically, it's not entirely feasible to compile such information at a comprehensive level, but even generally accurate numbers would be a valuable resource. If the numbers aren't out there, what would some good approaches to discovering them? Thanks! -eric As others have said on other Python newsgroups it ain't a problem. The only time I've ever had a problem was with matplotlib which couldn't print a £ sign. I used a U to enforce unicode job done. If I had a major problem I reckon that a search on c.l.p would give me an answer easy peasy. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python usage numbers
On Sat, Feb 11, 2012 at 2:51 PM, Andrew Berg wrote: > On 2/11/2012 3:02 PM, Eric Snow wrote: >> I'm thinking about this partly because of the discussion on >> python-ideas about the perceived challenges of Unicode in Python 3. > >> For instance, if frameworks (like django and numpy) could completely >> hide the arguable challenges of Unicode in Python 3--and most projects >> were built on top of frameworks--then general efforts for making >> Unicode easier in Python 3 should go toward helping framework writers. > Huh? I'll admit I'm a novice, but isn't Unicode mostly trivial in py3k > compared to 2.x? Or are you referring to porting 2.x to 3.x? I've been > under the impression that Unicode in 2.x can be painful at times, but > easy in 3.x. > I've been using 3.2 and Unicode hasn't been much of an issue. My expectation is that yours is the common experience. However, in at least one current thread (on python-ideas) and at a variety of times in the past, _some_ people have found Unicode in Python 3 to make more work. So that got me to thinking about who's experience is the general case, and if any concerns broadly apply to more that framework/library writers (like django, jinja, twisted, etc.). Having usage statistics would be helpful in identifying the impact of things like Unicode in Python 3. -eric -- http://mail.python.org/mailman/listinfo/python-list
Re: Python usage numbers
On Sun, Feb 12, 2012 at 12:21 PM, Eric Snow wrote: > However, in at > least one current thread (on python-ideas) and at a variety of times > in the past, _some_ people have found Unicode in Python 3 to make more > work. If Unicode in Python is causing you more work, isn't it most likely that the issue would have come up anyway? For instance, suppose you have a web form and you accept customer names, which you then store in a database. You could assume that the browser submits it in UTF-8 and that your database back-end can accept UTF-8, and then pretend that it's all ASCII, but if you then want to upper-case the name for a heading, somewhere you're going to needto deal with Unicode; and when your programming language has facilities like str.upper(), that's going to make it easier, not later. Sure, the simple case is easier if you pretend it's all ASCII, but it's still better to have language facilities. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python usage numbers
On Sat, Feb 11, 2012 at 6:28 PM, Chris Angelico wrote: > On Sun, Feb 12, 2012 at 12:21 PM, Eric Snow > wrote: >> However, in at >> least one current thread (on python-ideas) and at a variety of times >> in the past, _some_ people have found Unicode in Python 3 to make more >> work. > > If Unicode in Python is causing you more work, isn't it most likely > that the issue would have come up anyway? For instance, suppose you > have a web form and you accept customer names, which you then store in > a database. You could assume that the browser submits it in UTF-8 and > that your database back-end can accept UTF-8, and then pretend that > it's all ASCII, but if you then want to upper-case the name for a > heading, somewhere you're going to needto deal with Unicode; and when > your programming language has facilities like str.upper(), that's > going to make it easier, not later. Sure, the simple case is easier if > you pretend it's all ASCII, but it's still better to have language > facilities. Yeah, that's how I see it too. However, my sample size is much too small to have any sense of the broader Python 3 experience. That's what I'm going for with those Python usage statistics (if it's even feasible). -eric -- http://mail.python.org/mailman/listinfo/python-list
Re: Python usage numbers
On Sun, 12 Feb 2012 12:28:30 +1100, Chris Angelico wrote: > On Sun, Feb 12, 2012 at 12:21 PM, Eric Snow > wrote: >> However, in at >> least one current thread (on python-ideas) and at a variety of times in >> the past, _some_ people have found Unicode in Python 3 to make more >> work. > > If Unicode in Python is causing you more work, isn't it most likely that > the issue would have come up anyway? The argument being made is that in Python 2, if you try to read a file that contains Unicode characters encoded with some unknown codec, you don't have to think about it. Sure, you get moji-bake rubbish in your database, but that's the fault of people who insist on not being American. Or who spell Zoe with an umlaut. In Python 3, if you try the same thing, you get an error. Fixing the error requires thought, and even if that is only a minuscule amount of thought, that's too much for some developers who are scared of Unicode. Hence the FUD that Python 3 is too hard because it makes you learn Unicode. I know this isn't exactly helpful, but I wish they'd just HTFU. I'm with Joel Spolsky on this one: if you're a programmer in 2003 who doesn't have at least a basic working knowledge of Unicode, you're the equivalent of a doctor who doesn't believe in germs. http://www.joelonsoftware.com/articles/Unicode.html Learning a basic working knowledge of Unicode is not that hard. You don't need to be an expert, and it's just not that scary. The use-case given is: "I have a file containing text. I can open it in an editor and see it's nearly all ASCII text, except for a few weird and bizarre characters like £ © ± or ö. In Python 2, I can read that file fine. In Python 3 I get an error. What should I do that requires no thought?" Obvious answers: - Try decoding with UTF8 or Latin1. Even if you don't get the right characters, you'll get *something*. - Use open(filename, encoding='ascii', errors='surrogateescape') (Or possibly errors='ignore'.) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python usage numbers
On Feb 11, 8:23 pm, Steven D'Aprano wrote: > On Sun, 12 Feb 2012 12:28:30 +1100, Chris Angelico wrote: > > On Sun, Feb 12, 2012 at 12:21 PM, Eric Snow > > wrote: > >> However, in at > >> least one current thread (on python-ideas) and at a variety of times in > >> the past, _some_ people have found Unicode in Python 3 to make more > >> work. > > > If Unicode in Python is causing you more work, isn't it most likely that > > the issue would have come up anyway? > > The argument being made is that in Python 2, if you try to read a file > that contains Unicode characters encoded with some unknown codec, you > don't have to think about it. Sure, you get moji-bake rubbish in your > database, but that's the fault of people who insist on not being > American. Or who spell Zoe with an umlaut. That's not the worst of it... i have many times had a block of text that was valid ASCII except for some intermixed Unicode white-space. Who the hell would even consider inserting Unicode white-space!!! > "I have a file containing text. I can open it in an editor and see it's > nearly all ASCII text, except for a few weird and bizarre characters like > £ © ± or ö. In Python 2, I can read that file fine. In Python 3 I get an > error. What should I do that requires no thought?" > > Obvious answers: the most obvious answer would be to read the file WITHOUT worrying about asinine encoding. -- http://mail.python.org/mailman/listinfo/python-list
Re: ldap proxy user bind
On 02/11/2012 02:19 PM, sajuptpm wrote: > Hi Michael Ströder, > Thanks for replay > > Yea i am not totally clear about that > > Client's Requirement is > option to have a ldap proxy user bind to the ldap server if it needs > more directory rights than an anonymous bind. > option to use a ldap proxy user when searching. I wrote a true LDAP proxy server last year that intercepts and rewrites requests (bind, search, modify, etc). I used as my basis the LDAP proxy server that ships with Python-Twisted. Unfortunately I cannot share my code with you, but if you can get your head wrapped around Twisted (it's *extremely* hard to understand how it works at first), then this is the way to go. -- http://mail.python.org/mailman/listinfo/python-list
Re: ldap proxy user bind
On 02/11/2012 08:35 PM, Michael Torrie wrote: > On 02/11/2012 02:19 PM, sajuptpm wrote: >> Hi Michael Ströder, >> Thanks for replay >> >> Yea i am not totally clear about that >> >> Client's Requirement is >> option to have a ldap proxy user bind to the ldap server if it needs >> more directory rights than an anonymous bind. >> option to use a ldap proxy user when searching. > > I wrote a true LDAP proxy server last year that intercepts and rewrites > requests (bind, search, modify, etc). I used as my basis the LDAP proxy > server that ships with Python-Twisted. Unfortunately I cannot share my > code with you, but if you can get your head wrapped around Twisted (it's > *extremely* hard to understand how it works at first), then this is the > way to go. Okay so I looked over my code. I can share some of it with you if you want. The most simple proxy I could find (I have written several for various purposes) was based on the Twisted LDAP proxy server class (ldaptor.protocols.ldap.proxy). The reason I wrote it was because I had some Sharp multi-function printers that could do LDAP authentication, but instead of binding with a full DN, it would simply bind as "username" which wouldn't work on my ldap server. So I wrote the LDAP proxy server to intercept bind requests (Sharp doesn't even support SSL blah!) and convert it to a proper DN before passing it on to the real LDAP server. Also the LDAP search queries the sharp server generated were crappy, so I rewrote some of the searches as well as they pass through my proxy server. I sharp ===> Twisted LDAP server/Twisted LDAP client ===> ldapserver rewrite bind, rewrite some searches, pass thru everything My other LDAP proxy is fancier and it uses the ldaptor.protocols.ldap.ldapserver.BaseLDAPServer class, and instead of using twisted's LDAP client code, I just use python-ldap. So it's a hybrid approach I suppose. I can strip it down to bare proxy functionality that you could build on. client ==> twisted ldap server/python-ldap client ===> ldapserver Anyway let me know if you want to see some code and I'll post what I can. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python usage numbers
On Sun, Feb 12, 2012 at 1:36 PM, Rick Johnson wrote: > On Feb 11, 8:23 pm, Steven D'Aprano [email protected]> wrote: >> "I have a file containing text. I can open it in an editor and see it's >> nearly all ASCII text, except for a few weird and bizarre characters like >> £ © ± or ö. In Python 2, I can read that file fine. In Python 3 I get an >> error. What should I do that requires no thought?" >> >> Obvious answers: > > the most obvious answer would be to read the file WITHOUT worrying > about asinine encoding. What this statement misunderstands, though, is that ASCII is itself an encoding. Files contain bytes, and it's only what's external to those bytes that gives them meaning. The famous "bush hid the facts" trick with Windows Notepad shows the folly of trying to use internal evidence to identify meaning from bytes. Everything that displays text to a human needs to translate bytes into glyphs, and the usual way to do this conceptually is to go via characters. Pretending that it's all the same thing really means pretending that one byte represents one character and that each character is depicted by one glyph. And that's doomed to failure, unless everyone speaks English with no foreign symbols - so, no mathematical notations. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Stopping a looping computation in IDLE 3.2.x
In article , Franck Ditter wrote: > How do you stop a looping computation with IDLE 3.2.x on MacOS-X Lion ? > It hangs with the colored wheel... > Ctl-C does not work. Ctrl-C in the IDLE shell window works for me on OS X 10.7 Lion. Did you use the python.org 3.2.2 64-bit-/32-bit installer for 10.6? Do you have the latest ActiveState Tcl/Tk 8.5.11 installed? http://www.python.org/download/mac/tcltk/ -- Ned Deily, [email protected] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python usage numbers
On Sun, 12 Feb 2012 15:38:37 +1100, Chris Angelico wrote: > Everything that displays text to a human needs to translate bytes into > glyphs, and the usual way to do this conceptually is to go via > characters. Pretending that it's all the same thing really means > pretending that one byte represents one character and that each > character is depicted by one glyph. And that's doomed to failure, unless > everyone speaks English with no foreign symbols - so, no mathematical > notations. Pardon me, but you can't even write *English* in ASCII. You can't say that it cost you £10 to courier your résumé to the head office of Encyclopædia Britanica to apply for the position of Staff Coördinator. (Admittedly, the umlaut on the second "o" looks a bit stuffy and old-fashioned, but it is traditional English.) Hell, you can't even write in *American*: you can't say that the recipe for the 20¢ WobblyBurger™ is © 2012 WobblyBurgerWorld Inc. ASCII truly is a blight on the world, and the sooner it fades into obscurity, like EBCDIC, the better. Even if everyone did change to speak ASCII, you still have all the historical records and documents and files to deal with. Encodings are not going away. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python usage numbers
On Sun, Feb 12, 2012 at 4:51 PM, Steven D'Aprano wrote: > You can't say that it cost you £10 to courier your résumé to the head > office of Encyclopædia Britanica to apply for the position of Staff > Coördinator. True, but if it cost you $10 (or 10 GBP) to courier your curriculum vitae to the head office of Encyclopaedia Britannica to become Staff Coordinator, then you'd be fine. And if it cost you $10 to post your work summary to Britannica's administration to apply for this Staff Coordinator position, you could say it without 'e' too. Doesn't mean you don't need Unicode! ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python usage numbers
On Sat, 11 Feb 2012 18:36:52 -0800, Rick Johnson wrote: >> "I have a file containing text. I can open it in an editor and see it's >> nearly all ASCII text, except for a few weird and bizarre characters >> like £ © ± or ö. In Python 2, I can read that file fine. In Python 3 I >> get an error. What should I do that requires no thought?" >> >> Obvious answers: > > the most obvious answer would be to read the file WITHOUT worrying about > asinine encoding. Your mad leet reading comprehension skillz leave me in awe Rick. If you try to read a file containing non-ASCII characters encoded using UTF8 on Windows without explicitly specifying either UTF8 as the encoding, or an error handler, you will get an exception. It's not just UTF8 either, but nearly all encodings. You can't even expect to avoid problems if you stick to nothing but Windows, because Windows' default encoding is localised: a file generated in (say) Israel or Japan or Germany will use a different code page (encoding) by default than one generated in (say) the US, Canada or UK. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Numeric root-finding in Python
This is only peripherally a Python problem, but in case anyone has any
good ideas I'm going to ask it.
I have a routine to calculate an approximation of Lambert's W function,
and then apply a root-finding technique to improve the approximation.
This mostly works well, but sometimes the root-finder gets stuck in a
cycle.
Here's my function:
import math
def improve(x, w, exp=math.exp):
"""Use Halley's method to improve an estimate of W(x) given
an initial estimate w.
"""
try:
for i in range(36): # Max number of iterations.
ew = exp(w)
a = w*ew - x
b = ew*(w + 1)
err = -a/b # Estimate of the error in the current w.
if abs(err) <= 1e-16:
break
print '%d: w= %r err= %r' % (i, w, err)
# Make a better estimate.
c = (w + 2)*a/(2*w + 2)
delta = a/(b - c)
w -= delta
else:
raise RuntimeError('calculation failed to converge', err)
except ZeroDivisionError:
assert w == -1
return w
Here's an example where improve() converges very quickly:
py> improve(-0.36, -1.222769842388856)
0: w= -1.222769842388856 err= -2.9158979924038895e-07
1: w= -1.2227701339785069 err= 8.4638038491998997e-16
-1.222770133978506
That's what I expect: convergence in only a few iterations.
Here's an example where it gets stuck in a cycle, bouncing back and forth
between two values:
py> improve(-0.36787344117144249, -1.0057222396915309)
0: w= -1.0057222396915309 err= 2.6521238905750239e-14
1: w= -1.0057222396915044 err= -2.6521238905872001e-14
2: w= -1.0057222396915309 err= 2.6521238905750239e-14
3: w= -1.0057222396915044 err= -2.6521238905872001e-14
4: w= -1.0057222396915309 err= 2.6521238905750239e-14
5: w= -1.0057222396915044 err= -2.6521238905872001e-14
[...]
32: w= -1.0057222396915309 err= 2.6521238905750239e-14
33: w= -1.0057222396915044 err= -2.6521238905872001e-14
34: w= -1.0057222396915309 err= 2.6521238905750239e-14
35: w= -1.0057222396915044 err= -2.6521238905872001e-14
Traceback (most recent call last):
File "", line 1, in
File "", line 19, in improve
RuntimeError: ('calculation failed to converge', -2.6521238905872001e-14)
(The correct value for w is approximately -1.00572223991.)
I know that Newton's method is subject to cycles, but I haven't found any
discussion about Halley's method and cycles, nor do I know what the best
approach for breaking them would be. None of the papers on calculating
the Lambert W function that I have found mentions this.
Does anyone have any advice for solving this?
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python usage numbers
On 2/12/2012 12:10 AM, Steven D'Aprano wrote: > It's not just UTF8 either, but nearly all encodings. You can't even > expect to avoid problems if you stick to nothing but Windows, because > Windows' default encoding is localised: a file generated in (say) Israel > or Japan or Germany will use a different code page (encoding) by default > than one generated in (say) the US, Canada or UK. Generated by what? Windows will store a locale value for programs to use, but programs use Unicode internally by default (i.e., API calls are Unicode unless they were built for old versions of Windows), and the default filesystem (NTFS) uses Unicode for file names. AFAIK, only the terminal has a localized code page by default. Perhaps Notepad will write text files with the localized code page by default, but that's an application choice... -- CPython 3.2.2 | Windows NT 6.1.7601.17640 -- http://mail.python.org/mailman/listinfo/python-list
Re: ldap proxy user bind
Hi Michael Torrie, Thanks to reply Why we need Twisted here, i did not get it. My understanding is that if ldap_proxy_user = ldap_proxy ldap_proxy_pwd = secret ( set more privileges to this user at ldap server side, for get other users infos) are configured at server side, then allow clients to login using username only, this time use ldap_proxy_user and ldap_proxy_pwd for login to ldap server, user validation and get user infos. Is it possible and any drawback I think this is what client need. -- http://mail.python.org/mailman/listinfo/python-list
