Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #4044 > unrolled thread

Development tools and practices for Pythonistas

Back to article view | Back to comp.lang.python

Contents

  Development tools and practices for Pythonistas snorble <snorble@hotmail.com> - 2011-04-26 07:39 -0700
    Re: Development tools and practices for Pythonistas rusi <rustompmody@gmail.com> - 2011-04-26 09:00 -0700
    Re: Development tools and practices for Pythonistas "Martin P. Hellwig" <martin.hellwig@gmail.com> - 2011-04-26 17:02 +0000
    Re: Development tools and practices for Pythonistas Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-04-26 19:59 +0200
      Re: Development tools and practices for Pythonistas Algis Kabaila <akabaila@pcug.org.au> - 2011-04-27 04:42 +1000
        Re: Development tools and practices for Pythonistas Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-04-27 00:32 +0200
      Re: [OT] Comparing VCS tools (was ""Development tools and practices for Pythonistas") Tim Chase <python.list@tim.thechases.com> - 2011-04-26 20:44 -0500
        Re: [OT] Comparing VCS tools Ben Finney <ben+python@benfinney.id.au> - 2011-04-27 12:45 +1000
          Re: [OT] Comparing VCS tools Ben Finney <ben+python@benfinney.id.au> - 2011-04-27 16:51 +1000
          Re: [OT] Comparing VCS tools Tim Chase <python.list@tim.thechases.com> - 2011-04-27 14:13 -0500
        Re: Comparing VCS tools (was ""Development tools and practices for Pythonistas") rusi <rustompmody@gmail.com> - 2011-04-26 19:50 -0700
          Re: Comparing VCS tools (was ""Development tools and practices for Pythonistas") alex23 <wuwei23@gmail.com> - 2011-04-26 22:37 -0700
        Re: [OT] Comparing VCS tools (was ""Development tools and practices  for Pythonistas") Kevin Walzer <kw@codebykevin.com> - 2011-04-29 09:26 -0400
          Re: [OT] Comparing VCS tools (was ""Development tools and practices for Pythonistas") Daniel Kluev <dan.kluev@gmail.com> - 2011-04-30 05:08 +1100
    Re: Development tools and practices for Pythonistas Jean-Michel Pichavant <jeanmichel@sequans.com> - 2011-04-26 20:04 +0200
    Re: Development tools and practices for Pythonistas CM <cmpython@gmail.com> - 2011-04-26 11:29 -0700
      Re: Development tools and practices for Pythonistas CM <cmpython@gmail.com> - 2011-04-26 11:31 -0700
        Re: Development tools and practices for Pythonistas Algis Kabaila <akabaila@pcug.org.au> - 2011-04-27 04:50 +1000
    Re: Development tools and practices for Pythonistas Chris Angelico <rosuav@gmail.com> - 2011-04-27 06:14 +1000
      Re: Development tools and practices for Pythonistas Ben Finney <ben+python@benfinney.id.au> - 2011-04-27 09:41 +1000
        Re: Development tools and practices for Pythonistas Algis Kabaila <akabaila@pcug.org.au> - 2011-04-27 10:44 +1000
        Re: Development tools and practices for Pythonistas Jean-Michel Pichavant <jeanmichel@sequans.com> - 2011-04-27 11:24 +0200
          Re: Development tools and practices for Pythonistas Anssi Saari <as@sci.fi> - 2011-04-27 15:13 +0300
            Re: Development tools and practices for Pythonistas Jean-Michel Pichavant <jeanmichel@sequans.com> - 2011-04-27 14:24 +0200
              Re: Development tools and practices for Pythonistas Hans Georg Schaathun <hg@schaathun.net> - 2011-04-30 08:37 +0100
                Re: Development tools and practices for Pythonistas Martin Schöön <martin.schoon@gmail.com> - 2011-04-30 09:15 +0000
                  Re: [OT] VCS for non-text (was Development tools and practices for Pythonistas) Tim Chase <python.list@tim.thechases.com> - 2011-04-30 09:18 -0500
                    Re: [OT] VCS for non-text (was Development tools and practices for Pythonistas) Martin Schöön <martin.schoon@gmail.com> - 2011-05-01 19:53 +0000
              Re: Development tools and practices for Pythonistas Hans Georg Schaathun <hg@schaathun.net> - 2011-04-29 19:35 +0100
                Re: Development tools and practices for Pythonistas Ben Finney <ben+python@benfinney.id.au> - 2011-04-30 09:17 +1000
                  Re: Development tools and practices for Pythonistas CM <cmpython@gmail.com> - 2011-04-29 20:21 -0700
                    Re: Development tools and practices for Pythonistas Roy Smith <roy@panix.com> - 2011-04-29 23:54 -0400
                      Re: Development tools and practices for Pythonistas Ben Finney <ben+python@benfinney.id.au> - 2011-05-01 10:36 +1000
                        Re: Development tools and practices for Pythonistas Shawn Milochik <shawn@milochik.com> - 2011-04-30 20:47 -0400
                          Re: Development tools and practices for Pythonistas Dietmar Schwertberger <news@schwertberger.de> - 2011-05-01 18:11 +0200
                            Re: Development tools and practices for Pythonistas Jason Earl <jearl@notengoamigos.org> - 2011-05-01 14:51 -0600
                            Re: Development tools and practices for Pythonistas Ben Finney <ben+python@benfinney.id.au> - 2011-05-02 07:49 +1000
                              Re: Development tools and practices for Pythonistas Paul Rubin <no.email@nospam.invalid> - 2011-05-01 19:37 -0700
                            Re: Development tools and practices for Pythonistas David Boddie <david@boddie.org.uk> - 2011-05-02 01:33 +0200
                              Re: Development tools and practices for Pythonistas Dietmar Schwertberger <news@schwertberger.de> - 2011-05-02 19:40 +0200
                    Re: Development tools and practices for Pythonistas Shawn Milochik <shawn@milochik.com> - 2011-04-29 23:49 -0400
                    Re: Development tools and practices for Pythonistas rusi <rustompmody@gmail.com> - 2011-05-01 20:06 -0700
                      Re: Development tools and practices for Pythonistas Ben Finney <ben+python@benfinney.id.au> - 2011-05-02 13:22 +1000
                        Re: Development tools and practices for Pythonistas rusi <rustompmody@gmail.com> - 2011-05-01 20:45 -0700
                        Re: Development tools and practices for Pythonistas Algis Kabaila <akabaila@pcug.org.au> - 2011-05-02 17:08 +1000
                          Re: Development tools and practices for Pythonistas rusi <rustompmody@gmail.com> - 2011-05-02 00:19 -0700
                            Re: Development tools and practices for Pythonistas Algis Kabaila <akabaila@pcug.org.au> - 2011-05-02 17:48 +1000
                              Re: Development tools and practices for Pythonistas jacek2v <jacek2v@gmail.com> - 2011-05-02 02:09 -0700
                                Re: Development tools and practices for Pythonistas Algis Kabaila <akabaila@pcug.org.au> - 2011-05-02 20:38 +1000
                                  Re: Development tools and practices for Pythonistas jacek2v <jacek2v@gmail.com> - 2011-05-03 11:31 -0700
                      Re: Development tools and practices for Pythonistas Anssi Saari <as@sci.fi> - 2011-05-03 21:19 +0300
                        Re: Development tools and practices for Pythonistas rusi <rustompmody@gmail.com> - 2011-05-03 11:50 -0700
                          Re: Development tools and practices for Pythonistas Anssi Saari <as@sci.fi> - 2011-05-04 21:06 +0300
          Re: Development tools and practices for Pythonistas Ben Finney <ben+python@benfinney.id.au> - 2011-04-27 22:14 +1000
        Re: Development tools and practices for Pythonistas Chris Angelico <rosuav@gmail.com> - 2011-04-27 19:33 +1000
        Re: Development tools and practices for Pythonistas Jean-Michel Pichavant <jeanmichel@sequans.com> - 2011-04-27 13:17 +0200
          Re: Development tools and practices for Pythonistas Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-04-27 20:08 +0200
            Re: Development tools and practices for Pythonistas Ben Finney <ben+python@benfinney.id.au> - 2011-04-28 09:44 +1000
        Re: [OT] VCS tools (was "Development tools and practices for Pythonistas") Tim Chase <python.list@tim.thechases.com> - 2011-04-27 14:07 -0500
          Re: [OT] VCS tools (was "Development tools and practices for Pythonistas") Martin Schöön <martin.schoon@gmail.com> - 2011-04-28 20:48 +0000
            Re: [OT] VCS tools Ben Finney <ben+python@benfinney.id.au> - 2011-04-29 07:50 +1000
              Re: [OT] VCS tools Tim Chase <python.list@tim.thechases.com> - 2011-04-28 18:09 -0500
              Re: [OT] VCS tools Daniel Kluev <dan.kluev@gmail.com> - 2011-04-29 11:37 +1100
              Re: [OT] From svn to something else? (was: VCS tools) Hans Georg Schaathun <georg@schaathun.net> - 2011-04-29 11:07 +0100
                Re: [OT] From svn to something else? Tim Chase <python.list@tim.thechases.com> - 2011-04-29 06:50 -0500
                  Re: [OT] From svn to something else? Hans Georg Schaathun <hg@schaathun.net> - 2011-04-29 18:01 +0100
                    Re: [OT] From svn to something else? Tim Chase <python.list@tim.thechases.com> - 2011-04-29 13:23 -0500
                Re: [OT] From svn to something else? Ben Finney <ben+python@benfinney.id.au> - 2011-04-29 22:53 +1000
                  Re: [OT] From svn to something else? "D'Arcy J.M. Cain" <darcy@druid.net> - 2011-04-29 09:26 -0400
              Re: [OT] VCS tools Martin Schöön <martin.schoon@gmail.com> - 2011-04-29 18:46 +0000
    Re: Development tools and practices for Pythonistas Dan Stromberg <drsalists@gmail.com> - 2011-04-26 14:00 -0700
    recommended Emacs mode (was Re: Development tools and practices for Pythonistas) Gour-Gadadhara Dasa <gour@atmarama.net> - 2011-04-27 08:39 +0200
      Re: recommended Emacs mode (was Re: Development tools and practices for Pythonistas) rusi <rustompmody@gmail.com> - 2011-04-27 00:51 -0700
        Re: recommended Emacs mode Gour-Gadadhara Dasa <gour@atmarama.net> - 2011-04-27 10:10 +0200
    Re: Development tools and practices for Pythonistas Jonathan Hartley <tartley@tartley.com> - 2011-05-06 02:51 -0700
      Re: Development tools and practices for Pythonistas Tim Golden <mail@timgolden.me.uk> - 2011-05-06 10:59 +0100
        Python packaging (was Development tools and practices for Pythonistas) rusi <rustompmody@gmail.com> - 2011-05-06 04:55 -0700
    Re: Development tools and practices for Pythonistas rusi <rustompmody@gmail.com> - 2011-05-08 00:43 -0700
    Re: Development tools and practices for Pythonistas Roy Smith <roy@panix.com> - 2011-05-08 09:31 -0400
      Non Programming in python rusi <rustompmody@gmail.com> - 2011-05-10 09:41 -0700
        Re: Non Programming in python Terry Reedy <tjreedy@udel.edu> - 2011-05-10 15:28 -0400
          Re: Non Programming in python rusi <rustompmody@gmail.com> - 2011-05-10 20:36 -0700
        Re: Non Programming in python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-10 22:53 +0000

Page 1 of 5  [1] 2 3 4 5  Next page →

#4044 — Development tools and practices for Pythonistas

I'm not a Pythonista, but I aspire to be.

My current tools:

Python, gvim, OS file system

My current practices:

When I write a Python app, I have several unorganized scripts in a
directory (usually with several named test1.py, test2.py, etc., from
random ideas I have tested), and maybe a todo.txt file. Then I hack
away, adding features in a semi-random order. Then I get busy with
other things. Maybe one week I spend 20 hours on development. The next
week, no time on development. A few weeks later when I have some time,
I'm excited to get back to making progress, only to find that I have
to spend 30-60 minutes figuring out where I left off. The code is
usually out of sync with todo.txt. I see people who release new
versions and bug fixes, so I sometimes will create a new directory and
continue working from that copy, because it seems like the thing to
do. But if I ever made something worth releasing, and got a request
like, "I have problems with the 2.0 version. Can you send me the old
1.1 version?" I'd be like, "uhhh... let me hunt through my files by
hand and get back to you in a month". I'm thinking I can do a lot
better than this.

I am aware of tools like version control systems, bug trackers, and
things like these, but I'm not really sure if I need them, or how to
use them properly. I think having some organization to all of this
would help me to make more consistent progress, and spend less time
bringing myself up to speed after some time off.

I really like the idea of having a list of features, and tackling
those features one at a time. I read about people who do this, and
each new features gets a new minor version number. It sounds very
organized and clean. But I'm not really sure of the best way to
achieve this. Mainly I think I just need some recommendations to help
create a good mental map of what needs to happen, and mapping jargon
to concepts. Like, "each feature gets its own directory". Or with a
version control tool, I don't know if a feature maps to a branch, or a
commit?

I appreciate any advice or guidance anyone has to offer.

[toc] | [next] | [standalone]

#4047

On Apr 26, 7:39 pm, snorble <snor...@hotmail.com> wrote:


> I am aware of tools like version control systems, bug trackers, and
> things like these, but I'm not really sure if I need them,

You either dont want version control....

> But if I ever made something worth releasing, and got a request
> like, "I have problems with the 2.0 version. Can you send me the old
> 1.1 version?" I'd be like, "uhhh... let me hunt through my files by
> hand and get back to you in a month". I'm thinking I can do a lot
> better than this.

Or you do!


> or how to use them properly.

So the best advice would be: Forget python (for a while) and study one
(modern distributed) version control system:
http://en.wikipedia.org/wiki/Distributed_revision_control

From Joel Spolsky's  http://joelonsoftware.com/items/2010/03/17.html

With distributed version control, the distributed part is actually not
the most interesting part.
The interesting part is that these systems think in terms of changes,
not in terms of versions.

bug-trackers are a bit of overkill for a solo developer. However...

> My current tools:

> Python, gvim, OS file system
Hand in hand with a DVCS, you need to add a testing framework.

[toc] | [prev] | [next] | [standalone]

#4048

On 26/04/2011 14:39, snorble wrote:
<cut explanation>
I would strongly advice to get familiar with:
- Lint tools (like PyLint)
- Refactoring
- Source Control Systems (like Mercurial Hg)
- Unit Testing with Code Coverage

Followed by either writing your own toolset that integrates all of the 
above or start learning an IDE that has that stuff built-in (my personal 
preference is the latter with my current IDE being PyDev (Eclipse)).

Yes you will be less productive for a couple of weeks, but I promise you 
that once you know the above you win that time back very shortly, or if 
you are as chaotic as me, within a week :-).

-- 
mph

[toc] | [prev] | [next] | [standalone]

#4058

Am 26.04.2011 16:39, schrieb snorble:

> When I write a Python app, I have several unorganized scripts in a
> directory (usually with several named test1.py, test2.py, etc., from
> random ideas I have tested), and maybe a todo.txt file. Then I hack
> away, adding features in a semi-random order. Then I get busy with
> other things. Maybe one week I spend 20 hours on development. The next
> week, no time on development. A few weeks later when I have some time,
> I'm excited to get back to making progress, only to find that I have
> to spend 30-60 minutes figuring out where I left off. The code is
> usually out of sync with todo.txt.

That happens...


 > I see people who release new
> versions and bug fixes, so I sometimes will create a new directory and
> continue working from that copy, because it seems like the thing to
> do. But if I ever made something worth releasing, and got a request
> like, "I have problems with the 2.0 version. Can you send me the old
> 1.1 version?" I'd be like, "uhhh... let me hunt through my files by
> hand and get back to you in a month". I'm thinking I can do a lot
> better than this.

That is another subject (IMO), and you are right: you can do a very lot 
better, using the right tools.


> I am aware of tools like version control systems, bug trackers, and
> things like these, but I'm not really sure if I need them, or how to
> use them properly.

I have been using several VCS for about 5 or 6 years now, and I can only 
tell you that, once started using them, you will wonder how you ever got 
along without them.


 > I think having some organization to all of this
> would help me to make more consistent progress, and spend less time
> bringing myself up to speed after some time off.

I don't see how these tools will help to get up to date the way you 
describe it - but all other issues are well coped with using a VCS. I 
personally started with cvs (don't do that!), then worked with svn (do 
that only if you really need that), then got working with hg 
(Mercurial), which is a very good thing.


Say, you have a certain development progress, and you add a new feature.
Then you do all the changes, including increasing the version number. 
The changes you just have done are one changeset which you commit, 
providing a good commit message. If you have a version which you ship 
out, you give it a tag. In this way, you can easily change from 2.0 you 
are working on to 1.5 requested by the customer.


Thomas

[toc] | [prev] | [next] | [standalone]

#4065

On Wednesday 27 April 2011 03:59:25 Thomas Rachel wrote:
> Am 26.04.2011 16:39, schrieb snorble:
> > When I write a Python app, I have several unorganized

> I don't see how these tools will help to get up to date the
> way you describe it - but all other issues are well coped
> with using a VCS. I personally started with cvs (don't do
> that!), then worked with svn (do that only if you really
> need that), then got working with hg (Mercurial), which is a
> very good thing.
> 
> Thomas

Thomas, have you tried bzr (Bazaar) and if so do you consider hg 
(Mercurial) better?

And why is it better?   (bzr is widely used in ubuntu, which is 
my favourite distro at present).

TIA,

OldAl.
-- 
Algis
http://akabaila.pcug.org.au/StructuralAnalysis.pdf

[toc] | [prev] | [next] | [standalone]

#4096

Am 26.04.2011 20:42, schrieb Algis Kabaila:

> Thomas, have you tried bzr (Bazaar) and if so do you consider hg
> (Mercurial) better?

I have played around with bzr, but afterwards more with hg which gave me 
a better beeling (don't know why)...

Thomas

[toc] | [prev] | [next] | [standalone]

#4102 — Re: [OT] Comparing VCS tools (was ""Development tools and practices for Pythonistas")

On 04/26/2011 01:42 PM, Algis Kabaila wrote:
> Thomas, have you tried bzr (Bazaar) and if so do you consider hg
> (Mercurial) better?
>
> And why is it better?   (bzr is widely used in ubuntu, which is
> my favourite distro at present).

Each of the main 3 (bzr, hg, git) have advantages and 
disadvantages.  As Ben (and others?) mentions, it's best to learn 
one of these instead of starting with something like Subversion 
or worse (CVS or worse, *shudder* MS Visual SourceSafe)


Bazaar (bzr)
============
launchpad.net popular for hosting
Pros:
- some Ubuntu interactions (such as launchpad) easier
- a rigorous focus on correctness
- written in Python (with a small optional bit of C)
- easy-to-use interface (CVS-ish)
- good cross-platform support

Cons:
- was slow, though I understand they've worked on improving this

Protocols:
- custom/smart protocol
- http
- sftp
- ftp
- rsync (via plugin)


Mercurial (hg)
==============
BitBucket is popular for hosting
Pros:
- speedy
- written in Python (with a small optional bit of C)
- easy-to-use interface (CVS-ish)
- fairly compact repositories
- EXCELLENT documentation via online book
- chosen by Python as the repository of choice
- good cross-platform support

Cons:
- no biggies that I've found

Protocols:
- http
- ssh


Git (git)
=========
GitHub is popular for hosting
Pros:
- a *lot* of popular projects use it (Linux kernel)
- fast
- fairly compact repositories
- good documentation (though somewhat scattered)

Cons:
- interface diverges from the "CVS standards"
- (was?) not native on
- repositories require periodic maintenance using git gc
- Win32 support is/was a little clunky
- interface was under tumultuous change for a while (though it 
seems to have stabilized now)

Protocols:
- custom/smart protocol
- http
- sftp
- ftp


So that said, I've become a Mercurial user because the interface 
was close to SVN which I used previously, and it was speedy on my 
older machines.  If bzr has come up to comparable speed, I'd be 
game to probe it again.  I just don't care for git's command-line 
UI, but that's a personal preference thing (just like I prefer 
vi/vim over emacs, but acknowledge there are lots of smart folks 
on the other side, too).

-tkc

For at least hg vs. git, see
http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast

[toc] | [prev] | [next] | [standalone]

#4103 — Re: [OT] Comparing VCS tools

Tim Chase <python.list@tim.thechases.com> writes:

> Bazaar (bzr)
> ============
> launchpad.net popular for hosting
> Pros:
> - some Ubuntu interactions (such as launchpad) easier
> - a rigorous focus on correctness
> - written in Python (with a small optional bit of C)
> - easy-to-use interface (CVS-ish)
> - good cross-platform support

- Launchpad is free software (so anyone could run their own instance to
  host Bazaar repositories).

- Merges preserve all revision data, but history displays don't show
  merged revisions by default. (This obviates most of the need for
  history-altering commands in other VCSen to “tidy up” the revision
  data: it's tidy already by default.)

- Very smooth interaction with “foreign” VCS repositories, especially
  Subversion.

- Supports a wide range of workflows, without forcing peers to the same
  workflow.

  - Especially: Supports “centralised” (Subversion-style) VCS workflow
    without losing any of the distributed advantages.

- Treats files, and filename changes, as first-class citizens in the
  revision data. (Git and some others use fallible heuristics to figure
  those out after-the-fact instead of recording the data.)

> Cons:
> - was slow, though I understand they've worked on improving this

Right, that's not a count against Bazaar for at least the last several
versions (since 2009 at least). Bazaar is easily fast enough for
anything people use, say, Mercurial for.

Cons:

- Repository formats were changing frequently for a while, leaving a
  legacy of confusion (fixed now, but the confusion is still a black
  mark).

- Limited developer base, because of Canonical's community-hostile
  “contribution agreement” requirements.

- Currently only one big public full-featured hosting of Bazaar
  repositories: Launchpad.net.

- The most advanced web UI to browse Bazaar repositories, “loggerhead”,
  is somewhat lacking compared to the ones at Git and Mercurial hosting
  sites.

> Mercurial (hg)
> ==============
> BitBucket is popular for hosting
> Pros:
> - speedy

This isn't a significant advantage for Mercurial against Git (which is
much faster) or Bazaar (which is easily as fast as Mercurial).

> - fairly compact repositories

Again, this isn't a significant advantage for Mercurial over either of
Git or Bazaar.

> - chosen by Python as the repository of choice

As I understand it, the decision was down to Bazaar or Mercurial, which
were each close enough in technical and workflow assessment that the
decision was made on personal preference. Fair enough, and it does give
another reason *now* to use Mercurial, but not due to any particular
advantage in Mercurial.

> Cons:
> - no biggies that I've found

- (Anecdotal) Merge algorithm sometimes fails catastrophically.

- Merged revisions aren't hidden, leading users to alter history.

> Protocols:
> - http
> - ssh


> Git (git)
> =========
> GitHub is popular for hosting

Unlike GitHub, Gitorious is a free-software Git hosting provider.

> Pros:
> - a *lot* of popular projects use it (Linux kernel)
> - fast
> - fairly compact repositories
> - good documentation (though somewhat scattered)

Hmm. Can't really overcome the rampant NIH syndrome: there is a lot that
shouldn't *need* so much documentation if the interface were better
designed from the start. I wouldn't count this as a pro for Git.

> Cons:
> - interface diverges from the "CVS standards"

- Terminology and command-line API gratuitously arcane (I'm reminded of
  GNU Arch, *shudder*).

- Merged revisions aren't hidden, leading users to alter history.

> So that said, I've become a Mercurial user because the interface was
> close to SVN which I used previously, and it was speedy on my older
> machines. If bzr has come up to comparable speed, I'd be game to probe
> it again.

I recommend doing so.

-- 
 \      “If I haven't seen as far as others, it is because giants were |
  `\                           standing on my shoulders.” —Hal Abelson |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#4114 — Re: [OT] Comparing VCS tools

Ben Finney <ben+python@benfinney.id.au> writes:

> Tim Chase <python.list@tim.thechases.com> writes:
> > Mercurial (hg)
> > ==============
[…]
> > Cons:
> > - no biggies that I've found
>
> - (Anecdotal) Merge algorithm sometimes fails catastrophically.

I'm going to retract this one point. Merging is not as clear as in
Bazaar, but not enough to count against Mercurial – and certainly not
“fail”.

> - Merged revisions aren't hidden, leading users to alter history.

This still stands as a point against Mercurial (and against Git).

-- 
 \        “Always code as if the guy who ends up maintaining your code |
  `\     will be a violent psychopath who knows where you live.” —John |
_o__)                                                         F. Woods |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#4152 — Re: [OT] Comparing VCS tools

On 04/26/2011 09:45 PM, Ben Finney wrote:
> Tim Chase<python.list@tim.thechases.com>  writes:
>> Bazaar (bzr)
>> ============
>> Cons:
>> - was slow, though I understand they've worked on improving this
>
> Right, that's not a count against Bazaar for at least the last several
> versions (since 2009 at least). Bazaar is easily fast enough for
> anything people use, say, Mercurial for.

Glad to hear.  That was my biggest beef with bzr when I tried it 
(c. 2008), so if they've got that working well, it's worth my 
time to revisit.  Do you have a reference for timing improvements 
against version number ("in version x.y, action Z took N ms; in 
version x.[y+1], action Z took N-M ms")?  I'm running Debian 
Stable and sometimes it takes a little while for these features 
to trickle down.  But I *hope* changes in 2009 would have made it 
in by now :)



>> Git (git)
>> =========
>> Pros:
>> - good documentation (though somewhat scattered)
>
> Hmm. Can't really overcome the rampant NIH syndrome: there is a lot that
> shouldn't *need* so much documentation if the interface were better
> designed from the start. I wouldn't count this as a pro for Git.

Yeah, I've encountered that aspect of the abundant documentation 
on Git. :)

>> So that said, I've become a Mercurial user because the interface was
>> close to SVN which I used previously, and it was speedy on my older
>> machines. If bzr has come up to comparable speed, I'd be game to probe
>> it again.
>
> I recommend doing so.

Thanks for giving me something to do this weekend. :)

-tkc

[toc] | [prev] | [next] | [standalone]

#4104 — Re: Comparing VCS tools (was ""Development tools and practices for Pythonistas")

On Apr 27, 6:44 am, Tim Chase <python.l...@tim.thechases.com> wrote:
> On 04/26/2011 01:42 PM, Algis Kabaila wrote:
>
> > Thomas, have you tried bzr (Bazaar) and if so do you consider hg
> > (Mercurial) better?
>
> > And why is it better?   (bzr is widely used in ubuntu, which is
> > my favourite distro at present).
>
> Each of the main 3 (bzr, hg, git) have advantages and
> disadvantages.  As Ben (and others?) mentions, it's best to learn
> one of these instead of starting with something like Subversion
> or worse (CVS or worse, *shudder* MS Visual SourceSafe)

<pros and cons of bzr, git, mercurial snipped>

The distributed revision control page on wikipedia (bottom)
http://en.wikipedia.org/wiki/Distributed_revision_control
in addition to these, mentions fossil -- something I had not heard of
till now.


Its claims seem to match the OPs lightweight requirements more closely
than any other:

(from above link)
---------------------------
Fossil is cross-platform; its source code compiles on Linux, Mac OS X
and Microsoft Windows. It is not only capable of distributed version
control like Git and Mercurial but also supports distributed bug
tracking, a distributed wiki and a distributed blog mechanism all in a
single integrated package. With its built-in and easy-to-use web
interface, Fossil simplifies project tracking and promotes situational
awareness. A user may simply type "fossil ui" from within any check-
out and Fossil automatically opens the user's web browser in a page
that gives detailed history and status information on that project.
--------------------------
Well so much for the claims :-)

What's the facts? Anyone with any experiences on this?

[toc] | [prev] | [next] | [standalone]

#4107 — Re: Comparing VCS tools (was ""Development tools and practices for Pythonistas")

rusi <rustompm...@gmail.com> wrote:
> What's the facts? Anyone with any experiences on this?

No experience, but I'm rather torn over Fossil. On the one hand, it
feels like NIH writ large; on the other hand, it's a DVCS with Trac-
like features in a standalone executable less than 1MB in size...by
the author of sqlite.

[toc] | [prev] | [next] | [standalone]

#4311 — Re: [OT] Comparing VCS tools (was ""Development tools and practices for Pythonistas")

Fossil is another SCM to consider: http://www.fossil-scm.org/

It's written by the author of SQLite, D. Richard Hipp. It's not as 
well-known as some of the other DCVS's, but the Tcl/Tk language projects 
have moved their core development to it (http://core.tcl.tk). This is 
relevant to Python because Tkinter is part of the stlib.

There aren't any huge sites like Github providing Fossil hosting, but 
here is one site: http://chiselapp.com/

--Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[toc] | [prev] | [next] | [standalone]

#4316 — Re: [OT] Comparing VCS tools (was ""Development tools and practices for Pythonistas")

We were looking for some simple integrated SCM, issue tracker and wiki
in our university for software design and software testing courses,
and fossil seems to be perfect match, thanks for sharing.

-- 
With best regards,
Daniel Kluev

[toc] | [prev] | [next] | [standalone]

#4060

snorble wrote:
> I'm not a Pythonista, but I aspire to be.
>
> My current tools:
>
> Python, gvim, OS file system
>
> My current practices:
>
> When I write a Python app, I have several unorganized scripts in a
> directory (usually with several named test1.py, test2.py, etc., from
> random ideas I have tested), and maybe a todo.txt file. Then I hack
> away, adding features in a semi-random order. Then I get busy with
> other things. Maybe one week I spend 20 hours on development. The next
> week, no time on development. A few weeks later when I have some time,
> I'm excited to get back to making progress, only to find that I have
> to spend 30-60 minutes figuring out where I left off. The code is
> usually out of sync with todo.txt. I see people who release new
> versions and bug fixes, so I sometimes will create a new directory and
> continue working from that copy, because it seems like the thing to
> do. But if I ever made something worth releasing, and got a request
> like, "I have problems with the 2.0 version. Can you send me the old
> 1.1 version?" I'd be like, "uhhh... let me hunt through my files by
> hand and get back to you in a month". I'm thinking I can do a lot
> better than this.
>
> I am aware of tools like version control systems, bug trackers, and
> things like these, but I'm not really sure if I need them, or how to
> use them properly. I think having some organization to all of this
> would help me to make more consistent progress, and spend less time
> bringing myself up to speed after some time off.
>
> I really like the idea of having a list of features, and tackling
> those features one at a time. I read about people who do this, and
> each new features gets a new minor version number. It sounds very
> organized and clean. But I'm not really sure of the best way to
> achieve this. Mainly I think I just need some recommendations to help
> create a good mental map of what needs to happen, and mapping jargon
> to concepts. Like, "each feature gets its own directory". Or with a
> version control tool, I don't know if a feature maps to a branch, or a
> commit?
>
> I appreciate any advice or guidance anyone has to offer.
>   
You can have a look at SVN and bugzilla, they are free SCM & bug tracker 
applications.
Make sure it's worth the pain though, these tools are not that easy to 
administrate (the usage is pretty simple).

JM

[toc] | [prev] | [next] | [standalone]

#4062

On Apr 26, 10:39 am, snorble <snor...@hotmail.com> wrote:
> I'm not a Pythonista, but I aspire to be.
>
> My current tools:
>
> Python, gvim, OS file system
>
> My current practices:
>
> When I write a Python app, I have several unorganized scripts in a
> directory (usually with several named test1.py, test2.py, etc., from
> random ideas I have tested), and maybe a todo.txt file.

First, give your files meaningful names.  test1.py, test2.py...no
wonder you have to spend an hour just figuring out where you left
off.  Imagine instead if these were modules called
DiskAccessUtilities.py and UserPreferencesPanel.py.  You should also
use highly descriptive names in naming classes and functions, too,
with functions being verbs and don't be afraid of long(ish) function
names like AddNewCustomerToDatabase()

> Then I hack away, adding features in a semi-random order.

I'd spend an hour with your TODO list and break it into priority
categories, like High, Med, Low, and It Would Be Nice, and then take
them strictly in that order.  I'd also date the issues so you have a
sense for how long something has been waiting to be fixed.

> Then I get busy with other things. Maybe one week I spend 20 hours > on development. The next week, no time on development. A few
> weeks later when I have some time, I'm excited to get back to making
> progress, only to find that I have to spend 30-60 minutes figuring out
> where I left off.

I would try to not stop in the middle of creating a new feature or
fixing a bug, but try to finish it out before taking a week off.  This
way, when you come back, you can just tackle something from the High
Priority stack and not have to figure out where you were.

> The code is usually out of sync with todo.txt.

That's just a matter of being disciplined.  When I fix a bug, I simply
cut the bug from the TODO part to the DONE part of the .txt file,
nearly every time.  It requires no effort compared to actually fixing
the bug, yet it feels satisfying to get that text moved.

> would help me to make more consistent progress, and spend less time
> bringing myself up to speed after some time off.

Are you documenting your code?  That can help (I need to get better
about that as well).  Also, are things broken down into modules that
are self-contained?  That also can help much.  Is the TODO.txt always
open while you are working?  It should be.  Lastly, keeping some kind
of notebook or even Post-Its or a bulletin board over your desk with
notes as to what's next and where to hunt in your code to get at it
should help.  Imagine if you take two weeks off, come back, want to
work on the project, and you find this note on your bulletin board:
"In the CustomersPanel.py module, add support for a wxSearchCtrl
(search bar) that searches the Former_Customers table in the main
database..."  Now you are ready to jump right in!

> I really like the idea of having a list of features, and tackling
> those features one at a time. I read about people who do this, and
> each new features gets a new minor version number.

Is that true?  I'm under the impression that projects do a bunch of
changes (bug fixes, and new features) and then release a new version
that has a decent amount of changes.  I don't think people want tons
of versions of most projects around, but that each release should have
an appreciable amount of good changes.

> to concepts. Like, "each feature gets its own directory".

I guess it depends on your project, but that sounds needlessly complex
and way too tough with a VCS.  I'd say just don't go there.

Once you use a VCS you will probably settle into a better pattern, but
things like good naming, documenting, notes, prioritizing features/
bugs, and roadmaps don't magically go away.  Software development
takes long range thinking and some organizational discipline.

Che

[toc] | [prev] | [next] | [standalone]

#4064

> I guess it depends on your project, but that sounds needlessly complex
> and way too tough with a VCS.  I'd say just don't go there.

(Whoops, I meant way too tough *without* a VCS, not with)

[toc] | [prev] | [next] | [standalone]

#4067

On Wednesday 27 April 2011 04:31:19 CM wrote:
> > I guess it depends on your project, but that sounds
> > needlessly complex and way too tough with a VCS.  I'd say
> > just don't go there.
> 
> (Whoops, I meant way too tough *without* a VCS, not with)

And read your own emails *before* sending them   :)

Actually, CM has given some very good advice!  As I am probably 
the oldest person on this list, so my penny's worth is that some 
going over old stuff is good - learning is repetitious and  
memory is not going to get better with age, so learn to live 
with it (it being the frailty of memory...)

OldAl.
-- 
Algis
http://akabaila.pcug.org.au/StructuralAnalysis.pdf

[toc] | [prev] | [next] | [standalone]

#4077

On Wed, Apr 27, 2011 at 12:39 AM, snorble <snorble@hotmail.com> wrote:
> When I write a Python app, I have several unorganized scripts in a
> directory (usually with several named test1.py, test2.py, etc., from
> random ideas I have tested), and maybe a todo.txt file. ... The code is
> usually out of sync with todo.txt. I see people who release new
> versions and bug fixes, so I sometimes will create a new directory and
> continue working from that copy, because it seems like the thing to
> do. But if I ever made something worth releasing, and got a request
> like, "I have problems with the 2.0 version. Can you send me the old
> 1.1 version?"

As other people have said, version control is very handy. I use git
myself, but imho the choice of _which_ VCS you use is far less
important than the choice of _whether_ to use one.

As to the todo file - I tend to keep only vague ideas in a separate
file. Any todo that can be logically associated with a code file or,
especially, a particular piece of code, goes in that source file:

def function(parms):
    # TODO: This should check if Foo matches Bar and shortcut the computation
    ...

I have a very strict format: T, O, D, O, literal ASCII, always
uppercase. Makes it easy to grep (and I try to avoid "todo" in
lower-case, which means I can use a case-insensitive search if I
choose).

Additionally, if there's any task that will require checking of
multiple parts of the code, I'll create a keyword for it. For
instance, if I'm considering adding a local cache to an application to
reduce database traffic, I might do this:

//TODO CACHE: This will need to update the cache
...
//TODO CACHE: Read from cache instead
...
//TODO CACHE: Would this affect the cache?
... etc

The benefits of having the comments right beside the code cannot be
underestimated. Comments are far less likely to get out of sync if
they stare you in the face while you're changing the code - this is
why doxygen and friends are so useful.

Ultimately, it all comes down to discipline, and how important the
project is to you. At work, I have a lot of disciplines; we have a
wiki where stuff gets documented, we have source control, we have
daily backups (as well), etc, etc, etc. For little home projects, it's
not usually worth the effort. Take your pick, where do you want to go?

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#4097

Chris Angelico <rosuav@gmail.com> writes:

> As other people have said, version control is very handy. I use git
> myself, but imho the choice of _which_ VCS you use is far less
> important than the choice of _whether_ to use one.

True enough. But the modern crop of first-tier VCSen – Bazaar, Git,
Mercurial – are the ones to choose from. Anoyone recommending a VCS tool
that has poor merging support (such as Subversion or, heaven help us,
CVS) is doing the newcomer a disservice.

Learn the basics in all three of those, and learn one of them well. My
choice is Bazaar, because it has a very friendly command-line interface
and has excellent support for repositories created by all the others :-)

> def function(parms):
>     # TODO: This should check if Foo matches Bar and shortcut the computation
>     ...
>
> I have a very strict format: T, O, D, O, literal ASCII, always
> uppercase. Makes it easy to grep (and I try to avoid "todo" in
> lower-case, which means I can use a case-insensitive search if I
> choose).

Note that following that specific convention will match the default in
many programmers's text editors for highlighting those entries to bring
them to the programmer's attention. The defaults for PyLint also report
such comments in the code.

> Ultimately, it all comes down to discipline, and how important the
> project is to you. At work, I have a lot of disciplines; we have a
> wiki where stuff gets documented, we have source control, we have
> daily backups (as well), etc, etc, etc. For little home projects, it's
> not usually worth the effort. Take your pick, where do you want to go?

The two practices above – use a modern VCS, maintain TODO items such
that the computer can report them automatically – are so useful and so
inexpensive that I think anyone aspiring to become a good programmer is
foolish if they omit them on any project.

-- 
 \       “If you make people think they're thinking, they'll love you; |
  `\     but if you really make them think, they'll hate you.” —Donald |
_o__)                                             Robert Perry Marquis |
Ben Finney

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.python

csiph-web