python-devel April 2008

python-devel@lists.fedoraproject.org

17 participants
10 discussions

packaged Pylons, ready to use
by Kyle VanderBeek 02 May '08

02 May '08

(Sorry for the repost, didn't want this to get lost in a thread about naming conventions.) For those of you insterested in playing with Pylons, I've hacked out spec files and built RPMs for F8: http://www.kylev.com/pylons-rpm/ I haven't done anything other than make sure that everything installs and paster can do "create" and "serve", so consider this early access. I believe all the other prereqs (like python-simplejson and python-nose) are available via yum. Feedback welcome! If these test out ok for you all, I may submit them for F9. -- kylev(a)kylev.com Some people have a way with words, while others... erm... thingy.

2 2

pychecker stories/feedback?
by James Laska 29 Apr '08

29 Apr '08

Greetings! I've been playing around with a side project of using pychecker to provide early warning of typos/thinkos and questionable practices. I'm basically looking for many of the benefits that a compiler provides when it can't resolve find a variable/class/function name etc... I've got the right mix of pychecker cmdline args such that the subset of issues is now manageable. But I'm curious if folks have any general thoughts on this subject. What are your best practices? Are there other similar tools out there? Have any experiences to share or words of caution/wisdom? Many thanks, James -- ========================================== James Laska -- jlaska(a)redhat.com Quality Engineering -- Red Hat, Inc. ==========================================

3 3

Python package naming guidelines
by Timothy Selivanow 25 Apr '08

25 Apr '08

I feel this is more nit-picking, but I'm currently working on packaging the following items (python/zope names) and need some direction: zc.buildout zope.proxy ZConfig zdaemon zope.testing ZODB3 I haven't exactly liked the current naming conventions, as they leave way too much variation while still being "acceptable". E.g., a package I have already done, pysvn, could have been named "python-pysvn" or "pysvn". If it had been used as "import svn", I would have no problems calling it "python-svn", as that would denote that it is a python package having something to do with SVN (since SVN is already a well-known entity), but upstream calls itself "pysvn" while also using that as the python package name, so calling it "python-pysvn" seemed redundant. However, with the above, there seems to be more ambiguity. Adding to my naming troubles, there is already a package for zope.interface, which is a dependency of ZODB3, and it's name is python-zope-interface. The problem I am having is that it seems to me that if an entity is fairly standalone, i.e. there is no ambiguity whether or not it is a python (or any other language) library/application, that the "python" prefix would be dropped. We don't currently call TurboGears, "python-TurboGears" (yet there are other turbo-related libs that follow the python prefix scheme, e.g. python-turbokid and python-turbocheeta). Really, I'm asking the Python consuming portion of the Fedora Community what they would rather see. I can also take this up on the packaging list, but thought I'd ask here first because potentially it's the people on this list that would be consuming these packages. Would it be: python-zc-buildout python-zope-proxy python-ZConfig python-zdaemon python-zope-testing python-ZODB3 python-zope (thrown in to add contrast, and I'm still working on packaging it...) Or the above without the prefix? It seems to me that there should be a more firm guideline that takes into account python applications, python only frameworks/libs, and python lib ports (these seem to be the bulk of how a name would be determined). --Tim _______________________________________________________________________ / Much of the excitement we get out of our work is that we don't really \ | know what we are doing. | \ -- E. Dijkstra / ----------------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ).

3 5

help with simple script and strings
by John Poelstra 13 Apr '08

13 Apr '08

I'm just getting started with python. Curious what I need to change to properly filter out only strings starting with "200" script: #!/usr/bin/python directories = ['20080412', '20080324', 'blahblah', 'latest-dir', 'rawhide-20080410', 'rawhide-20080411', 'rawhide-20080412' , '20080401'] print 'directories == %s' % directories for directory in directories: print 'processing directory %s ' % directory if not directory.startswith('200'): directories.remove(directory) print 'removed == %s' % directory print 'directories == %s' % directories ~~~~~~~~~~~~~~~~~~~~~~~~~ output: $ python dir-filter.py directories == ['20080412', '20080324', 'blahblah', 'latest-dir', 'rawhide-20080410', 'rawhide-20080411', 'rawhide-20080412', '20080401'] processing directory 20080412 type == <type 'str'> processing directory 20080324 type == <type 'str'> processing directory blahblah type == <type 'str'> removed == blahblah processing directory rawhide-20080410 type == <type 'str'> removed == rawhide-20080410 processing directory rawhide-20080412 type == <type 'str'> removed == rawhide-20080412 directories == ['20080412', '20080324', 'latest-dir', 'rawhide-20080411', '20080401'] ~~~~~~~~~~~~~~~~~~~~ why do 'rawhide-20080411' and 'latest-dir' remain? Thanks, John

6 8

Pakaging enthought tool suite
by Gael Varoquaux 11 Apr '08

11 Apr '08

Hi, I am the guy who asked about packaging mayavi2 a few weeks ago. Unfortunately I didn't realize the discussion was going on on the ML with me following. To pick up on the points that have been raised on the ML: I agree that packaging the whole Enthought Tool Suite would be very nice, and much better than shipping it in a coarse-grained set of packages, as Debian and Ubuntu have been doing. Making 15 or so packages is more work than making 4, but it is more value. I, and probably Dave Perterson and many other on the enthought-dev mailing list (https://mail.enthought.com/mailman/listinfo/enthought-dev ) would be very happy to help you in this endeavour by answering any question you have about the ETS. I do not have any experience with RPM packaging, and do not have access to a fedora box to test, but I can try to help with as much as I can by providing upstream knowledge and fixing small problems upstream, if any. I am now subscribed to this mailing list (god, another mailing list in my already cramed mailbox, how will I ever get some work done!). Keep me posted. I want to stress that if you don't have the time to package all the ETS with all the different packages, a set of 4 packages is what we settled for Debian to distribute the whole suite. Better this than no packages, and the modularity can come later. Keep me posted. Cheers, Gaël

4 10

cython is waiting for review
by Neal Becker 11 Apr '08

11 Apr '08

cython (needed for sage) is waiting for review.

1 0

naming conventions (and an intro)
by Kyle VanderBeek 09 Apr '08

09 Apr '08

I couldn't find a naming convention set in the wiki, so I'll ask here. As I prep the bits and pieces for packaged pylons on Fedora, I'm seeing a lot of varied package names and project names. Projects like Pylons and Mako refer to themselves with caps, but provide PEP-8 friendly lowercase package names, and I'm wondering how we should map these to package names. Personally I'd rather not see a package named "Mako" since it is meaningless outside the context of python and provides nothing in /usr/bin. I'd probably name the package python-mako to make it sort near python-*, which seems to be fairly common in Fedora and RedHat. Does that sound right to you all? By the way, I'm Kyle VanderBeek, professional software developer for IronPort (a Cisco Company). I've been doing software development for more than a decade now, as well as administering a variety of Unix systems including RedHat/RPM Linux distros going back to 4.0 (no, not RHEL 4; actual RedHat Linux 4.0). I currently do the majority of my work in Python, writing massive email anti-spam and reputation systems to protect your mom's Inbox. -- kylev(a)kylev.com Some people have a way with words, while others... erm... thingy.

2 2

[Fedora-python-devel-list] [Fwd: Python SIG mailing list/packaging mayavi2]
by Ignacio Vazquez-Abrams 09 Apr '08

09 Apr '08

Now that most of us are here, let's get started. I received this email from someone wanting to get mayavi2 included in Fedora. It certainly looks like an interesting piece of software. Anyone want to try their hand at it? -------- Forwarded Message -------- From: Gael Varoquaux <gael.varoquaux(a)normalesup.org> To: ivazqueznet+wiki(a)gmail.com Subject: Python SIG mailing list/packaging mayavi2 Date: Thu, 20 Mar 2008 08:01:29 +0100 Hi, I would like to send an e-mail to the Fedora python SIG, but I seem to be too stupid to find the e-mail address, so I am sending it to you. Do you mind forwarding it to the right mailing list, with me in CC. Here is the catch, I would like mayavi2 ( https://svn.enthought.com/enthought/wiki/MayaVi , the web page is horendous) to be included in Fedora. I propose to do it the same way we did it under debian, with three packages, breaking up the fonctionality of the tools suite that we are using for better reuse. In Debian, these are: python-enthought-traits python-enthought-traits-ui mayavi2 I must admit that due to a large modularity of the tools suite (more like 20 packages than 3, and not all used in mayavi2), and heavy use of setuptools packaging this stuff is not trivial. But we finally got it right with the Debian packages, and I am sure we can talk to the maintainers and find out what ended up being the best way to do it. The relevent mailing-list is https://mail.enthought.com/mailman/listinfo/enthought-dev and we will be happy helping you doing these packages. None of the mayavi2 developpers run an rpm-based distribution, so it is a bit hard for us to bootstrap the process. In terms of functionnality for the users, the webpage is terribly poorly written, but you can find some remarks on my blog http://gael-varoquaux.info/blog/ . I have recently had the pleasure to see new users pick up the API and apply it to their domain-specific problem with a lot of ease to build 3D visualization to fit their need with small scripts. I think that for the Python scientific user, this program answers a real need. Cheers, Gaël -- Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>

6 6

New to mailing list
by Brad Malone 02 Apr '08

02 Apr '08

Hi all, I just joined the mailing list. So I guess I'll say a little about myself. I'm a physics graduate student who does a significant amount of scientific programming in python (including numpy/scipy). I've also done some other things in Python as well outside of scientific programming, specifically making a couple of GUIs (tools to make my fiancee's linux experience easier) and internet related tools (simply scripts that monitor the online prices of things I'd like to buy and alert me when the price drops low enough). I still have a lot to learn about Python, but I've been introduced to a number of things that I wouldn't come across usually doing physics. So I'd say I have a decent idea of the scope of what Python can do, although perhaps in some cases not enough experience to do certain things without consulting references. I've been wanting to figure out a way as to how I could help contribute to the Fedora project. I don't know what exactly you do in the Python SIG, but I thought I'd hang around and find out. Best, Brad

1 0

Introduction
by Jason Fenner 01 Apr '08

01 Apr '08

Yet another introduction... I am an experienced SysAdmin and have done quite a bit of scripting in Perl and BASH. However, for about the last year or two my hands down favorite language to continue to learn and use is Python. I am not a Python expert by far but feel quite confident using it to solve problems wherever they might arise. Currently, I am desiring to learn Django and TurboGears so that I can develop some web sites that I've had ideas on. I look forward to what might develop on this list and help out however I can. -- =+=+=+=+=+=+=+=+=+=+=+= Jason aka, Axelilly Catch me on gchat or Jabber =+=+=+=+=+=+=+=+=+=+=+=

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel April 2008