From axelilly at fedoraproject.org Tue Apr 1 13:42:38 2008 From: axelilly at fedoraproject.org (Jason Fenner) Date: Tue, 1 Apr 2008 09:42:38 -0400 Subject: Introduction Message-ID: 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 =+=+=+=+=+=+=+=+=+=+=+= -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.malone at gmail.com Wed Apr 2 16:21:54 2008 From: brad.malone at gmail.com (Brad Malone) Date: Wed, 2 Apr 2008 09:21:54 -0700 Subject: New to mailing list Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kylev at kylev.com Thu Apr 3 23:15:58 2008 From: kylev at kylev.com (Kyle VanderBeek) Date: Thu, 3 Apr 2008 16:15:58 -0700 Subject: naming conventions (and an intro) Message-ID: <20080403231558.GE22494@kylev.com> 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 at kylev.com Some people have a way with words, while others... erm... thingy. From a.badger at gmail.com Fri Apr 4 00:07:14 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 03 Apr 2008 17:07:14 -0700 Subject: naming conventions (and an intro) In-Reply-To: <20080403231558.GE22494@kylev.com> References: <20080403231558.GE22494@kylev.com> Message-ID: <47F57132.80808@gmail.com> Kyle VanderBeek wrote: > 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? > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#AddonPython So if mako is the name of the module you import you'd name it python-mako. > 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. > Cool, it looks like we started using Red Hat at about the same time! -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From trondd at fedoraproject.org Wed Apr 9 05:46:29 2008 From: trondd at fedoraproject.org (Trond Danielsen) Date: Wed, 9 Apr 2008 07:46:29 +0200 Subject: [Fedora-python-devel-list] [Fwd: Python SIG mailing list/packaging mayavi2] In-Reply-To: <604aa7910803281446k37901d49r23131cde69717486@mail.gmail.com> References: <1206739940.24545.32.camel@ignacio.lan> <604aa7910803281446k37901d49r23131cde69717486@mail.gmail.com> Message-ID: <409676c70804082246y30ab4083q769bce6d7d97446e@mail.gmail.com> 2008/3/28 Jeff Spaleta : > > > > As a scientific user....who is writing pythonic codebases for data analysis > and visualization... > > I'd rather see us have a plan to incorporate the all of enthought's software > base in a meaningful way... instead of cherry picking the 3d visualization > stuff specifically. > Enthought's stuff is a framework that should probably go in as a > collection. > > > https://svn.enthought.com/enthought/ > > There's a lot there... and its introduction as a collection of software > needs to be organized. > > > If I were even going to touch it as a user, at a bare minimum I need to know > whether this framework layers over scipy and numpy. Hi everyone, I am willing to help out in an effort to bring the Enthought collection into Fedora. I've used parts of it at work, but never got familiar with the rather complex setup. If anyone has a plan I am willing to put several hours into packaging and testing. Regards, -- Trond Danielsen From kylev at kylev.com Thu Apr 10 01:04:06 2008 From: kylev at kylev.com (Kyle VanderBeek) Date: Wed, 9 Apr 2008 18:04:06 -0700 Subject: naming conventions (and an intro) In-Reply-To: <47F57132.80808@gmail.com> References: <20080403231558.GE22494@kylev.com> <47F57132.80808@gmail.com> Message-ID: <20080410010406.GO22494@kylev.com> 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! -- kylev at kylev.com Some people have a way with words, while others... erm... thingy. From gael.varoquaux at normalesup.org Thu Apr 10 14:53:46 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 10 Apr 2008 16:53:46 +0200 Subject: Pakaging enthought tool suite Message-ID: <20080410145346.GA29029@phare.normalesup.org> 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 From ivazqueznet at gmail.com Thu Apr 10 15:32:07 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 10 Apr 2008 11:32:07 -0400 Subject: Pakaging enthought tool suite In-Reply-To: <20080410145346.GA29029@phare.normalesup.org> References: <20080410145346.GA29029@phare.normalesup.org> Message-ID: <1207841527.23356.1.camel@ignacio.lan> On Thu, 2008-04-10 at 16:53 +0200, Gael Varoquaux wrote: > 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. Is there a dependency tree/graph anywhere we can look at to decide which pieces to tackle first? -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gael.varoquaux at normalesup.org Thu Apr 10 15:52:10 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 10 Apr 2008 17:52:10 +0200 Subject: Pakaging enthought tool suite In-Reply-To: <1207841527.23356.1.camel@ignacio.lan> References: <20080410145346.GA29029@phare.normalesup.org> <1207841527.23356.1.camel@ignacio.lan> Message-ID: <20080410155210.GD29029@phare.normalesup.org> On Thu, Apr 10, 2008 at 11:32:07AM -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2008-04-10 at 16:53 +0200, Gael Varoquaux wrote: > > 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. > Is there a dependency tree/graph anywhere we can look at to decide which > pieces to tackle first? We are using setuptools to declare dependencies. I don't see an obious way of generating a dependency graph from setuptools. We also have all the interproject dependencies listed in https://svn.enthought.com/enthought/browser/project_map.ini, using a home-made dependency-inspection tool. I am having a look at seeing how this tool can be used to generate such graph. I will post the result on the list (don't hold your breath, I am also working on some day work). Cheers, Ga?l From ivazqueznet at gmail.com Thu Apr 10 16:11:14 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 10 Apr 2008 12:11:14 -0400 Subject: Pakaging enthought tool suite In-Reply-To: <20080410155210.GD29029@phare.normalesup.org> References: <20080410145346.GA29029@phare.normalesup.org> <1207841527.23356.1.camel@ignacio.lan> <20080410155210.GD29029@phare.normalesup.org> Message-ID: <1207843874.23356.2.camel@ignacio.lan> On Thu, 2008-04-10 at 17:52 +0200, Gael Varoquaux wrote: > On Thu, Apr 10, 2008 at 11:32:07AM -0400, Ignacio Vazquez-Abrams wrote: > > On Thu, 2008-04-10 at 16:53 +0200, Gael Varoquaux wrote: > > > 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. > > > Is there a dependency tree/graph anywhere we can look at to decide which > > pieces to tackle first? > > We are using setuptools to declare dependencies. I don't see an obious > way of generating a dependency graph from setuptools. We also have all > the interproject dependencies listed in > https://svn.enthought.com/enthought/browser/project_map.ini, using a > home-made dependency-inspection tool. > > I am having a look at seeing how this tool can be used to generate such > graph. I will post the result on the list (don't hold your breath, I am > also working on some day work). Well, we don't need a graph per se; I think that file should be enough, thanks. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gael.varoquaux at normalesup.org Thu Apr 10 16:14:03 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 10 Apr 2008 18:14:03 +0200 Subject: Pakaging enthought tool suite In-Reply-To: <1207843874.23356.2.camel@ignacio.lan> References: <20080410145346.GA29029@phare.normalesup.org> <1207841527.23356.1.camel@ignacio.lan> <20080410155210.GD29029@phare.normalesup.org> <1207843874.23356.2.camel@ignacio.lan> Message-ID: <20080410161403.GF29029@phare.normalesup.org> On Thu, Apr 10, 2008 at 12:11:14PM -0400, Ignacio Vazquez-Abrams wrote: > Well, we don't need a graph per se; I think that file should be enough, > thanks. As you wish. I think I will have a go at the graph thing (I have already started) because it is useful anyhow. For packaging, you are only interested in the closure of ets_2.7.1, which is the latest released version. This reduces the graph a lot :->. Cheers, Ga?l From kylev at kylev.com Thu Apr 10 17:49:17 2008 From: kylev at kylev.com (Kyle VanderBeek) Date: Thu, 10 Apr 2008 10:49:17 -0700 Subject: packaged Pylons, ready to use Message-ID: <20080410174917.GQ22494@kylev.com> (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 at kylev.com Some people have a way with words, while others... erm... thingy. From trondd at fedoraproject.org Thu Apr 10 19:23:19 2008 From: trondd at fedoraproject.org (Trond Danielsen) Date: Thu, 10 Apr 2008 21:23:19 +0200 Subject: Pakaging enthought tool suite In-Reply-To: <20080410161403.GF29029@phare.normalesup.org> References: <20080410145346.GA29029@phare.normalesup.org> <1207841527.23356.1.camel@ignacio.lan> <20080410155210.GD29029@phare.normalesup.org> <1207843874.23356.2.camel@ignacio.lan> <20080410161403.GF29029@phare.normalesup.org> Message-ID: <409676c70804101223l7812c409s81510111f2c8a591@mail.gmail.com> 2008/4/10 Gael Varoquaux : > For packaging, you are only interested in the closure of ets_2.7.1, which > is the latest released version. Just one quick question: Are there tarballs available for the various enthought components, or do we have to pull every single one from svn? I looked at the enthought wiki, but I could not find anything there. Regards, -- Trond Danielsen From gael.varoquaux at normalesup.org Thu Apr 10 19:30:48 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 10 Apr 2008 21:30:48 +0200 Subject: Pakaging enthought tool suite In-Reply-To: <409676c70804101223l7812c409s81510111f2c8a591@mail.gmail.com> References: <20080410145346.GA29029@phare.normalesup.org> <1207841527.23356.1.camel@ignacio.lan> <20080410155210.GD29029@phare.normalesup.org> <1207843874.23356.2.camel@ignacio.lan> <20080410161403.GF29029@phare.normalesup.org> <409676c70804101223l7812c409s81510111f2c8a591@mail.gmail.com> Message-ID: <20080410193048.GA2873@phare.normalesup.org> On Thu, Apr 10, 2008 at 09:23:19PM +0200, Trond Danielsen wrote: > 2008/4/10 Gael Varoquaux : > > For packaging, you are only interested in the closure of ets_2.7.1, which > > is the latest released version. > Just one quick question: Are there tarballs available for the various > enthought components, or do we have to pull every single one from svn? > I looked at the enthought wiki, but I could not find anything there. Our wiki is horrible. We are in the process of reworking it, but nobody agrees on how it should be done. The tarballs of each released packages are located on http://code.enthought.com/enstaller/eggs/source/ You do need a dependency graph to be able to make some sense of this. I am making good progress on making a nice one. Cheers, Ga?l From jspaleta at gmail.com Thu Apr 10 21:43:34 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 10 Apr 2008 13:43:34 -0800 Subject: Pakaging enthought tool suite In-Reply-To: <20080410193048.GA2873@phare.normalesup.org> References: <20080410145346.GA29029@phare.normalesup.org> <1207841527.23356.1.camel@ignacio.lan> <20080410155210.GD29029@phare.normalesup.org> <1207843874.23356.2.camel@ignacio.lan> <20080410161403.GF29029@phare.normalesup.org> <409676c70804101223l7812c409s81510111f2c8a591@mail.gmail.com> <20080410193048.GA2873@phare.normalesup.org> Message-ID: <604aa7910804101443k97a458bqd1063ce26cd62dd2@mail.gmail.com> On Thu, Apr 10, 2008 at 11:30 AM, Gael Varoquaux wrote: > Our wiki is horrible. We are in the process of reworking it, but nobody > agrees on how it should be done. This is easy to fix. Have everyone agree on the one person who has the authority to decide what to implement..and then everyone sucks it up and lives with that person's decision. > > The tarballs of each released packages are located on > > http://code.enthought.com/enstaller/eggs/source/ > > You do need a dependency graph to be able to make some sense of this. I > am making good progress on making a nice one. Just for clarification... the eggs are completely source...and don't contain binary blobs of any sort? -jef From gael.varoquaux at normalesup.org Thu Apr 10 21:49:18 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 10 Apr 2008 23:49:18 +0200 Subject: Pakaging enthought tool suite In-Reply-To: <604aa7910804101443k97a458bqd1063ce26cd62dd2@mail.gmail.com> References: <20080410145346.GA29029@phare.normalesup.org> <1207841527.23356.1.camel@ignacio.lan> <20080410155210.GD29029@phare.normalesup.org> <1207843874.23356.2.camel@ignacio.lan> <20080410161403.GF29029@phare.normalesup.org> <409676c70804101223l7812c409s81510111f2c8a591@mail.gmail.com> <20080410193048.GA2873@phare.normalesup.org> <604aa7910804101443k97a458bqd1063ce26cd62dd2@mail.gmail.com> Message-ID: <20080410214918.GF30722@phare.normalesup.org> On Thu, Apr 10, 2008 at 01:43:34PM -0800, Jeff Spaleta wrote: > > The tarballs of each released packages are located on > > http://code.enthought.com/enstaller/eggs/source/ > > You do need a dependency graph to be able to make some sense of this. I > > am making good progress on making a nice one. > Just for clarification... the eggs are completely source...and don't > contain binary blobs of any sort? Yes. I am not an Enthought employee. I have no financial interest or other interest than promoting high-quality open-source scientific packages. I am very much attached to the open source values. I have made sure, together with the Debian packagers, that the ETS was Debian Free Software Guidelines compatible (even if I don't agree with all what's in there). All the code is licensed under BDS 3 clause (no advertizing clause). The license of some of the icons vary, and is mentionned in the "icon_license.txt" file for each project. However everything is licensed under non-copyleft licenses (LGPL, Eclipse, ...). I hope this clarifies things. If there are any more questions, please do not hesitate. Cheers, Ga?l From gael.varoquaux at normalesup.org Thu Apr 10 22:24:25 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Fri, 11 Apr 2008 00:24:25 +0200 Subject: Pakaging enthought tool suite In-Reply-To: <20080410161403.GF29029@phare.normalesup.org> References: <20080410145346.GA29029@phare.normalesup.org> <1207841527.23356.1.camel@ignacio.lan> <20080410155210.GD29029@phare.normalesup.org> <1207843874.23356.2.camel@ignacio.lan> <20080410161403.GF29029@phare.normalesup.org> Message-ID: <20080410222425.GI30722@phare.normalesup.org> On Thu, Apr 10, 2008 at 06:14:03PM +0200, Gael Varoquaux wrote: > On Thu, Apr 10, 2008 at 12:11:14PM -0400, Ignacio Vazquez-Abrams wrote: > > Well, we don't need a graph per se; I think that file should be enough, > > thanks. > As you wish. I think I will have a go at the graph thing (I have already > started) because it is useful anyhow. For people in a hurry, I just put a first graph on the net, on http://gael-varoquaux.info/ets_deps.png It will not stay there, I am just working in making the code that generates this a bit more reliable, and will publish this on the Enthought wiki. The graph is quite horrendous. I had never seen it before, but from inside it did look bad. Now the good news is that for version 3 of the ETS, the graph looks like: http://gael-varoquaux.info/ets3_deps.png Way better. I hope this helps a bit having a better understanding of the packaging. Maybe an interesting way of doing a coarse-grained approach, is to group packages as they are reorganized in ETS3. You can have a look at the organisation on the svn repo: https://svn.enthought.com/enthought/browser Look in the "trunk" folder of each project. Cheers, Ga?l From ndbecker2 at gmail.com Fri Apr 11 14:11:28 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 11 Apr 2008 10:11:28 -0400 Subject: cython is waiting for review Message-ID: <200804111011.28919.ndbecker2@gmail.com> cython (needed for sage) is waiting for review. From gael.varoquaux at normalesup.org Fri Apr 11 18:31:13 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Fri, 11 Apr 2008 20:31:13 +0200 Subject: Pakaging enthought tool suite In-Reply-To: <1207841527.23356.1.camel@ignacio.lan> References: <20080410145346.GA29029@phare.normalesup.org> <1207841527.23356.1.camel@ignacio.lan> Message-ID: <20080411183113.GA3673@phare.normalesup.org> On Thu, Apr 10, 2008 at 11:32:07AM -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2008-04-10 at 16:53 +0200, Gael Varoquaux wrote: > > 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. > Is there a dependency tree/graph anywhere we can look at to decide which > pieces to tackle first? By the way, what can we do, what tools and information can we provide to make your work easier? Specificaly, what is your workflow to package a suite of tools with cross dependencies like the ETS, relying heavily on setuptools? We are having a internal discussion on how to make it as easy as possible to package ETS and maintain for downstream, and as none of us has much packaging experience it would be great to have as much feedback as possible. From poelstra at redhat.com Sat Apr 12 20:35:33 2008 From: poelstra at redhat.com (John Poelstra) Date: Sat, 12 Apr 2008 13:35:33 -0700 Subject: help with simple script and strings Message-ID: <48011D15.8040700@redhat.com> 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 == processing directory 20080324 type == processing directory blahblah type == removed == blahblah processing directory rawhide-20080410 type == removed == rawhide-20080410 processing directory rawhide-20080412 type == removed == rawhide-20080412 directories == ['20080412', '20080324', 'latest-dir', 'rawhide-20080411', '20080401'] ~~~~~~~~~~~~~~~~~~~~ why do 'rawhide-20080411' and 'latest-dir' remain? Thanks, John From kylev at kylev.com Sat Apr 12 20:47:25 2008 From: kylev at kylev.com (Kyle VanderBeek) Date: Sat, 12 Apr 2008 13:47:25 -0700 Subject: help with simple script and strings In-Reply-To: <48011D15.8040700@redhat.com> References: <48011D15.8040700@redhat.com> Message-ID: <20080412204725.GT22494@kylev.com> On Sat, Apr 12, 2008 at 01:35:33PM -0700, John Poelstra wrote: > 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 Modifying the contents of a list that you're iterating over with a generator will give you strange results. Basically, you're causing the generator to lose its place. If you put the result in a new list (say, directories_new), this won't happen. Granted, I'd probably do it this way, just going once over the list with a list iteration: >>> [d for d in directories if d.startswith('200')] ['20080412', '20080324', '20080401'] Since it builds a new list, you can even assign it back to the directories variable: >>> directories = [d for d in directories if d.startswith('200')] >>> directories ['20080412', '20080324', '20080401'] I'm not a huge fan of list comprehensions due to the somewhat baroque syntax, but this seems like a perfect single-pass O(n) application of the construct that is still easy to read. -- kylev at kylev.com Some people have a way with words, while others... erm... thingy. From skvidal at fedoraproject.org Sat Apr 12 20:47:59 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 12 Apr 2008 16:47:59 -0400 Subject: help with simple script and strings In-Reply-To: <48011D15.8040700@redhat.com> References: <48011D15.8040700@redhat.com> Message-ID: <1208033279.5736.2.camel@cutter> On Sat, 2008-04-12 at 13:35 -0700, John Poelstra wrote: > 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 == > processing directory 20080324 > type == > processing directory blahblah > type == > removed == blahblah > processing directory rawhide-20080410 > type == > removed == rawhide-20080410 > processing directory rawhide-20080412 > type == > removed == rawhide-20080412 > directories == ['20080412', '20080324', 'latest-dir', > 'rawhide-20080411', '20080401'] > > ~~~~~~~~~~~~~~~~~~~~ > > why do 'rawhide-20080411' and 'latest-dir' remain? removing items from a list you're working on means the index change in place so you'll end up skipping some items b/c the loop moves over them. -sv From james at fedoraproject.com Sat Apr 12 20:52:06 2008 From: james at fedoraproject.com (James Antill) Date: Sat, 12 Apr 2008 16:52:06 -0400 Subject: help with simple script and strings In-Reply-To: <48011D15.8040700@redhat.com> References: <48011D15.8040700@redhat.com> Message-ID: <1208033526.3606.74.camel@code.and.org> On Sat, 2008-04-12 at 13:35 -0700, John Poelstra wrote: > 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 You can't alter things that you are iterating, the easist fix is: for directory in directories[:]: ...the others being to create a new list of just what you want, or a list of what needs to go and then do the .remove() calls on that (these methods can be worth it, for large lists). -- James Antill Fedora From kylev at kylev.com Sat Apr 12 20:56:12 2008 From: kylev at kylev.com (Kyle VanderBeek) Date: Sat, 12 Apr 2008 13:56:12 -0700 Subject: help with simple script and strings In-Reply-To: <20080412204725.GT22494@kylev.com> References: <48011D15.8040700@redhat.com> <20080412204725.GT22494@kylev.com> Message-ID: <20080412205612.GU22494@kylev.com> On Sat, Apr 12, 2008 at 01:47:25PM -0700, Kyle VanderBeek wrote: > Modifying the contents of a list that you're iterating over with a > generator will give you strange results. Basically, you're causing the > generator to lose its place. If you put the result in a new list (say, > directories_new), this won't happen. I mis-spoke on a minor detail: the list object doesn't use a generator, it's just an interable in the usual sense. Sorry to confuse. My technique still holds. Modifying something you're iterating over will give you unexpected results. -- kylev at kylev.com Some people have a way with words, while others... erm... thingy. From kylev at kylev.com Sat Apr 12 21:07:54 2008 From: kylev at kylev.com (Kyle VanderBeek) Date: Sat, 12 Apr 2008 14:07:54 -0700 Subject: help with simple script and strings In-Reply-To: <1208033526.3606.74.camel@code.and.org> References: <48011D15.8040700@redhat.com> <1208033526.3606.74.camel@code.and.org> Message-ID: <20080412210754.GV22494@kylev.com> On Sat, Apr 12, 2008 at 04:52:06PM -0400, James Antill wrote: > You can't alter things that you are iterating, the easist fix is: > > for directory in directories[:]: > > ...the others being to create a new list of just what you want, or a > list of what needs to go and then do the .remove() calls on that (these > methods can be worth it, for large lists). Actually, I'd contend this technique gets worse as your list size increases. First, you're making a copy pass, doubling your memory footprint, and then a second pass to actually filter the list down to just the elements you want. That will get slower as your list size increases. Oh, and that reminds me of another way, using the builtin filter(): >>> directories = ['20080412', '20080324', 'blahblah', 'latest-dir', 'rawhide-20080410', 'rawhide-20080411', 'rawhide-20080412' , '20080401'] >>> filter(lambda x: x.startswith('200'), directories) ['20080412', '20080324', '20080401'] -- kylev at kylev.com Some people have a way with words, while others... erm... thingy. From a.badger at gmail.com Sun Apr 13 00:10:02 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 12 Apr 2008 17:10:02 -0700 Subject: help with simple script and strings In-Reply-To: <20080412210754.GV22494@kylev.com> References: <48011D15.8040700@redhat.com> <1208033526.3606.74.camel@code.and.org> <20080412210754.GV22494@kylev.com> Message-ID: <48014F5A.2050901@gmail.com> Kyle VanderBeek wrote: > On Sat, Apr 12, 2008 at 04:52:06PM -0400, James Antill wrote: >> You can't alter things that you are iterating, the easist fix is: >> >> for directory in directories[:]: >> >> ...the others being to create a new list of just what you want, or a >> list of what needs to go and then do the .remove() calls on that (these >> methods can be worth it, for large lists). > > Actually, I'd contend this technique gets worse as your list size > increases. First, you're making a copy pass, doubling your memory > footprint, and then a second pass to actually filter the list down to > just the elements you want. That will get slower as your list size > increases. > > Oh, and that reminds me of another way, using the builtin filter(): > > >>> directories = ['20080412', '20080324', 'blahblah', 'latest-dir', > 'rawhide-20080410', 'rawhide-20080411', 'rawhide-20080412' , '20080401'] > >>> filter(lambda x: x.startswith('200'), directories) > ['20080412', '20080324', '20080401'] > Just a note: This will be much slower than the list comprehension for large lists. That's because function calls have tremendous overhead in python and a lambda is just a function without a name. So using filter you make two function calls for every entry in the list: * lambda [...] * str.startswith() With a list comprehension you only call str.startswith(). As I tell people, if you want readability, write it out fully (James Antill's solution or even: newDirectories = [] for directory in directories: if directory.startswith('200'): newDirectories.append(directory) directories = newDirectories If you want speed and code compactness use a list comprehension. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From skvidal at fedoraproject.org Sun Apr 13 21:05:34 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Sun, 13 Apr 2008 17:05:34 -0400 Subject: help with simple script and strings In-Reply-To: <48014F5A.2050901@gmail.com> References: <48011D15.8040700@redhat.com> <1208033526.3606.74.camel@code.and.org> <20080412210754.GV22494@kylev.com> <48014F5A.2050901@gmail.com> Message-ID: <1208120734.5736.4.camel@cutter> On Sat, 2008-04-12 at 17:10 -0700, Toshio Kuratomi wrote: > Kyle VanderBeek wrote: > > On Sat, Apr 12, 2008 at 04:52:06PM -0400, James Antill wrote: > >> You can't alter things that you are iterating, the easist fix is: > >> > >> for directory in directories[:]: > >> > >> ...the others being to create a new list of just what you want, or a > >> list of what needs to go and then do the .remove() calls on that (these > >> methods can be worth it, for large lists). > > > > Actually, I'd contend this technique gets worse as your list size > > increases. First, you're making a copy pass, doubling your memory > > footprint, and then a second pass to actually filter the list down to > > just the elements you want. That will get slower as your list size > > increases. > > > > Oh, and that reminds me of another way, using the builtin filter(): > > > > >>> directories = ['20080412', '20080324', 'blahblah', 'latest-dir', > > 'rawhide-20080410', 'rawhide-20080411', 'rawhide-20080412' , '20080401'] > > >>> filter(lambda x: x.startswith('200'), directories) > > ['20080412', '20080324', '20080401'] > > > > Just a note: This will be much slower than the list comprehension for > large lists. > > That's because function calls have tremendous overhead in python and a > lambda is just a function without a name. So using filter you make two > function calls for every entry in the list: > * lambda [...] > * str.startswith() > > With a list comprehension you only call str.startswith(). > > As I tell people, if you want readability, write it out fully (James > Antill's solution or even: > > newDirectories = [] > for directory in directories: > if directory.startswith('200'): > newDirectories.append(directory) > directories = newDirectories > > If you want speed and code compactness use a list comprehension. > And just as another note - you better be doing this several hundred thousand times to justify the complete unreadability of list comprehensions. -sv From python at venix.com Mon Apr 14 00:11:47 2008 From: python at venix.com (Lloyd Kvam) Date: Sun, 13 Apr 2008 20:11:47 -0400 Subject: help with simple script and strings In-Reply-To: <1208120734.5736.4.camel@cutter> References: <48011D15.8040700@redhat.com> <1208033526.3606.74.camel@code.and.org> <20080412210754.GV22494@kylev.com> <48014F5A.2050901@gmail.com> <1208120734.5736.4.camel@cutter> Message-ID: <1208131907.3474.308.camel@localhost.localdomain> On Sun, 2008-04-13 at 17:05 -0400, seth vidal wrote: > > newDirectories = [] > > for directory in directories: > > if directory.startswith('200'): > > newDirectories.append(directory) > > directories = newDirectories > > > > If you want speed and code compactness use a list comprehension. > > > > And just as another note - you better be doing this several hundred > thousand times to justify the complete unreadability of list > comprehensions. directories = [directory for directory in directories if directory.startswith('200') ] The change in line ordering is unsettling at first. But I think the intent is very clear with a list comprehension. Certainly the phrasing is quite similar. -- Lloyd Kvam Venix Corp DLSLUG/GNHLUG library http://www.librarything.com/catalog/dlslug http://www.librarything.com/profile/dlslug http://www.librarything.com/rsshtml/recent/dlslug From timothy.selivanow at virtualxistenz.com Thu Apr 24 22:37:41 2008 From: timothy.selivanow at virtualxistenz.com (Timothy Selivanow) Date: Thu, 24 Apr 2008 15:37:41 -0700 Subject: Python package naming guidelines Message-ID: <1209076661.8910.42.camel@denkiteki-penpen.easystreet.com> 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 ). From a.badger at gmail.com Thu Apr 24 23:21:15 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 24 Apr 2008 16:21:15 -0700 Subject: Python package naming guidelines In-Reply-To: <1209076661.8910.42.camel@denkiteki-penpen.easystreet.com> References: <1209076661.8910.42.camel@denkiteki-penpen.easystreet.com> Message-ID: <481115EB.9050406@gmail.com> Timothy Selivanow wrote: > 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). > TurboGears was built before the Guideline. (Django, OTOH, was built in violation of the guidelines and I didn't get to the review bug in time to get it changed) > 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). > An application doesn't need to be prefixed with python-. The question is, of course, if something like gourmet which has a module... but that module really just exists to be imported by the program should be gourmet or python-gourmet. I wouldn't stop someone from going either way with this. Other than that, bit... python libs and python lib ports should both be prefixed with python-. A python framework should be prefixed with python- as well but the definition of framework is a bit ambiguous: zope can run standalone and therefore could be considered an application while TurboGears cannot run until someone creates an application that imports it, therefore it should definitely have been named python-turbogears. So in your list, you need to decide if it's an application, an application which happens to have a module to support its functionality, or if it's a module that people are expected to use in their programs. If the latter, you are most likely going to want a python- prefix.... although you might want to have a subpackage for the application in corner cases where it's equally likely that someone would import a certain module and that someone else would run the program. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jlaska at redhat.com Fri Apr 25 13:10:18 2008 From: jlaska at redhat.com (James Laska) Date: Fri, 25 Apr 2008 13:10:18 +0000 Subject: pychecker stories/feedback? Message-ID: <1209129018.22312.183.camel@flatline> 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 at redhat.com Quality Engineering -- Red Hat, Inc. ========================================== From a.badger at gmail.com Fri Apr 25 15:32:27 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 25 Apr 2008 08:32:27 -0700 Subject: pychecker stories/feedback? In-Reply-To: <1209129018.22312.183.camel@flatline> References: <1209129018.22312.183.camel@flatline> Message-ID: <4811F98B.6080007@gmail.com> James Laska wrote: > 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? > pylint is the tool I use. pyflakes does the same sort of thing as well. I think pylint checks for the most things... which can be good or bad (you can disable groups of checks so it's not too bad.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From timothy.selivanow at virtualxistenz.com Fri Apr 25 16:02:38 2008 From: timothy.selivanow at virtualxistenz.com (Timothy Selivanow) Date: Fri, 25 Apr 2008 09:02:38 -0700 Subject: Python package naming guidelines In-Reply-To: <481115EB.9050406@gmail.com> References: <1209076661.8910.42.camel@denkiteki-penpen.easystreet.com> <481115EB.9050406@gmail.com> Message-ID: <1209139358.29909.12.camel@denkiteki-penpen.easystreet.com> On Thu, 2008-04-24 at 16:21 -0700, Toshio Kuratomi wrote: > Other than that, bit... python libs and python lib ports should both be > prefixed with python-. A python framework should be prefixed with > python- as well but the definition of framework is a bit ambiguous: zope > can run standalone and therefore could be considered an application > while TurboGears cannot run until someone creates an application that > imports it, therefore it should definitely have been named > python-turbogears. So, under that logic, I should have named pysvn python-pysvn? That seems a bit redundant to me, but I'm willing to play along if that is the consensus. From now on, I'll make an effort to name things that way, unless I hear a better reason not to (name space pollution, lib-{package} naming in other distros, other historical reason that I'm not aware of or privy to...). If this is The Way, it should be updated on the wiki so other (future) maintainers can avoid the ambiguity. Yes, I've volunteered to make the change (or propose it to Packaging Committee) as long as there is sufficient consensus, or however the Python SIG is making decisions. That is unless someone with more tenure would be more applicable in this case. --Tim _____________________________________________________________________________ < "But what we need to know is, do people want nasally-insertable computers?" > ----------------------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ). From a.badger at gmail.com Fri Apr 25 16:19:08 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 25 Apr 2008 09:19:08 -0700 Subject: Python package naming guidelines In-Reply-To: <1209139358.29909.12.camel@denkiteki-penpen.easystreet.com> References: <1209076661.8910.42.camel@denkiteki-penpen.easystreet.com> <481115EB.9050406@gmail.com> <1209139358.29909.12.camel@denkiteki-penpen.easystreet.com> Message-ID: <4812047C.2080503@gmail.com> Timothy Selivanow wrote: > On Thu, 2008-04-24 at 16:21 -0700, Toshio Kuratomi wrote: > >> Other than that, bit... python libs and python lib ports should both be >> prefixed with python-. A python framework should be prefixed with >> python- as well but the definition of framework is a bit ambiguous: zope >> can run standalone and therefore could be considered an application >> while TurboGears cannot run until someone creates an application that >> imports it, therefore it should definitely have been named >> python-turbogears. > > So, under that logic, I should have named pysvn python-pysvn? That > seems a bit redundant to me, but I'm willing to play along if that is > the consensus. Yeah... but there is a specific exception in the guidelines for packages which start with 'py'. scop talked about having that exception removed (old packages grandfathered) but it never reached the proposal stage. > If this is The Way, it should be updated on the wiki so other (future) > maintainers can avoid the ambiguity. Yes, I've volunteered to make the > change (or propose it to Packaging Committee) as long as there is > sufficient consensus, or however the Python SIG is making decisions. > That is unless someone with more tenure would be more applicable in this > case. > If the wiki isn't clear, definitely draft better wording and propose it to the Packaging Committee. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From kylev at kylev.com Fri Apr 25 17:25:44 2008 From: kylev at kylev.com (Kyle VanderBeek) Date: Fri, 25 Apr 2008 10:25:44 -0700 Subject: Python package naming guidelines In-Reply-To: <1209139358.29909.12.camel@denkiteki-penpen.easystreet.com> References: <1209076661.8910.42.camel@denkiteki-penpen.easystreet.com> <481115EB.9050406@gmail.com> <1209139358.29909.12.camel@denkiteki-penpen.easystreet.com> Message-ID: <20080425172543.GJ22494@kylev.com> On Fri, Apr 25, 2008 at 09:02:38AM -0700, Timothy Selivanow wrote: > So, under that logic, I should have named pysvn python-pysvn? That > seems a bit redundant to me, but I'm willing to play along if that is > the consensus. From now on, I'll make an effort to name things that > way, unless I hear a better reason not to (name space pollution, > lib-{package} naming in other distros, other historical reason that I'm > not aware of or privy to...). I agree that python-pysvn seems redundant, but that is the fault of the project creators, and is probably not up to packagers to correct. Naming a python package with "py" in the name is redundant itself. But, since you're going to have to "import pysvn", you might was well be installing python-pysvn. -- kylev at kylev.com Some people have a way with words, while others... erm... thingy. From timothy.selivanow at virtualxistenz.com Fri Apr 25 17:54:11 2008 From: timothy.selivanow at virtualxistenz.com (Timothy Selivanow) Date: Fri, 25 Apr 2008 10:54:11 -0700 Subject: Python package naming guidelines In-Reply-To: <20080425172543.GJ22494@kylev.com> References: <1209076661.8910.42.camel@denkiteki-penpen.easystreet.com> <481115EB.9050406@gmail.com> <1209139358.29909.12.camel@denkiteki-penpen.easystreet.com> <20080425172543.GJ22494@kylev.com> Message-ID: <1209146051.29909.52.camel@denkiteki-penpen.easystreet.com> On Fri, 2008-04-25 at 10:25 -0700, Kyle VanderBeek wrote: > On Fri, Apr 25, 2008 at 09:02:38AM -0700, Timothy Selivanow wrote: > > So, under that logic, I should have named pysvn python-pysvn? That > > seems a bit redundant to me, but I'm willing to play along if that is > > the consensus. From now on, I'll make an effort to name things that > > way, unless I hear a better reason not to (name space pollution, > > lib-{package} naming in other distros, other historical reason that I'm > > not aware of or privy to...). > > I agree that python-pysvn seems redundant, but that is the fault of the > project creators, and is probably not up to packagers to correct. > Naming a python package with "py" in the name is redundant itself. But, > since you're going to have to "import pysvn", you might was well be > installing python-pysvn. Since I didn't make the deadline to have it included in F9, how difficult/frowned upon is it to change the package name. However, it is in F8 now... --Tim _____________________________________________________________________________ < "See - the thing is - I'm an absolutist. I mean, kind of ... in a way ..." > ----------------------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ). From dkovalsk at redhat.com Tue Apr 29 11:04:56 2008 From: dkovalsk at redhat.com (David Kovalsky) Date: Tue, 29 Apr 2008 13:04:56 +0200 Subject: pychecker stories/feedback? In-Reply-To: <1209129018.22312.183.camel@flatline> References: <1209129018.22312.183.camel@flatline> Message-ID: <20080429130456.47af75c8@kovinek> On Fri, 25 Apr 2008 13:10:18 +0000 James Laska wrote: > 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? Hey James, I've been using pylint for a while and I must say it's pretty useful. It takes a while though to tune some of the tests - like * every variable has to be at least 3 chars (except for i when iterating), so often used 'id' won't pass as well as common for l in lines, for k,v in dict.iteritems() and such * pylint complains about nonexisting properties if you override the __getattr__ method. * in default * and ** magic is now allowed (from foo import *, def bar(*args, **kwargs), which is sometimes very useful But it has pretty good documentation, commented config file and you can tune the checks using comments in the .py files themselves to disable a check for a file or even a block of code as simply as for example '# pylint: disable-msg=C0103' to disable warning about module variable in lowercase. As I mentioned, you really have to take the time to configure it to your standart. As some people prefer to use CamelCase, some use_underline. After that is helps you keep the same standart throughout the whole project. And writing your own tests (plugins) is easy and fun :) HTH, /David -- =================================================================== David Kovalsky dkovalsk at redhat.com Quality Engineer & EUS (z-stream) QE point person Red Hat Czech s.r.o. Brno, Czech Republic tel: +420 532 294 223 mobile: +420 777 707 369 IRC: #0day, #brno, #errata, #qa, #rhlp, #tps, #urt =================================================================== From a.badger at gmail.com Tue Apr 29 15:48:45 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 29 Apr 2008 08:48:45 -0700 Subject: pychecker stories/feedback? In-Reply-To: <20080429130456.47af75c8@kovinek> References: <1209129018.22312.183.camel@flatline> <20080429130456.47af75c8@kovinek> Message-ID: <4817435D.3080703@gmail.com> David Kovalsky wrote: > On Fri, 25 Apr 2008 13:10:18 +0000 > > I've been using pylint for a while and I must say it's pretty useful. > It takes a while though to tune some of the tests - like > * every variable has to be at least 3 chars (except for i when > iterating), so often used 'id' won't pass as well as common for l in > lines, for k,v in dict.iteritems() and such > id is also a builtin:: id(...) id(object) -> integer Return the identity of an object. This is guaranteed to be unique among simultaneously existing objects. (Hint: it's the object's memory address.) > * pylint complains about nonexisting properties if you override the > __getattr__ method. > > * in default * and ** magic is now allowed (from foo import *, def > bar(*args, **kwargs), which is sometimes very useful > > But it has pretty good documentation, commented config file and you can > tune the checks using comments in the .py files themselves > to disable a check for a file or even a block of code as simply as for > example '# pylint: disable-msg=C0103' to disable warning about module > variable in lowercase. > It is also supposed to be able to turn tests on and off at the same level but that is broken in the current release. (Upstream says they have a fix in for the next release). > As I mentioned, you really have to take the time to configure it to > your standart. As some people prefer to use CamelCase, some > use_underline. After that is helps you keep the same standart > throughout the whole project. And writing your own tests (plugins) is > easy and fun :) > pylint --generate-rcfile is a useful option to start your customization with. -Toshio From lmacken at redhat.com Wed Apr 30 15:54:39 2008 From: lmacken at redhat.com (Luke Macken) Date: Wed, 30 Apr 2008 11:54:39 -0400 Subject: packaged Pylons, ready to use In-Reply-To: <20080410174917.GQ22494@kylev.com> References: <20080410174917.GQ22494@kylev.com> Message-ID: <20080430155439.GA3462@x300> On Thu, Apr 10, 2008 at 10:49:17AM -0700, Kyle VanderBeek wrote: > (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. Thanks for packaging these, Kyle. It would be great to get these into Fedora, seeing as how TurboGears2 (the web framework that we use for most of our infrastructure) is based on Pylons. If you get a chance, please submit them for review: http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess luke