Re: Where does setuptools live?
On Jul 7, 4:06 am, Chris Withers wrote: > David Lyon wrote: > > > What hasn't happened is enough testing of pypi packages and installing > > with setuptools/pip/enstall from pypi. > > What needs testing? > > More important for me is which of these has the most active development > community. How do we judge that? Currently, distutils itself is being actively developed. More info about this here: http://tarekziade.wordpress.com/ My (albeit anonymous) advice is: use distutils. Manually download packages as-needed from PyPI and install manually using standard distutils. Read more about distutils here http://wiki.python.org/moin/Distutils and of course in the Python docs. If you want to contribute, my first guess would be that Tarek could use help writing tests (but I don't know what distutils coverage looks like at the moment). When Tarek says, "For package installation that takes care of dependencies, uninstall, etc., use $tool", then I'll start using $tool. Until then, it's just straight distutils for me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Where does setuptools live?
On Jul 10, 10:26 am, Chris Withers wrote: > Inky 788 wrote: > > Currently, distutils itself is being actively developed. More info > > about this here:http://tarekziade.wordpress.com/ > > > My (albeit anonymous) advice is: use distutils. Manually download > > packages as-needed from PyPI and install manually using standard > > distutils. > > No thanks. I'm a big fan of buildout. Making it possible for packages to > specify their dependencies is a big win... Yup, it's a big win. But package installation for Python is a bit of a mess right now. Neither setuptools nor buildout (nor pip for that matter) are a standard part of Python. It's rather silly that although Python is a batteries-included language, and it's mid-2009, and Python 3.1 has been released, that Python *still* doesn't have a standard built-in way to handle package installation (including dependencies and uninstallation). My guess is that once distutils finishes getting spruced up, some intrepid hacker is going to: * take the best parts of pip and the best parts of setuptools (I don't know anything about buildout), * stir vigorously, * ruthlessly remove the excess pieces, * write good documentation for it, * throw the result up on github/launchpad/bitbucket/whatever, and then *that's* what everyone's going to start using and which will eventually make it into the Python std lib. But that's just my anon 2 cents. -- http://mail.python.org/mailman/listinfo/python-list
Re: Where does setuptools live?
On Jul 10, 10:26 am, Chris Withers wrote: > Inky 788 wrote: > > Currently, distutils itself is being actively developed. More info > > about this here:http://tarekziade.wordpress.com/ > > > My (albeit anonymous) advice is: use distutils. Manually download > > packages as-needed from PyPI and install manually using standard > > distutils. > > No thanks. I'm a big fan of buildout. Making it possible for packages to > specify their dependencies is a big win... Read this: http://tarekziade.wordpress.com/2009/07/03/dropping-pep-386-versions-comparison/ So, again, I don't know anything about buildout, and it might be a nice interim solution, but there are some new and exciting developments in distutils coming down the pike, and whatever becomes the standard Python package management system will very likely be based on those new developments. I just hope it all happens sooner than later. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Why not enforce four space indentations in version 3.x?
On Jul 10, 7:35 pm, Ben Finney wrote:
> walterbyrd writes:
> > I believe Guido himself has said that all indentions should be four
> > spaces - no tabs.
>
> Yes. That's a “should” and not a “must”, even though PEP 8 says it
> with a simple imperative::
>
> Use 4 spaces per indentation level.
That actually sounds pretty weird. "Don't do {foo}. Really, I mean
*really* don't do {foo}. Oh, also, the interpreter allows you to do
{foo}. But don't do it! I mean it!".
Very ... perlish, if you ask me.
I realize that a small portion of the community likes the tabs.
They're sold on the tabs. They like the tabs. But tabs are an archaic
holdover from an era when typewriters had physical tabstops on them.
Actually, after *that* they're a holdover from a program called `make`
whose designers unfortunately decided to use tab "characters" to
prefix commands. The tab is vestigial. Your text editor can treat 4
consecutive spaces as a unit if you wish. Let tabs go away. Stop using
them. If your editor keeps irrationally inserting them, make it stop.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why not enforce four space indentations in version 3.x?
On Jul 16, 10:18 am, Tim Chase wrote: > > I realize that a small portion of the community likes the tabs. > > They're sold on the tabs. They like the tabs. But tabs are an archaic > > holdover from an era when typewriters had physical tabstops on them. > > However, they are a single logical level of indentation -- I come > down fairly solidly on the "tabs" side of the "tabs vs. spaces" > argument. My bet is that the problem is this: some people like to format their code in ways that don't work well when you're using tabs. For example, they might want to call a function like this (note spaces): some_func(foo=1, bar=2, baz=3) instead of: some_func( foo=1, bar=2, baz=3) The first one requires 10 spaces in front of bar and baz. If you're using tabs, that means one or two tabs plus some space characters. So, people who do that would probably never use tabs. The 2nd example is fine for tabs or spaces. I'm sure there are a bunch of similar examples for things besides function calls. Don't you ever find cases where you'd like to add in an extra space or two to make things line up nicely? > I can set my editor (vim in this case) to show tabs as > as many spaces as I want. I usually have this set to 4, but > sometimes 1 or 2. Just curious: why would you want to do that? In my experience, once my eyes got used to 4-space indents, everything else looks either too little or too much. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Help understanding the decisions *behind* python?
On Jul 20, 12:27 pm, Phillip B Oldham wrote: > [snip] We > understand that lists are mutable and tuples are not, but we're a > little lost as to why the two were kept separate from the start. They > both perform a very similar job as far as we can tell. My guess is that it was probably for optimization reasons long ago. I've never heard a *good* reason why Python needs both. -- http://mail.python.org/mailman/listinfo/python-list
Re: Help understanding the decisions *behind* python?
On Jul 22, 2:36 am, Hendrik van Rooyen wrote: > On Tuesday 21 July 2009 15:49:59 Inky 788 wrote: > > > On Jul 20, 12:27 pm, Phillip B Oldham > > > wrote: > > > [snip] We > > > understand that lists are mutable and tuples are not, but we're a > > > little lost as to why the two were kept separate from the start. They > > > both perform a very similar job as far as we can tell. > > > My guess is that it was probably for optimization reasons long ago. > > I've never heard a *good* reason why Python needs both. > > The good reason is the immutability, which lets you use > a tuple as a dict key. Thanks for the reply Hendrik (and Steven (other reply)). Perhaps I'm just not sophisticated enough, but I've never wanted to use a list/ tuple as a dict key. This sounds like obscure usage, and a bit contrived as a reason for having *both* lists and tuples. -- http://mail.python.org/mailman/listinfo/python-list
Re: Documentation Problems
On Jul 22, 7:15 am, Tim Golden wrote:
> Mark du Preez wrote:
> > Hi
>
> > Can anyone tell me where to go to suggest changes to the Python
> > documentation?
>
> Drop an entry in the tracker:
>
> http://bugs.python.org
>
> Patches are always welcome,
Could you please provide brief instructions on exactly how to go about
creating a suitable patch file? I mean, starting from the beginning
(as in, "check out code from {here} using {this command}", "cd to
{this} directory", "edit the file in place", "run {this} command to
create a patch file"). Or perhaps this procedure is already outlined
elsewhere?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Help understanding the decisions *behind* python?
On Jul 23, 3:42 am, Hendrik van Rooyen wrote: > On Wednesday 22 July 2009 16:36:51 Inky 788 wrote: > > > On Jul 22, 2:36 am, Hendrik van Rooyen > > > wrote: > > > The good reason is the immutability, which lets you use > > > a tuple as a dict key. > > > Thanks for the reply Hendrik (and Steven (other reply)). Perhaps I'm > > just not sophisticated enough, but I've never wanted to use a list/ > > tuple as a dict key. This sounds like obscure usage, and a bit > > contrived as a reason for having *both* lists and tuples. > > Steven showed why you cannot have a mutable thing > as a key in a dict. > > if you think it is contrived, then please consider how you would > keep track of say the colour of a pixel on a screen at position > (x,y) - this is about the simplest "natural" tuple format and > example. My guess is that this is probably the way most people do it: #!/usr/bin/env python import sys import random if len( sys.argv ) != 3: print "Please pass exactly 2 ints. Exiting." sys.exit(1) NUM_COLUMNS = int( sys.argv[1] ) NUM_ROWS= int( sys.argv[2] ) print "Making array of %s columns by %s rows." % (NUM_COLUMNS, NUM_ROWS) def rand(): return int( 255 * random.random()) def make_a_pixel(): # red green blue return [rand(), rand(), rand()] def make_a_row(num_columns): temp_row = [] for i in range(num_columns): temp_row.append( make_a_pixel() ) return temp_row def make_array_of_pixels(num_columns, num_rows): rows = [] for i in range(num_rows): rows.append( make_a_row(num_columns) ) return rows def show_pixels(pixel_array): for row in pixel_array: for pixel in row: print pixel, ' ', print rows_of_pixels = make_array_of_pixels(NUM_COLUMNS, NUM_ROWS) show_pixels(rows_of_pixels) -- http://mail.python.org/mailman/listinfo/python-list
Re: Confessions of a Python fanboy
On Jul 30, 12:04 am, alex23 wrote: > On Jul 30, 1:06 pm, r wrote: > > > 1.) No need to use "()" to call a function with no arguments. > > Python --> "obj.m2().m3()" --ugly > > Ruby --> "obj.m1.m2.m3" -- sweeet! > > Man, i must admit i really like this, and your code will look so much > > cleaner. > > How do you distinguish between calling a method with no arguments, and > getting access to the method object itself (because it _is_ an object, > y'know, it's OO all the way down...)? I agree with alex here. Will take the explicit syntax over the extra cognitive load of figuring out exactly what's going on with `obj.m1.m2.m3`. Python has its warts, but requiring ()'s on function calls isn't one of them. :) -- http://mail.python.org/mailman/listinfo/python-list
