Re: LDAP: How get all users belongs to a group.
On Thu, Jun 23, 2011 at 9:14 AM, sajuptpm wrote: > Hi, > How get all users belongs to a group using python ldap module. Depends on what you mean by "users" and "group", what information you already have, and what information you want to get. I'll assume you mean posix accounts and groups, and that you already know how to connect to the LDAP server. If you already know the distinguished name of the group, you can get a list of the member names like so (ignoring error handling): dn, entry = connection.search_s(group_dn, ldap.SCOPE_BASE)[0] member_list = entry['memberUid'] That will only get you the usernames. If you need to get the user's entry (or don't know the group_dn above), then you'll have to do a bit more searching. To find a user's entry given their uid: results = connection.search_s(base_dn, ldap.SCOPE_SUBTREE, "(uid=*)") for dn, entry in results: if uid in entry['uid']: # this is your guy. return, or break, or whatever The "(uid=*)" filter just means to only find entries that have user id fields. If you wanted to be more specific about it, you could limit it to only posixAccount objects with "(objectClass=posixAccount)". This would probably be necessary if you wanted to search for groups (via "(objectClass=posixGroup)" ), since those don't have a special field for their name - they usually just use the cn (common name) field for that. A slightly more complex filter could be written to avoid the python loop. If your groups are not posixGroup objects but instead groupOfNames, then the appropriate attribute is "member" rather than "memberUid", and the values there are user DNs instead of uids. In that case, if you need the uid you'll have to look up those users and pull it out. -- http://mail.python.org/mailman/listinfo/python-list
Re: perceptron feed forward neural networks in python
On Mon, Jul 11, 2011 at 2:31 PM, Igor Begić wrote: > Hi, > I,m new to Python and i want to study and write programs about perceptron > feed forward neural networks in python. Does anyone have a good book or link > for this? Try Stephen Marsland's "Machine Learning: An Algorithmic Perspective". All example code is done in Python, and there's a chapter on multilayer perceptrons. The code for the book is available online here: http://www-ist.massey.ac.nz/smarsland/MLbook.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Wondering in the Python Forrest
On Sat, Jul 30, 2011 at 7:13 AM, ray wrote: > I found that structured data could be presented in Python using a module in > wxPython. > > Where am I? I do not know the relationships between the Pythons. I > feel that I am missing something. I started with Python as it has so > much functionality and a huge user group of very helpful individuals > and sites. Now that I have delved deeper, it seems I need different > Pythons. I think the name has caused you some confusion. wxPython is not a different Python, it's a package for Python that displays GUI components using the C++ "wxWidgets" library. While there are other Pythons out there, for scientific work you should have everything you need in the one you've got. You may have to install an additional package now and then, but that's it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Replace all references to one object with references to other
On Fri, Aug 5, 2011 at 3:37 PM, Jack Bates wrote: > I have two objects, and I want to replace all references to the first > object - everywhere - with references to the second object. What can I > try? If using PyPy instead of CPython is an option, the "thunk" object space's "become" function can apparently do this: http://doc.pypy.org/en/latest/objspace-proxies.html#the-thunk-object-space In CPython, this might be a tad difficult. At the C level, a reference to a python object is just a pointer to it. You could iterate through the entire address space looking for values that equal a particular pointer, but changing them would be dangerous, since memory isn't labeled by type - you can't tell if the memory is a pointer to your object or an important part of some other data structure. If you could narrow down what you want to accomplish, this might be easier. For instance, if all you need is to replace module-level references to the object, that can be done. -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for the shelve module?
On Fri, Aug 19, 2011 at 11:31 AM, Forafo San wrote: > Folks, > What might be a good replacement for the shelve module, but one that > can handle a few gigs of data. I'm doing some calculations on daily > stock prices and the result is a nested list like: For what you're doing, I would give PyTables a try. -- http://mail.python.org/mailman/listinfo/python-list
Re: dpkg
On Fri, Aug 26, 2011 at 10:43 AM, Verde Denim 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: I think I found a mistake in the official language reference documentation -- or I am missing somethig???
On Wed, Apr 27, 2011 at 4:02 PM, Igor Soares wrote: > Reading the section "6.11. The import statement" > http://docs.python.org/py3k/reference/simple_stmts.html#the-import-statement > > I found: > """ > Import statements are executed in two steps: (1) find a module, and > initialize it if necessary; (2) define a name or names in the local > namespace (of the scope where the import statement occurs). > (...) > The first form (without from) repeats these steps for each identifier > in the list. The form with from performs step (1) once, and then > performs step (2) repeatedly. > """ > In the last sentence, isn't it the opposite? > With the "from" form it would find/initialize all the modules and > define just the name after "from". > Or am I missing something? Judging only by what you've quoted, the forms would be: 1) import os, sys, glob 2) from os.path import exists, split, join In the first form, one or more modules come after the 'import'. In the second form, a single module comes after the 'from', and then multiple names from within that module come after the 'import'. Looks fine to me. -- http://mail.python.org/mailman/listinfo/python-list
Re: rstrip()
On Fri, Jul 16, 2010 at 12:58 PM, Jason Friedman wrote:
> $ python
> Python 2.6.4 (r264:75706, Dec 7 2009, 18:43:55)
> [GCC 4.4.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
"x.vsd-dir".rstrip("-dir")
> 'x.vs'
>
> I expected 'x.vsd' as a return value.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
rstrip strips a given set of characters, not a specific string. '-dir'
contains d, so the trailing d is also stripped.
--
http://mail.python.org/mailman/listinfo/python-list
Exposing buffer interface for non-extension types?
Is there any way to expose the PEP 3118 buffer interface for objects that aren't extension types? Currently, I can expose the NumPy array interface (using either __array_interface__ or __array_struct__) for any class, extension or otherwise. But I can't find any reference to python-side interfacing for PEP 3118. SWIG makes an extension module for your wrapped code, but not extension *types*, so the classes it produces are pure-python with methods added in from the extension module. The NumPy array interface works fine for now (especially since NumPy is the only thing I need to consume these objects), but the documentation claims that it's being deprecated in favor of PEP 3118, so I thought it might be relevant to bring this up. -- http://mail.python.org/mailman/listinfo/python-list
Re: Exposing buffer interface for non-extension types?
On Tue, Jul 20, 2010 at 6:58 PM, Stefan Behnel wrote: > Ken Watford, 21.07.2010 00:09: >> >> Is there any way to expose the PEP 3118 buffer interface for objects >> that aren't extension types? > > Given that it's a pure C-level interface, I don't think there would be much > use for that. Perhaps, but *why* is it only a pure C-level interface? It's based on/inspired by the array interface, which was not a pure C-level interface. Did they simply neglect to provide the functionality due to lack of obvious use cases, or did they consciously decide to drop that functionality? >> Currently, I can expose the NumPy array interface (using either >> __array_interface__ or __array_struct__) for any class, extension or >> otherwise. But I can't find any reference to python-side interfacing >> for PEP 3118. SWIG makes an extension module for your wrapped code, >> but not extension *types*, so the classes it produces are pure-python >> with methods added in from the extension module. > > Try using Cython instead, it has native support for the buffer protocol. I've used Cython before, and I generally like it. But its purpose is slightly different than SWIG's, and does not particularly meet my current project's needs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Exposing buffer interface for non-extension types?
On Tue, Jul 20, 2010 at 8:28 PM, Carl Banks wrote: > On Jul 20, 3:09 pm, Ken Watford wrote: >> Is there any way to expose the PEP 3118 buffer interface for objects >> that aren't extension types? >> >> Currently, I can expose the NumPy array interface (using either >> __array_interface__ or __array_struct__) for any class, extension or >> otherwise. But I can't find any reference to python-side interfacing >> for PEP 3118. SWIG makes an extension module for your wrapped code, >> but not extension *types*, so the classes it produces are pure-python >> with methods added in from the extension module. >> >> The NumPy array interface works fine for now (especially since NumPy >> is the only thing I need to consume these objects), but the >> documentation claims that it's being deprecated in favor of PEP 3118, >> so I thought it might be relevant to bring this up. > > Can you tell let us know what you want to use it for? We could offer > better help. > > Numpy is generally how I get at buffers in Python 2.x. For instance > if I have an object m that supports buffer protocol (m could a string, > mmap object, Python array, etc.), then the following will create an > array view of the same buffer: > > numpy.ndarray((10,10),type=numpy.float32,buffer=m) > > As far as I know this procedure won't be too different under PEP 3118; > if anything it's simplified in Python 3 since it can discover type and > shape information itself. (You'll have to check with the numpy people > on that.) I'm not having trouble using buffers, I'm having trouble providing them. As a part of SWIG-wrapping a larger C++ project, I'm producing some wrappings for Blitz++ arrays. I can extract the shape and stride information from the array object to fill either NumPy's or PEP 3118's appropriate structure. In the case of NumPy, I can easily arrange for the necessary interface on the proxy object to be fulfilled, because NumPy doesn't care what kind of object it's attached to. But the PEP 3118 interface can only be provided by C extension types. One possibility I've considered is injecting a small extension type into the wrapper that provides PEP 3118 by reading the NumPy array interface info off of the object, and then inject it into all appropriate SWIG-generated proxy classes as an additional base class. This isn't a big deal for me - the array interface works just fine, and probably will for longer than I'll be working on this project - but it just struck me as strange that some of my existing array-interface-enabled classes can't be trivially ported to PEP 3118 because they're defined in pure Python modules rather than extension modules. -- http://mail.python.org/mailman/listinfo/python-list
Re: Exposing buffer interface for non-extension types?
On Tue, Jul 20, 2010 at 9:26 PM, Robert Kern wrote: > On 7/20/10 8:38 PM, Ken Watford wrote: >> >> On Tue, Jul 20, 2010 at 6:58 PM, Stefan Behnel >> wrote: >>> >>> Ken Watford, 21.07.2010 00:09: >>>> >>>> Is there any way to expose the PEP 3118 buffer interface for objects >>>> that aren't extension types? >>> >>> Given that it's a pure C-level interface, I don't think there would be >>> much >>> use for that. >> >> Perhaps, but *why* is it only a pure C-level interface? It's based >> on/inspired by the array interface, which was not a pure C-level >> interface. Did they simply neglect to provide the functionality due to >> lack of obvious use cases, or did they consciously decide to drop thaThat >> functionality? > > Lack of obvious use cases. The primary use case is for C extensions to > communicate with each other. SWIG is the odd man out in that it does not > create true extension types. While the functionality of the PEP derives from > numpy's interface, it's inclusion in Python was largely seen as the > extension of the older buffer interface which is also a pure C interface. > > The Python-level __array_interface__ numpy API is not and will not be > deprecated despite some outdated language in the documentation. Please > continue to use it. Thanks, that's good to know. (Someone should probably do something about the big red box that says the opposite in the current docs). I assume the same is true about __array_struct__? Since it *is* an extension despite the non-extension types, filling in a structure is a little more convenient than building the dictionary. -- http://mail.python.org/mailman/listinfo/python-list
Re: Down with tinyurl! (was Re: importing excel data into a python matrix?)
On Sun, Sep 19, 2010 at 9:16 AM, Aahz wrote: > In article , > geremy condra wrote: >>On Wed, Sep 1, 2010 at 4:35 PM, patrick mcnameeking >> wrote: >>> >>> I've been working with Python now for about a year using it primarily for >>> scripting in the Puredata graphical programming environment. I'm working on >>> a project where I have been given a 1000 by 1000 cell excel spreadsheet and >>> I would like to be able to access the data using Python. Does anyone know >>> of a way that I can do this? >> >>http://tinyurl.com/2eqqjxv > > Please don't use tinyurl -- it's opaque and provides zero help to anyone > who might later want to look it up (and also no accessibility if tinyurl > ever goes down). At the very least, include the original URL for > reference. > > (Yes, I realize this is probably a joke given the smiley I excised, but > too many people do just post tinyurl.) Not that I disagree with you, but you might find this helpful: http://tinyurl.com/preview.php -- http://mail.python.org/mailman/listinfo/python-list
Re: Python3: API Documentation generator
On Mon, Sep 27, 2010 at 1:15 PM, Tim Diels wrote:
> On 27/09/2010 09:02, Chris Rebert wrote:
>>
>> On Sun, Sep 26, 2010 at 11:56 PM, Tim Diels wrote:
>>>
>>> Hi all
>>>
>>> I've just switched to python3 and it turns out my current API
>>> documentation
>>> generator (epydoc) no longer works. I am looking for a tool that reads
>>> the
>>> docstrings of all classes, ... in my project and turns it into HTML
>>> documentation.
>>
>> Sphinx (http://sphinx.pocoo.org/ ) is the new gold standard. You'll
>> want to enable the `autodoc` extension:
>> http://sphinx.pocoo.org/ext/autodoc.html
>>
>> Cheers,
>> Chris
>> --
>> http://blog.rebertia.com
>
> I tried, but it fails to run through python code that's not backwards
> compatible with older python versions.
>
> It fails with: ...autodoc can't import/find module 'pytilities', it reported
> error: "invalid syntax (overload.py, line 55)"...
>
> This is line 55 (runs in python3, not in python):
> def process_args(self, *args, kwargs={})
>
As far as I'm aware, autodoc works by importing the modules and then
reading doctext straight from the __doc__ attributes.
So the module in question has to import correctly in whatever
interpreter Sphinx is using. You probably need to install Sphinx with
python3 to get it to use the right interpreter. If you're using
easy_install or pip, check if you have an easy_install-3.1 or pip-3.1
(or similar) script installed.
--
http://mail.python.org/mailman/listinfo/python-list
Re: factorial of negative one (-1)
On Mon, Nov 1, 2010 at 5:42 AM, Hrvoje Niksic wrote: > > Printing out further digits (without quotes) is not pointless if you > want to find out the exact representation of your number in python's > floating point, for educational purposes or otherwise. Python has a > little-known but very instructive method for determining the makeup of a > float: > 1.1 .as_integer_ratio() > (2476979795053773, 2251799813685248) > Handy, but if you need the exact representation, my preference is float.hex, which seems to be the same as C99's %a format. >>> math.pi.hex() '0x1.921fb54442d18p+1' >>> float.fromhex(math.pi.hex()) == math.pi True Granted, it's not as easy for humans to interpret, but it's useful for certain things. -- http://mail.python.org/mailman/listinfo/python-list
