Search Results

Search found 59 results on 3 pages for 'pypi'.

Page 3/3 | < Previous Page | 1 2 3 

  • Does Python work in larger teams?

    - by Kugel
    I read this post last night and it got me thinking. I like python and "batteries", pypi and such. But I've only done python solo. Never tried it in a team. Are the points that Ted mentions valid? If they are how do teams cope with them? Does Python work in teams or even large teams? Or it kills productivity? I personally see the problems he mentions when I come back to my old code. Even when working with other modules sometimes I need to peek inside. I would like to hear people with experience on this.

    Read the article

  • just-in-time list

    - by intuited
    I'd like to know if there is a class available, either in the standard library or in pypi, that fits this description. The constructor would take an iterator. It would implement the container protocol (ie _getitem_, _len_, etc), so that slices, length, etc., would work. In doing so, it would iterate and retain just enough values from its constructor argument to provide whatever information was requested. So if jitlist[6] was requested, it would call self.source.next() 7 times, save those elements in its list, and return the last one. This would allow downstream code to use it as a list, but avoid unnecessarily instantiating a list for cases where list functionality was not needed, and avoid allocating memory for the entire list if only a few members ended up being requested. It seems like a pretty easy one to write, but it also seems useful enough that it's likely that someone would have already made it available in a module.

    Read the article

  • What's the best way to create a static utility class in python? Is using metaclasses code smell?

    - by rsimp
    Ok so I need to create a bunch of utility classes in python. Normally I would just use a simple module for this but I need to be able to inherit in order to share common code between them. The common code needs to reference the state of the module using it so simple imports wouldn't work well. I don't like singletons, and classes that use the classmethod decorator do not have proper support for python properties. One pattern I see used a lot is creating an internal python class prefixed with an underscore and creating a single instance which is then explicitly imported or set as the module itself. This is also used by fabric to create a common environment object (fabric.api.env). I've realized another way to accomplish this would be with metaclasses. For example: #util.py class MetaFooBase(type): @property def file_path(cls): raise NotImplementedError def inherited_method(cls): print cls.file_path #foo.py from util import * import env class MetaFoo(MetaFooBase): @property def file_path(cls): return env.base_path + "relative/path" def another_class_method(cls): pass class Foo(object): __metaclass__ = MetaFoo #client.py from foo import Foo file_path = Foo.file_path I like this approach better than the first pattern for a few reasons: First, instantiating Foo would be meaningless as it has no attributes or methods, which insures this class acts like a true single interface utility, unlike the first pattern which relies on the underscore convention to dissuade client code from creating more instances of the internal class. Second, sub-classing MetaFoo in a different module wouldn't be as awkward because I wouldn't be importing a class with an underscore which is inherently going against its private naming convention. Third, this seems to be the closest approximation to a static class that exists in python, as all the meta code applies only to the class and not to its instances. This is shown by the common convention of using cls instead of self in the class methods. As well, the base class inherits from type instead of object which would prevent users from trying to use it as a base for other non-static classes. It's implementation as a static class is also apparent when using it by the naming convention Foo, as opposed to foo, which denotes a static class method is being used. As much as I think this is a good fit, I feel that others might feel its not pythonic because its not a sanctioned use for metaclasses which should be avoided 99% of the time. I also find most python devs tend to shy away from metaclasses which might affect code reuse/maintainability. Is this code considered code smell in the python community? I ask because I'm creating a pypi package, and would like to do everything I can to increase adoption.

    Read the article

  • Error with python-setuptools doing "sudo easy_install python-graph-core"

    - by Dan
    Using easy_install, part of the python-setuptools, I get the following error: $ sudo easy_install python-graph-core [sudo] password for dan: Searching for python-graph-core Reading http://pypi.python.org/simple/python-graph-core/ Reading http://code.google.com/p/python-graph/ Reading http://code.google.com/p/python-graph/downloads/list?can=1 Reading http://code.google.com/p/python-graph/downloads/list Best match: python-graph-core 1.7.0 Downloading http://python-graph.googlecode.com/files/python-graph-core-1.7.0.tar.gz Processing python-graph-core-1.7.0.tar.gz Running python-graph-core-1.7.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-GwpYiM/python-graph-core-1.7.0/egg-dist-tmp-1yqbyV setup.py:8: Warning: 'as' will become a reserved keyword in Python 2.6 Traceback (most recent call last): File "/usr/bin/easy_install", line 8, in <module> load_entry_point('setuptools==0.6c9', 'console_scripts', 'easy_install')() File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1671, in main with_ei_usage(lambda: File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1659, in with_ei_usage return f() File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1675, in <lambda> distclass=DistributionWithoutHelpCommands, **kw File "/usr/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 211, in run self.easy_install(spec, not self.no_deps) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 446, in easy_install return self.install_item(spec, dist.location, tmpdir, deps) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 476, in install_item dists = self.install_eggs(spec, download, tmpdir) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 655, in install_eggs return self.build_and_install(setup_script, setup_base) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 930, in build_and_install self.run_setup(setup_script, setup_base, args) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 919, in run_setup run_setup(setup_script, args) File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 27, in run_setup lambda: execfile( File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 63, in run return func() File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 29, in <lambda> {'__file__':setup_script, '__name__':'__main__'} File "setup.py", line 8 except ImportError as ie: ^ SyntaxError: invalid syntax Any suggestions to what I may be doing wrong? Thanks, Dan

    Read the article

  • How can I use the Homebrew Python with Homebrew MacVim on Mountain Lion?

    - by Stephen Jennings
    I originally asked and answered this question: How can I use the Homebrew Python version with Homebrew MacVim? These instructions worked on Snow Leopard using Xcode 4.0.1 and associated developer tools. However, they no longer seem to work on Mountain Lion with Xcode 4.4.1. My goal is to leave the system's version of Python completely untouched, and to only install PyPI packages into Homebrew's site-packages directory. I want to use the vim_bridge package in MacVim, so I need to compile MacVim against the Homebrew version of Python. I've edited the MacVim formula to add these to the arguments: --enable-pythoninterp=dynamic --with-python-config-dir=/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/Current/lib/python2.7/config Then I install with the command: brew install macvim --override-system-vim --custom-icons --with-cscope --with-lua However, it still seems to be somehow using Python 2.7.2 from the system. This seems strange to me because it also seems to be using the correct executable. :python print(sys.version) 2.7.2 (default, Jun 20 2012, 16:23:33) [GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] :python print(sys.executable) /usr/local/bin/python $ /usr/local/bin/python --version Python 2.7.3 $ /usr/local/bin/python -c "import sys; print(sys.version)" 2.7.3 (default, Aug 12 2012, 21:17:22) [GCC 4.2.1 Compatible Apple Clang 4.0 ((tags/Apple/clang-421.0.60))] $ readlink /usr/local/lib/python2.7/config /usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/Current/lib/python2.7/config I've removed everything in /usr/local and reinstalled Homebrew by running these commands: $ ruby <(curl -fsSkL raw.github.com/mxcl/homebrew/go) $ brew install git mercurial python ruby $ brew install macvim (nope, still broken) $ brew remove macvim $ ln -s /usr/local/Cellar/python/..../python2.7/config /usr/local/lib/python2.7/config $ brew install macvim

    Read the article

  • Almost every Inkscape extension yields an error in Mac OS X

    - by andyvn22
    I've run the latest few versions of Inkscape (currently landed on "0.47+devel"), and have been having trouble with the Extensions menu. So far, in every version of Inkscape I've tried, nearly every extension yields the following error: The fantastic lxml wrapper for libxml2 is required by inkex.py and therefore this extension. Please download and install the latest version from http://cheeseshop.python.org/pypi/lxml/, or install it through your package manager by a command like: sudo apt-get install python-lxml I've tried the instructions listed there, of course, with no effect. I've also found many references to this issue on fora, in bug trackers, etc., and as such also tried: sudo easy_install lxml cd /Applications/Inkscape.app/Contents/Resources/lib mv libxml2.2.dylib libxml2.2.dylib.old ln -s /usr/lib/libxml2.dylib and a few similar solutions. Nothing has produced any change in Inkscape's behavior. Does anyone know A) what's really going on here? Because from what I gather the error is not describing the actual problem. And of course B) a simple solution? I need those features! :)

    Read the article

  • Having a Python package install itself under a different name

    - by cool-RR
    I'm developing a package called garlicsim. (Website.) The package is intended for Python 2.X, but I am also offerring Python 3 support on a different fork called garlicsim_py3.(1) So both of these packages live side by side on PyPI, and Python 3 users install garlicsim_py3, and Python 2 users install garlicsim. The problem is: When third party modules want to use garlicsim, they should have one package name to refer to, not two. Sure, they can do something like this: try: import garlicsim except ImportError: import garlicsim_py3 as garlicsim But I would prefer not to make the developers of these modules do this. Is there a way that garlicsim_py3 will install itself under the alias garlicsim? What I want is for a Python 3 user to be able to import garlicsim and refer to the module all the time as garlicsim, but that it will really be garlicsim_py3. I know that the Distribute project does something like this: They make it so you can import setuptools and it will be redirected into their code. I have no idea how they do it. Any ideas? (1) I've reached the decision to support Python 3 on a fork instead of in the same code base; It's important for me that the code base will be clean, and I would really not want to introduce compatibilty hacks.

    Read the article

  • Can't install egenix-mx-base on Django production VPS

    - by Shane
    I have been following these instructions for setting up a Django production server with postgres, apache, nginx, and memcache. My problem is that I cannot get egenix-mx-base to install and without this I cannot get psycopg2 to work and therefore no database access :(. I am attempting this on a VPS running a clean install of Ubuntu Hardy (8.04) and have followed all instructions on the site to a T. The error message is as follows: $ easy_install egenix-mx-base Searching for egenix-mx-base Reading http://pypi.python.org/simple/egenix-mx-base/ Reading http://www.egenix.com/products/python/mxBase/ Reading http://www.lemburg.com/python/mxExtensions.html Reading http://www.egenix.com/ Best match: egenix-mx-base 3.1.3 Downloading http://downloads.egenix.com/python/egenix-mx-base-3.1.3.tar.gz Processing egenix-mx-base-3.1.3.tar.gz Running egenix-mx-base-3.1.3/setup.py -q bdist_egg --dist-dir /tmp/easy_install-iF7qzl/egenix-mx-base-3.1.3/egg-dist-tmp-laxvcS Warning: Can't read registry to find the necessary compiler setting Make sure that Python modules _winreg, win32api or win32con are installed. In file included from mx/TextTools/mxTextTools/mxte.c:42: mx/TextTools/mxTextTools/mxte_impl.h: In function ‘mxTextTools_TaggingEngine’: mx/TextTools/mxTextTools/mxte_impl.h:345: warning: pointer targets in initialization differ in signedness mx/TextTools/mxTextTools/mxte_impl.h:364: warning: pointer targets in initialization differ in signedness mx/URL/mxURL/mxURL.c: In function ‘mxURL_SetFromString’: mx/URL/mxURL/mxURL.c:676: warning: pointer targets in initialization differ in signedness mx/UID/mxUID/mxUID.c: In function ‘mxUID_Verify’: mx/UID/mxUID/mxUID.c:333: warning: pointer targets in passing argument 1 of ‘sscanf’ differ in signedness mx/UID/mxUID/mxUID.c: In function ‘mxUID_New’: mx/UID/mxUID/mxUID.c:462: warning: pointer targets in passing argument 1 of ‘mxUID_CRC16’ differ in signedness error: Setup script exited with error: build/bdist.linux-x86_64-py2.5_ucs4/dumb/egenix_mx_base-3.1.3-py2.5.egg-info: Is a directory Thank you to anyone who takes the time to try to help me.

    Read the article

  • How to speed up an already cached pip install?

    - by Maxime R.
    I frequently have to re-create virtual environments from a requirements.txt and I am already using $PIP_DOWNLOAD_CACHE. It still takes a lot of time and I noticed the following: Pip spends a lot of time between the following two lines: Downloading/unpacking SomePackage==1.4 (from -r requirements.txt (line 2)) Using download cache from $HOME/.pip_download_cache/cached_package.tar.gz Like ~20 seconds on average to decide it's going to use the cached package, then the install is fast. This is a lot of time when you have to install dozens of packages (actually enough to write this question). What is going on in the background? Are they some sort of integrity checks against the online package? Is there a way to speed this up? edit: Looking at: time pip install -v Django==1.4 I get: real 1m16.120s user 0m4.312s sys 0m1.280s The full output is here http://pastebin.com/e4Q2B5BA. Looks like pip is spending his time looking for a valid download link while it already has a valid cache of http://pypi.python.org/packages/source/D/Django/Django-1.4.tar.gz. Is there a way to look for the cache first and stop there if versions match?

    Read the article

< Previous Page | 1 2 3