date:20101103

On Mon, Nov 1, 2010 at 8:15 PM, Lawrence D'Oliveiro
 wrote:
> In message , Chris
> Rebert wrote:
>
>> desc_attr_colors_triples = (("normal", "image",
>> MainWindow.ColorsNormalList),
>>     ("highlighted", "highlight", MainWindow.ColorsHighlightedList),
>>     ("selected", "select", MainWindow.ColorsSelectedList))
>> for in description, attr, color_list in desc_attr_colors_triples:
>>     ...
>
> And so you have managed to separate one set of looping conditions into two
> parts. What is the significance of the name “desc_attr_colors_triples”? None
> at all. What purpose does it serve? None, really. Does it ease the
> maintenance burden? No, but by splitting your attention across two places,
> it actually adds to it.
>
> If this is all your PEP-8 can achieve, then a pox on it.

Actually, my PEP 8 reference was in regards to the (imo, terrible)
UseOfCamelCaseForNonClasses (Python != C#), not the formatting of the
for-loop; hence the "In any case" qualification.

Cheers,
Chris
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py3: decode subprocess output

On 2010-11-03, Gnarlodious  wrote:
> Under Python 3, subprocess.check_output returns a bytestring that
> doesn't parse. Since the CLI program (written in the 1990's) will
> never send Unicode, is there a way to downconvert the bytestring into
> type str so as to emulate Py2.6 behavior?

str() will convert a bytestring into a Python string object which you will
be able to parse so long as the output remains ASCII (which your example
is).  If the input uses another encoding or contains characters with the
high order bit set, you might need to fiddle with the strings encoding.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Mail Merge from python data

2010-11-03 Thread Dylan Evans

On Wed, Nov 3, 2010 at 3:20 PM, Tim Harig  wrote:

> This page didn't make it to through to my nntp server so I appologize if I
> miss something that was covered.
>
> On 2010-11-03, Dennis Lee Bieber  wrote:
> > On Tue, 2 Nov 2010 20:32:13 +1000, Dylan Evans 
> > declaimed the following in gmane.comp.python.general:
> >
> >> I'm setting up a database for an organisation who want to do mail merges
> in
> >> office 2010. I know i can use the MySQL ODBC driver for the mail merge
> but i
> >> have set up the database with lots of relations and many-to-many links
> which
> >> i'm sure will lead to a huge amount of confusion (I think, i don't
> really
> >> know much about mail merge).
>
> Many to many relationships without some kind of intersection table are
> considered a rather poor practice in general.


Yes an intersection table with a description char field.

>
> >> What i want to know is, is there anyway to send data from python, which
> the
> >> UI is written in, to office templates and mail merges?
> >
> >   If a long lived form, I'd probably define a query or view (I think
> > MySQL 5.x has output-only views) that isolates just to the data fields
> > used in the mail merge.
>
> I agree that a view would be the best solution if you have the access to do
> so; but, a couple of other alternatives come to mind in case you do not.
>
> That would help alot, it would certainly make it easier for then, i didn't
know about views, i will rtfm.


> 1. Do the mail merge in Python using a Word template.  Then you can add any
>kind of logic that you need to the merge.
>
> Can this be done in pure python? Bearing in mind that the server will be
linux


> 2. Add some kind of export function to your python UI that allows you to
>export the data to an Excel sheet, CSV, or even another ODBC data
>source (like another MySQL table or database that you might have
>access to).
>

I have considered this one, ideally the file saving would be skipped, since
it's only temporary and i am concerned that users may save many files mixing
them up, or try to use old export files which are out of sync with the
database. This is a community organisation with volunteers, so i expect
technical competency to be low. However if i can send the data directly from
python to office somehow i could avoid that issue. What would be perfect is
an ODBC driver which connected via XMLRPC or some other simple protocol.

Thanks for the help.

--
>
> http://mail.python.org/mailman/listinfo/python-list
>



-- 
"The UNIX system has a command, nice ... in order to be nice to the other
users. Nobody ever uses it." - Andrew S. Tanenbaum



-- 
"The UNIX system has a command, nice ... in order to be nice to the other
users. Nobody ever uses it." - Andrew S. Tanenbaum
-- 
http://mail.python.org/mailman/listinfo/python-list

Ways of accessing this mailing list?

Hope this isn't too O/T - I was just wondering how people read/send to 
this mailing list, eg. normal email client, gmane, some other software 
or online service?


My normal inbox is getting unmanageable, and I think I need to find a 
new way of following this and other lists.


Thanks for any suggestions.

Cheers, JB.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python documentation too difficult for beginners

2010-11-03 Thread jk

On Nov 2, 11:06 pm, Lawrence D'Oliveiro  wrote:
> In message
> , jk
> wrote:
>
> > This (http://epydoc.sourceforge.net/stdlib/) is what I'm talking
> > about.
>
> Framesets? Is that really your idea of well-laid-out documentation? Using a
> feature which has been derided (and dropped in HTML5) because of its effect
> on usability and accessibility?

No, the framesets suck, and I agree that Javadoc isn't perfect.
Actually, I do think the PHP docs are the best I've found as a
reference. Javadocs just need a few tweaks and they'd be better (an
index at the top so you don't have to scroll down, no framesets, a
search engine). Still think they're better than the python docs though.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py3: Import relative path module

MRAB wrote:

> On 03/11/2010 01:48, Gnarlodious wrote:
>> I admit I don't understand any of what was said here. Or why it is so
>> hard what I am trying to do. I searched Google for a few hours looking
>> for a way to import a module from an absolute path, but that was a
>> waste of time too.
>>
>> To reiterate, I am trying to import a Def function from a file one
>> level up. Let's say relative import is unreasonable to expect from
>> Python. If it is possible using an absolute path, please let me know
>> how, in plain language. Otherwise I can continue to copy and paste my
>> programming into several files.
>>
>> Thank you for any help.
>>
> After some experimentation (and Googling!) I think the problem is that
> a module can do your relative import but a main script can't.
> 
> Or, to put it another way, if __name__ is "__main__" then it won't work.

Slightly generalized: have the importing module print its __name__. There 
has to be at least one dot in the name for

from .. import whatever

to succeed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: functions, list, default parameters

2010-11-03 Thread Hrvoje Niksic

Paul Rudin  writes:

> Terry Reedy  writes:
>
>> Suppose I write an nasty C extension that mutates tuples. What then
>> would be illegal about...
>
> Depends on exactly what we mean by legal. If immutability is part of the
> language spec (rather than an artifact of a particular implementation)
> then a compiler could assume immutability.

And, indeed, it does exactly that.  Tuples of constant literals are
created at compilation time and reused across function invocations.

Mutating a tuple using a C extension is "illegal" in that it breaks the
rules of the system, by changing the semantics of valid code in
unexpected ways.  A more extreme example of this would be mutating the
constant 0 or the empty tuple.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Man pages and info pages

2010-11-03 Thread Hrvoje Niksic

Teemu Likonen  writes:

> Enter   Follow a link (down to node)
> u   up node level
> h   help (general how-to)
> ?   help (commands)
> s   search

And don't forget:

  l   last viewed page (aka "back")

That one seems to be the info reader's best-kept secret.
-- 
http://mail.python.org/mailman/listinfo/python-list

What people are using to access this mailing list

Hope this isn't too O/T - I was just wondering how people read/send to this 
mailing list, eg. normal email client, gmane, some other software or online 
service?

My normal inbox is getting unmanageable, and I think I need to find a new way 
of following this and other lists.

Thanks for any suggestions.

Cheers, JB. 

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

2010-11-03 Thread Xavier Ho

Gmail.

-Xav


On 3 November 2010 18:02, John Bond  wrote:

> Hope this isn't too O/T - I was just wondering how people read/send to this
> mailing list, eg. normal email client, gmane, some other software or online
> service?
>
> My normal inbox is getting unmanageable, and I think I need to find a new
> way
> of following this and other lists.
>
> Thanks for any suggestions.
>
> Cheers, JB.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

2010-11-03 Thread Daniel Kluev

I use gmail with according filters and labels, so each mailing list has its
own label and is removed from inbox.

-- 
With best regards,
Daniel Kluev
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Man pages and info pages

2010-11-03 Thread Daniel da Silva

Guys, this really has nothing to do with python.

On Wednesday, November 3, 2010, Hrvoje Niksic  wrote:
> Teemu Likonen  writes:
>
>>     Enter   Follow a link (down to node)
>>     u       up node level
>>     h       help (general how-to)
>>     ?       help (commands)
>>     s       search
>
> And don't forget:
>
>       l       last viewed page (aka "back")
>
> That one seems to be the info reader's best-kept secret.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python documentation too difficult for beginners

2010-11-03 Thread Hallvard B Furuseth

Steven D'Aprano writes:
> On Tue, 02 Nov 2010 03:42:22 -0700, jk wrote:
>> The former is difficult to find (try searching for 'open' in the search
>> box and see what you get).
>
> A fair point -- the built-in open comes up as hit #30, whereas searching 
> for open in the PHP page brings up fopen as hit #1. But the PHP search 
> also brings up many, many hits -- ten pages worth.
>
> But in any case, the Python search functionality could be smarter. If I 
> had a complaint about the docs, that would be it. Fortunately, I have 
> google :)

Actually that was one of the hair-tearing attitudes I heard a web search
guru complain about.  The smartest part of the search engine is the
people running it, so why not apply their brains directly?  Read the log
like you did, look for poor results (like "open"), put in exceptions by
hand.  This might be a fraction of the work it takes to program that
kind of smarts into the engine.  Or you might discover a group of
exceptions to put in - like all Python keywords.  That makes it at least
partially programmed, which may be preferable.

-- 
Hallvard
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Man pages and info pages

2010-11-03 Thread rustom

On Nov 3, 3:11 pm, Daniel da Silva  wrote:
> Guys, this really has nothing to do with python.

?? python docs have nothing to do with python??
python docs by default on linux are read with info and many seem to
find info unpleasant to use.

Myself an old emacs user and cant say info helps me as much as google.
However comparing info and man is also a bit strange.  The printed
python docs come to several thousand pages.  Do we want them to be 1
manpage? a hundred? a thousand?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to highlight Label/Text in tkinter ?

2010-11-03 Thread VGNU Linux

I was able to solve the problem. But unable to use Label or Text widget. Any
idea as to why focus does not work with Label or Text widget.
Here is the program using button widget.

from Tkinter import *
import tkFont

class DisplayFrame:
"""
Uses GUI to display contacts
"""
def __init__(self, root):
self.b = Button(root, text="Peter Pan",font=("Arial",10,"bold"),
  anchor=W, justify=LEFT, relief=FLAT)
self.b.pack(fill=BOTH)
self.b.focus_set()

self.b = Button(root, text="Marry Joe", font=("Arial",10,"bold"),
 anchor=W, justify=LEFT, relief=FLAT)
self.b.pack(fill=BOTH)

self.b = Button(root, text="Michael Kin", font=("Arial",10,"bold"),
 anchor=W, justify=LEFT, relief=FLAT)
self.b.pack(fill=BOTH)

self.b = Button(root, text="Jennifer McConelly",
font=("Arial",10,"bold"),
 anchor=W, justify=LEFT, relief=FLAT)
self.b.pack(fill=BOTH)

self.b = Button(root, text="Jonathen Broady",
font=("Arial",10,"bold"),
 anchor=W, justify=LEFT, relief=FLAT)
self.b.pack(fill=BOTH)

def handleReturn(event):
event.widget["font"] = "Arial 16 bold"
print event.widget.focus_get()
nxtwid = event.widget.tk_focusNext()
prewid = event.widget.tk_focusPrev()
prewid["font"] = "Arial 10 bold"
nxtwid.focus_set()

if __name__ == '__main__':
root = Tk()
frame = DisplayFrame(root)
root.bind("",handleReturn)
root.mainloop()

Regards,
VGNU

On Wed, Nov 3, 2010 at 12:02 PM, VGNU Linux  wrote:

> Hi,
> I am writing a program teach myself python and tkinter.
> Below given is a program which displays label with different fonts and
> sizes.
> How to highlight text and change font size if the up/down arrow keys are
> pressed ?
> from Tkinter import *
> import tkFont
>
> class MyFrame(Frame):
>
> def __init__(self, root):
> Frame.__init__(self, root)
> self.txt = Label(self, text="Arial 10 bold",
> font=("Arial",10,"bold"))
> self.txt.grid(row=1,column=1)
> self.txt = Label(self, text="Courier 12 bold",
> font=("Courier",12,"bold"))
> self.txt.grid(row=2,column=1)
> self.txt = Label(self, text="Comic Sans MS 14 bold", font=("Comic
> Sans MS",14,"bold"))
> self.txt.grid(row=3,column=1)
> self.txt = Label(self, text="Fixedsys 16 bold",
> font=("Fixedsys",16,"bold"))
> self.txt.grid(row=4,column=1)
> self.txt = Label(self, text="MS Sans Serif 18 bold", font=("MS Sans
> Serif",18,"bold"))
> self.txt.grid(row=5,column=1)
> self.txt = Label(self, text="MS Serif, Symbol 20 bold", font=("MS
> Serif, Symbol",20,"bold"))
> self.txt.grid(row=6,column=1)
> self.txt = Label(self, text="System 22 bold",
> font=("System",22,"bold"))
> self.txt.grid(row=7,column=1)
> self.txt = Label(self, text="Verdana 24 bold",
> font=("Verdana",24,"bold"))
> self.txt.grid(row=8,column=1)
>
> if __name__ == '__main__':
> root = Tk()
> c = MyFrame(root)
> c.pack(fill=BOTH, expand=1)
> root.mainloop()
>
> any help?
>
> Regards,
> VGNU
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

On Wed, 03 Nov 2010 08:02:29 +, John Bond wrote:

> Hope this isn't too O/T - I was just wondering how people read/send to
> this mailing list, eg. normal email client, gmane, some other software
> or online service?

Usenet via my ISP, on comp.lang.python.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

2010-11-03 Thread Tim Chase


On 11/03/10 03:02, John Bond wrote:

Hope this isn't too O/T - I was just wondering how people read/send to this
mailing list, eg. normal email client, gmane, some other software or online
service?

My normal inbox is getting unmanageable, and I think I need to find a new way
of following this and other lists.


Currently using Gmane NNTP via Thunderbird.  If TB offered the 
ability to kill-thread normal email (the "kill thread" 
functionality only seems to work in newsgroups), I'd stick to 
getting them via email, filtered into my Python folder.


-tkc



--
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

2010-11-03 Thread Cameron Simpson

On 03Nov2010 08:02, John Bond  wrote:
| Hope this isn't too O/T - I was just wondering how people read/send to this 
| mailing list, eg. normal email client, gmane, some other software or online 
| service?
| 
| My normal inbox is getting unmanageable, and I think I need to find a new way 
| of following this and other lists.

I use mutt to read my python folder.

I use getmail to collect email via POP and deliver via procmail, which files
this list (and python-ideas etc) into a "python" folder, out of my main
inbox.
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

It is impossible to travel faster than light, and certainly not desirable as
ones hat keeps blowing off. - Woody Allen
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On Tue, 02 Nov 2010 19:26:56 +, Tim Harig wrote:

> I agree with Seebs, Python is the only language I know that promotes the
> use of spaces over tabs; 

Really? I'm not aware of *any* language that promotes tabs over spaces. I 
thought the tabs vs spaces war was mostly won by spaces over a decade ago 
(apart from a few plucky freedom fighters who will never surrender).

> and there are equally picky syntaxs (ie,
> Makefiles) that mandate the use of tabs.  I personally prefer tabs as it
> lets *me* decide how far the apparent indentations are in the code. You
> may like four spaces; but, I agree with Linus Torvalds that eight spaces
> is much clearer.  The beautiful thing about tabs is that we can both set
> our tab stops to match our own viewing preferences.

Actually I agree with you about tabs. I think tabs are far more logical 
and sensible. But I'm stuck with broken tools that don't deal with tabs, 
and with PEP 8 that mandates the use of spaces, and popular opinion that 
says make is crazy for using tabs.

So, I bite my lip, stop using broken tools that make dealing with space-
indents painful, and just deal with it. And you know what? It's not so 
bad after all.

> This is Python's most noticable blemish outside of the community.
> Everybody knows that Python is the language that forces you to use a
> particular style of formatting; and, that is a turn-off for many people.

Their loss. I don't miss the flame wars over the One True Brace Style. 
There are enough disagreements over coding conventions without adding to 
them.

> It is a big mistake that whenever the issue arises, the community
> effectively attacks anybody who might have disagreements with the
> tradeoffs made for the Python language.  This tends to set people on the
> defensive and gives them a bad taste about the language as a whole.

That's very insightful. Why don't you apply some of that insight to the 
other side? It is *incredibly* annoying to see the same old people making 
the same old snide remarks about the same old issues over and over again, 
particularly when:

* it's not an issue for thousands of other users;
* even if it were an issue, if you use the right tool for the job, the 
issue disappears;
* and even if there is no right tool for the job, the feature isn't going 
to change;
* and even if it would change, the people doing the whinging aren't going 
to volunteer to make the change.

> It would be much better if the community would simply acknowledge that
> this is a tradeoff the the language has made and one which is often
> misunderstood by many first time Python programmers.

Been there, done that. This is *old news*.

-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On Wed, 03 Nov 2010 12:01:06 +1300, Lawrence D'Oliveiro wrote:

> In message , Grant Edwards wrote:

>> Other languages have similar problems if you remove salient bits of
>> syntax before comparing two source files files.
> 
> But other languages don’t make those “salient bits of syntax” invisible.
> I.e. they are actually “salient”.

(1) Indentation is visible. Compare:

This line has leading visible whitespace.

This line has leading invisible characters.

See the difference?

(2) Salient doesn't mean visible. It means "prominent, conspicuous, 
noticeable". Something can be conspicuous by its absence; conspicuous 
whitespacecanbe
verynoticeable.

-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list


On 3/11/2010 11:17 AM, Steven D'Aprano wrote:

On Wed, 03 Nov 2010 08:02:29 +, John Bond wrote:


Hope this isn't too O/T - I was just wondering how people read/send to
this mailing list, eg. normal email client, gmane, some other software
or online service?

Usenet via my ISP, on comp.lang.python.




Using what client (or web client)?

Cheers, JB
--
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

2010-11-03 Thread Paul Rudin

John Bond  writes:

> On 3/11/2010 11:17 AM, Steven D'Aprano wrote:
>> On Wed, 03 Nov 2010 08:02:29 +, John Bond wrote:
>>
>>> Hope this isn't too O/T - I was just wondering how people read/send to
>>> this mailing list, eg. normal email client, gmane, some other software
>>> or online service?
>> Usenet via my ISP, on comp.lang.python.
>>
>>
>>
> Using what client (or web client)?
>

Emacs, of course :-;
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

2010-11-03 Thread tinnews

John Bond  wrote:
> Hope this isn't too O/T - I was just wondering how people read/send to this 
> mailing list, eg. normal email client, gmane, some other software or online 
> service?
> 
> My normal inbox is getting unmanageable, and I think I need to find a new way 
> of following this and other lists.
> 
> Thanks for any suggestions.
> 
I read it as a Usenet newsgroup, far better than as an E-Mail list
IMHO.  Wherever I have a choice (quite a few mailing lists are
'gatewayed' with newsgroups) I choose the newsgroup, newsreaders are
much more able to manage this sort of discussion group.

Alternatively, if you want to stay with the E-Mail format then use
some sort of filtering that will allow you to send each mailing list
to its own folder.  I do this with a home-grown python script but most
E-Mail programs have the ability to do this themselves nowadays.

-- 
Chris Green
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Allowing comments after the line continuation backslash

In article ,
 Lawrence D'Oliveiro  wrote:

> > I suppose readability is in the eye of the reader, but, yes, I agree
> > that I have split this into two parts.  The parts are
> > 
> > 1) The table of data
> > 
> > 2) The looping construct
> 
> But the table of data makes no sense outside of the looping construct. That 
> table does nothing other than define the bounds of the loop.

I look at it the other way around.  The data is the important part, and 
the loop is just plumbing.  Once I've got the data in an easy to manage 
form, I can do lots of things with it.  I could iterate over it (as 
originally written) with a "for" loop.  I could refactor the code to 
pass the data to some function which processes it.  I could refactor it 
a different way and use map() to process the data.

> Which means you donât understand the purpose of the code at all. Go look at 
> it in its entirety, and youâll see what I mean.
> 
> 

That URL takes me to a github page.  Can you be more specific about 
which file I should be looking at?  I did take a look at one file, 
overscan_margins.py.  Here's a few stylistic comments.

1) I like the fact that the file starts out with a block comment 
describing what it does, how to install it, and how to run it.  
Documentation is A Good Thing, and most people don't do enough of it.

2) You have provided comments for each function, such as (lines 36-37):

def NewLayer(svg, LayerName) :
# adds a new layer to the SVG document and returns it.

This is good, but would be even more useful if it were turned into a 
docstring, such as:

def NewLayer(svg, LayerName) :
"adds a new layer to the SVG document and returns it."

For the same amount of typing, you now have a piece of text which can be 
retrieved by help() and processed in various useful ways with other 
tools.

3) I find the deeply nested style you use very difficult to read.  For 
example, on lines 80-103.  As I read this, here's how I mentally process 
it:

"OK, here's a function call (minor stumble over the open paren not being 
on the same line as the function name, but I can get past that).  The 
first argument is TheLayer.  The second argument is whatever 
inkex.addNS() returns.  Umm..."

At that point, I can't scan quickly any more.  It took me a while to 
understand that the third argument was a dictionary.  The nesting is 
just too deep for me to continue to mentally hold the context of "I'm 
looking at a function call and gathering up the arguments" while I drill 
down through the dictionary structure to understand what it is.

This would be a lot easier to scan if it were written as:

inkex.etree.SubElement(TheLayer,
   inkex.addNS("path", "svg"),
   stuff)

where "stuff" is the big complicated dictionary, which is defined before 
the call.  Of course, "stuff" is not a useful name for it, but not being 
familiar with the domain, I don't know what a useful name would be.

Hmmm, googling for inkex.etree.SubElement found me some Inkscape 
documentation.  Looks like "attribs" would be a good name for the 
dictionary, since that's the name they use in the docs.  In fact, if you 
look at http://tinyurl.com/24wa3q8, you'll see they use exactly the 
style I describe above (modulo whitespace).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

2010-11-03 Thread Adam Tauno Williams

On Wed, 2010-11-03 at 11:17 +, Steven D'Aprano wrote: 
> On Wed, 03 Nov 2010 08:02:29 +, John Bond wrote:
> > Hope this isn't too O/T - I was just wondering how people read/send to
> > this mailing list, eg. normal email client, gmane, some other software
> > or online service?

GNOME's awesome Evolution mail (IMAP) client.

Via a SIEVE script on a Cyrus IMAP server the mailist traffic is
automatically placed in a folder.  Then it can be read with any IMAP
traffic.  Delete the silly traffic and that folder becomes an invaluable
resource of useful information [no wading through pages and pages of
search-result-swill].

-- 
Adam Tauno Williams  LPIC-1, Novell CLA

OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

In article ,
 John Bond  wrote:

> Hope this isn't too O/T - I was just wondering how people read/send to this 
> mailing list, eg. normal email client, gmane, some other software or online 
> service?

Usenet group comp.lang.python.  Most of the time, using MT-NewsWatcher 
on my Mac.  Occasionally via the Google Groups web interface.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Allowing comments after the line continuation backslash

2010-11-03 Thread Neil Cerutti

On 2010-11-03, Ben Finney  wrote:
> I would do the same, but fix the indentation. Making
> indentation depend on the *length* of the previous line is
> needlessly making a maintenance burden.
>
> Instead, I'd do::
>
> styles = [
> ("normal",  "image", MainWindow.ColorsNormalList),
> ("highlighted", "highlight", MainWindow.ColorsHighlightedList),
> ("selected","select",MainWindow.ColorsSelectedList)]

Agreed, except cute stuff like putting those three items in
columns is just as bad.

Code should be utilitarian rather than ornate, Shaker rather than
Victorian.

-- 
Neil Cerutti
-- 
http://mail.python.org/mailman/listinfo/python-list

Subclassing unittest.TestCase?

I'm using Python 2.6, with unittest2 imported as unittest.

I'm writing a test suite for a web application.  There is a subclass of 
TestCase for each basic page type.  One thing that's in common between 
all the pages is that every page must have a valid copyright notice.  It 
seems like the logical thing would be to put the common test(s) in a 
subclass unittest.TestCase and have all my real test cases derive from 
that:

class CommonTestCase(unittest.TestCase):
   def test_copyright(self):
  self.assert_(find copyright notice in DOM tree)

class HomepageTestCase(CommonTestCase):
   def setUp(self):
  self.url = "http://site.com";

   def test_whatever(self):
  self.assert_(whatever)

This works fine as far as HomepageTestCase running test_copyright() and 
test_whatever().  The problem is that CommonTestCase *also* runs 
test_copyright(), which fails because there's no setUp(), and thus no 
retrieved page for it to work on.

The hack that I came up with is:

class CommonTestCase(unittest.TestCase):
   def test_copyright(self):
  if self.__class__.__name__ == 'CommonTestCase':
 return
  self.assert_(find copyright notice in DOM tree)

which works, but it's ugly.  It also counts 
CommonTestCase.test_copyright() as passing, which messes up the 
statistics.  Is there a cleaner way to define some common test methods 
which all of my test cases can inherit, without having them be run in 
the base class?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ways of accessing this mailing list?

On 2010-11-02, John Bond  wrote:
> Hope this isn't too O/T - I was just wondering how people read/send to 
> this mailing list, eg. normal email client, gmane, some other software 
> or online service?
>
> My normal inbox is getting unmanageable, and I think I need to find a 
> new way of following this and other lists.

Point an NNTP client at new.gmane.org.

This "list" is also a Usenet newsgroup (comp.lang.python), and there
are a number of cheap/low-cost text-only Usenet providers.

-- 
Grant Edwards   grant.b.edwardsYow! ... or were you
  at   driving the PONTIAC that
  gmail.comHONKED at me in MIAMI last
   Tuesday?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On 2010-11-03, D'Arcy J.M. Cain  wrote:
> On 03 Nov 2010 01:20:40 GMT
> Seebs  wrote:
>> However, I have probably seen all of two or three bugs ever related to
>> mis-indented C, and I've had various things screw up or wreck indentation
>
> Really?  I have never seen bugs in C related to indentation.  I have
> seen plenty related to braces.

Same here.

> What I have seen is bugs hidden by the indentation not matching the
> block structure.  Wrong indentation in Python *is* a bug.  There's no
> other visual signal to hide the error.

Exactly.

-- 
Grant Edwards   grant.b.edwardsYow! I selected E5 ... but
  at   I didn't hear "Sam the Sham
  gmail.comand the Pharoahs"!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On 2010-11-03, Seebs  wrote:
> On 2010-11-02, Grant Edwards  wrote:
>> Huh? Indentation is invisible?  You can't see the indentation in
>> Python source code?
>
> The difference between tabs and spaces is invisible on a great
> number of the devices on which people display code.

Allowing a mixture of tabs/spaces for indentation was a mistake, and
pretty much everybody agrees on that.  However, that isn't what's
being discussed.

> Indentation is visible, but the underlying structure of it may not
> be.  (It's worse than that, because for instance " " is quite hard to
> distinguish from the quite similar " ".) And at least one of them is
> clearly wrong.

-- 
Grant Edwards   grant.b.edwardsYow! An air of FRENCH FRIES
  at   permeates my nostrils!!
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

On 2010-11-03, Paul Rudin  wrote:
> John Bond  writes:
>
>> On 3/11/2010 11:17 AM, Steven D'Aprano wrote:
>>> On Wed, 03 Nov 2010 08:02:29 +, John Bond wrote:
>>>
 Hope this isn't too O/T - I was just wondering how people read/send to
 this mailing list, eg. normal email client, gmane, some other software
 or online service?
>>> Usenet via my ISP, on comp.lang.python.
>>>
>> Using what client (or web client)?
>
> Emacs, of course :-;

Slrn, of course.

-- 
Grant Edwards   grant.b.edwardsYow! I am having FUN...
  at   I wonder if it's NET FUN or
  gmail.comGROSS FUN?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py3: Import relative path module

2010-11-03 Thread Gnarlodious

On Nov 3, 2:51 am, Peter Otten wrote:

> Slightly generalized: have the importing module print its __name__. There
> has to be at least one dot in the name for
>
> from .. import whatever
>
> to succeed.

Just spent about 3 hours trying every permutation I could think of,
and searching Google for exactly how to do it, but all I get is:

ValueError: Attempted relative import in non-package

How do I import a module so that a dot will appear in its name?

-- Gnarlie
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py3: Import relative path module

Gnarlodious wrote:

> On Nov 3, 2:51 am, Peter Otten wrote:
> 
>> Slightly generalized: have the importing module print its __name__. There
>> has to be at least one dot in the name for
>>
>> from .. import whatever
>>
>> to succeed.
> 
> Just spent about 3 hours trying every permutation I could think of,
> and searching Google for exactly how to do it, but all I get is:
> 
> ValueError: Attempted relative import in non-package
> 
> How do I import a module so that a dot will appear in its name?

Make sure the no path in sys.path leads into a directory that contains an 
__init__.py. In particular, ensure that you aren't invoking the python 
interpreter from a working directory that contains an __init__.py and that 
the main script is in a directory that doesn't contain an __init__.py.

Peter
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

2010-11-03 Thread Dan M

On Wed, 03 Nov 2010 08:02:29 +, John Bond wrote:

> Hope this isn't too O/T - I was just wondering how people read/send to
> this mailing list, eg. normal email client, gmane, some other software
> or online service?
> 
> My normal inbox is getting unmanageable, and I think I need to find a
> new way of following this and other lists.
> 
> Thanks for any suggestions.
> 
> Cheers, JB.

Pan newsreader

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py3: Import relative path module

Peter Otten wrote:

> Gnarlodious wrote:
> 
>> On Nov 3, 2:51 am, Peter Otten wrote:
>> 
>>> Slightly generalized: have the importing module print its __name__.
>>> There has to be at least one dot in the name for
>>>
>>> from .. import whatever
>>>
>>> to succeed.
>> 
>> Just spent about 3 hours trying every permutation I could think of,
>> and searching Google for exactly how to do it, but all I get is:
>> 
>> ValueError: Attempted relative import in non-package
>> 
>> How do I import a module so that a dot will appear in its name?
> 
> Make sure the no path in sys.path leads into a directory that contains an
> __init__.py. In particular, ensure that you aren't invoking the python
> interpreter from a working directory that contains an __init__.py and that
> the main script is in a directory that doesn't contain an __init__.py.
> 
> Peter

Here's a working example that you can use as a starting point:

$ tree
.
|-- alpha
|   |-- __init__.py
|   |-- beta
|   |   |-- __init__.py
|   |   `-- one.py
|   `-- two.py
`-- main.py

2 directories, 5 files
$ cat main.py
import alpha.beta.one
$ cat alpha/beta/one.py
from ..alpha import two
$ cat alpha/two.py
print "success!"
$ python main.py
success!

Peter
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

2010-11-03 Thread QoS


Dan M  wrote in message-id:  


> 
> On Wed, 03 Nov 2010 08:02:29 +, John Bond wrote:
> 
> > Hope this isn't too O/T - I was just wondering how people read/send to
> > this mailing list, eg. normal email client, gmane, some other software
> > or online service?
> > 
> > My normal inbox is getting unmanageable, and I think I need to find a
> > new way of following this and other lists.
> > 
> > Thanks for any suggestions.
> > 
> > Cheers, JB.
> 
> Pan newsreader

Using Perl and NewsSurfer to read this newsgroup (check headers).

Thanks,
J

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py3: Import relative path module

Peter Otten wrote:

> Peter Otten wrote:
> 
>> Gnarlodious wrote:
>> 
>>> On Nov 3, 2:51 am, Peter Otten wrote:
>>> 
 Slightly generalized: have the importing module print its __name__.
 There has to be at least one dot in the name for

 from .. import whatever

 to succeed.
>>> 
>>> Just spent about 3 hours trying every permutation I could think of,
>>> and searching Google for exactly how to do it, but all I get is:
>>> 
>>> ValueError: Attempted relative import in non-package
>>> 
>>> How do I import a module so that a dot will appear in its name?
>> 
>> Make sure the no path in sys.path leads into a directory that contains an
>> __init__.py. In particular, ensure that you aren't invoking the python
>> interpreter from a working directory that contains an __init__.py and
>> that the main script is in a directory that doesn't contain an
>> __init__.py.
>> 
>> Peter
> 
> Here's a working example that you can use as a starting point:
> 
> $ tree
> .
> |-- alpha
> |   |-- __init__.py
> |   |-- beta
> |   |   |-- __init__.py
> |   |   `-- one.py
> |   `-- two.py
> `-- main.py
> 
> 2 directories, 5 files
> $ cat main.py
> import alpha.beta.one
> $ cat alpha/beta/one.py
> from ..alpha import two
> $ cat alpha/two.py
> print "success!"
> $ python main.py
> success!

Hmm, now I'm puzzled myself. 

> $ cat alpha/beta/one.py
> from ..alpha import two

That line should have been

from .. import two

For some reason (bug?) it seems to work with and without the extra alpha.

Peter
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Learning book recommendation?

2010-11-03 Thread Felipe Bastos Nunes

The pyschools dot com have so many exercises that 'forces' you to
learn. It shows some results, explains the algorithm and checks the
results of your code.

2010/11/2, brf...@gmail.com :
> Hey there,
>
> I would reccomend a non-programmers tutorial to python by Josh coglatti and
> its a free wiki book. Also I would recommend byte into python. Both are
> great for beginers. Best of luck!
>
> -- Braden Faulkner
> Sent wirelessly from my BlackBerry device on the Bell network.
> Envoyé sans fil par mon terminal mobile BlackBerry sur le réseau de Bell.
> --
> http://mail.python.org/mailman/listinfo/python-list
>


-- 
Felipe Bastos Nunes
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Subclassing unittest.TestCase?

Roy Smith wrote:

> I'm using Python 2.6, with unittest2 imported as unittest.
> 
> I'm writing a test suite for a web application.  There is a subclass of
> TestCase for each basic page type.  One thing that's in common between
> all the pages is that every page must have a valid copyright notice.  It
> seems like the logical thing would be to put the common test(s) in a
> subclass unittest.TestCase and have all my real test cases derive from
> that:
> 
> class CommonTestCase(unittest.TestCase):
>def test_copyright(self):
>   self.assert_(find copyright notice in DOM tree)
> 
> class HomepageTestCase(CommonTestCase):
>def setUp(self):
>   self.url = "http://site.com";
> 
>def test_whatever(self):
>   self.assert_(whatever)
> 
> This works fine as far as HomepageTestCase running test_copyright() and
> test_whatever().  The problem is that CommonTestCase *also* runs
> test_copyright(), which fails because there's no setUp(), and thus no
> retrieved page for it to work on.
> 
> The hack that I came up with is:
> 
> class CommonTestCase(unittest.TestCase):
>def test_copyright(self):
>   if self.__class__.__name__ == 'CommonTestCase':
>  return
>   self.assert_(find copyright notice in DOM tree)
> 
> which works, but it's ugly.  It also counts
> CommonTestCase.test_copyright() as passing, which messes up the
> statistics.  Is there a cleaner way to define some common test methods
> which all of my test cases can inherit, without having them be run in
> the base class?

Remove the base class from the module with

del CommonTestCase

before you invoke unittest.main().

Peter
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: problem with opening a new python program in a new window (and keeping track of the process)

2010-11-03 Thread Tim Golden


On 02/11/2010 20:55, Zak Kinion wrote:

What I want to do:  launch seperate python programs from one main
program (multi-threading will not achieve this because the mechanize
library uses one shared global opener object which will not suit my
needs)  I want the scripts launched to be in seperate windows that i
can see the output of on screen, seperate processes.  I can accomplish
this in win32 by:

import subprocess;
args = ["cmd", "/c", "START", "python", "myScript.py"];
process1 = subprocess.Popen(args, shell=False);


Pass CREATE_NEW_CONSOLE as one of the creationflags:


import os, sys
import subprocess

processes = []
cmd = [sys.executable, "-c", "import os; print os.getpid (); raw_input ()"]
for i in range (3):
  processes.append (subprocess.Popen (cmd, 
creationflags=subprocess.CREATE_NEW_CONSOLE))


#
# Keep looping round to see the current status
#
while True:
  for p in processes:
print p.poll ()

  raw_input ()



TJG
--
http://mail.python.org/mailman/listinfo/python-list

Re: functions, list, default parameters

2010-11-03 Thread Bruno Desthuilliers


Lawrence D'Oliveiro a écrit :
In message <20101021235138.609fe...@geekmail.invalid>, Andreas Waldenburger 
wrote:



While not very commonly needed, why should a shared default argument be
forbidden?


Because it’s safer to disallow it than to allow it.


Then there are quite a few python features (or misfeatures depending on 
your personal tastes and whatnot) that should be "disabled" too. What 
about rebinding some_object.__class__ ?-)


--
http://mail.python.org/mailman/listinfo/python-list

Serializing a user-defined class

2010-11-03 Thread T.J. Simmons

Hi all, got a question regarding serializing classes that I've defined. I
have some classes like

class Foo:
 def __init__(self, x, y):
  self.x = x, self.y = y

then a class that can contain multiple Foos, such as:

class Bar:
 def __init__(self):
  self.foos = [Foo(a, b), Foo(1, 2)]


While that's a gross oversimplification of the real structure (it gets much,
much more nested than that), that's a pretty decent overview. The actual
data for this is coming from a pseudo-XML file without any actual structure,
so I wrote a parser according to the spec given to me, so I now have all the
data in a series of classes I've defined, with actual structure.

What I'm wanting to do is take this data I have and spit it out into JSON,
but I really don't see a good way (I'm new to Python, this is my first real
project with it).

I've defined a method in Foo, such as:

def toDict(self):
 return dict(x = self.x, y = self.y)

but that obviously isn't going to work out like I hope when I try to
serialize Bar, with the multiple Foos.

Does anyone have a great way of doing this? This has been a pretty much
non-stop learning/codefest the past few days and I'm out of ideas for this,
which is the last part of the project.

Let me know if I can clarify in any way.

Thanks,
T.J.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Serializing a user-defined class

On Wed, Nov 3, 2010 at 8:30 AM, T.J. Simmons  wrote:
> Hi all, got a question regarding serializing classes that I've defined. I
> have some classes like
> class Foo:
>      def __init__(self, x, y):
>           self.x = x, self.y = y
> then a class that can contain multiple Foos, such as:
> class Bar:
>      def __init__(self):
>           self.foos = [Foo(a, b), Foo(1, 2)]
>
> While that's a gross oversimplification of the real structure (it gets much,
> much more nested than that), that's a pretty decent overview. The actual
> data for this is coming from a pseudo-XML file without any actual structure,
> so I wrote a parser according to the spec given to me, so I now have all the
> data in a series of classes I've defined, with actual structure.
> What I'm wanting to do is take this data I have and spit it out into JSON,
> but I really don't see a good way (I'm new to Python, this is my first real
> project with it).

Did you google for "python json"? The std lib `json` module is the
very first hit:
http://docs.python.org/library/json.html

For future reference, here's the Global Module Index:
http://docs.python.org/modindex.html

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

2010-11-03 Thread D'Arcy J.M. Cain

On Wed, 3 Nov 2010 08:02:29 + (UTC)
John Bond  wrote:
> Hope this isn't too O/T - I was just wondering how people read/send to this 

It is completely off topic.  What you need to do is research your own
email client to see how to filter mailing lists into their own
folders.  Failing that look for a forum dedicated to your email
client.  There is nothing specific about Python in this regard.

-- 
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list


On 3/11/2010 3:38 PM, D'Arcy J.M. Cain wrote:

On Wed, 3 Nov 2010 08:02:29 + (UTC)
John Bond  wrote:

Hope this isn't too O/T - I was just wondering how people read/send to this

It is completely off topic.  What you need to do is research your own
email client to see how to filter mailing lists into their own
folders.  Failing that look for a forum dedicated to your email
client.  There is nothing specific about Python in this regard.



I know how to do that, thanks, but I was looking at broader options.

Apologies to anyone whose time has been wasted by this heinous request, 
and thanks to those who have responded and given me ideas. I hope 
they'll help me better contribute to this (Python) list.


Cheers, JB
--
http://mail.python.org/mailman/listinfo/python-list

Re: Py3: decode subprocess output

2010-11-03 Thread Gnarlodious

OK, it turns out I had to tweak the parsing minimally for Python3:

1) Substrings such as st[5] no longer work (returns an ascii number),
instead st[5:6] selects one character

2) Replacements need to specified as bytes: s.replace('R','*') change
to s.replace(b'R',b'*')

So I think this problem is solved.

-- Gnarlie
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Serializing a user-defined class


On 3/11/2010 3:30 PM, T.J. Simmons wrote:
Hi all, got a question regarding serializing classes that I've 
defined. I have some classes like


class Foo:
 def __init__(self, x, y):
  self.x = x, self.y = y

then a class that can contain multiple Foos, such as:

class Bar:
 def __init__(self):
  self.foos = [Foo(a, b), Foo(1, 2)]


While that's a gross oversimplification of the real structure (it gets 
much, much more nested than that), that's a pretty decent overview. 
The actual data for this is coming from a pseudo-XML file without any 
actual structure, so I wrote a parser according to the spec given to 
me, so I now have all the data in a series of classes I've defined, 
with actual structure.


What I'm wanting to do is take this data I have and spit it out into 
JSON, but I really don't see a good way (I'm new to Python, this is my 
first real project with it).


I've defined a method in Foo, such as:

def toDict(self):
 return dict(x = self.x, y = self.y)

but that obviously isn't going to work out like I hope when I try to 
serialize Bar, with the multiple Foos.


Does anyone have a great way of doing this? This has been a pretty 
much non-stop learning/codefest the past few days and I'm out of ideas 
for this, which is the last part of the project.


Let me know if I can clarify in any way.

Thanks,
T.J.


Python has a JSON lib that may be what you want, alternatively you could 
have a common base class with a method that iterates through its own 
member variables (see dir() function) as key/value pairs, recursing when 
it finds further instances of that base class (see isinstance() 
function). That would let you iterate through all member variables in 
the object hierarchy from the top level object, and do what you wish 
with them. I'm sure there are other ways too.


Cheers, JB

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

2010-11-03 Thread D'Arcy J.M. Cain

On Wed, 03 Nov 2010 15:53:41 +
John Bond  wrote:
> > It is completely off topic.  What you need to do is research your own
> > email client to see how to filter mailing lists into their own
> > folders.  Failing that look for a forum dedicated to your email
> > client.  There is nothing specific about Python in this regard.
> 
> I know how to do that, thanks, but I was looking at broader options.

Well, still off-topic but the question could have been put better.  If
you knew how to do that you should have mentioned it and explained why
it wasn't suitable for your needs.  You would have got a more focussed
response.  This applies to asking any questions here or elsewhere.  The
more information you provide in your question, the more relevant the
responses will be.

By the way, I am seeing two copies of every message from you.  How are
you posting?

-- 
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Serializing a user-defined class

> On Wed, Nov 3, 2010 at 10:35 AM, Chris Rebert  wrote:
>> On Wed, Nov 3, 2010 at 8:30 AM, T.J. Simmons 
>> wrote:
>> > Hi all, got a question regarding serializing classes that I've defined.
>> > I
>> > have some classes like
>> > class Foo:
>> >      def __init__(self, x, y):
>> >           self.x = x, self.y = y
>> > then a class that can contain multiple Foos, such as:
>> > class Bar:
>> >      def __init__(self):
>> >           self.foos = [Foo(a, b), Foo(1, 2)]
>> >
>> > While that's a gross oversimplification of the real structure (it gets
>> > much,
>> > much more nested than that), that's a pretty decent overview. The actual
>> > data for this is coming from a pseudo-XML file without any actual
>> > structure,
>> > so I wrote a parser according to the spec given to me, so I now have all
>> > the
>> > data in a series of classes I've defined, with actual structure.
>> > What I'm wanting to do is take this data I have and spit it out into
>> > JSON,
>> > but I really don't see a good way (I'm new to Python, this is my first
>> > real
>> > project with it).
>>
>> Did you google for "python json"? The std lib `json` module is the
>> very first hit:
>> http://docs.python.org/library/json.html

On Wed, Nov 3, 2010 at 8:39 AM, T.J. Simmons  wrote:
> Right, I know about the json module; that's not the problem. My problem is
> with the fact that different instances of the same class, with different
> data, have the same keys. Foo, in this instance, can be both a list of Foos
> inside Bar, and also a list of Foos outside Bar. I'm just unsure of how to
> get the data into a serializable form.

So, if I'm understanding you correctly, your classes make use of
dynamic typing and you think this will cause serialization problems?
In that case, just define an appropriate JSONEncoder or object_hook;
see the module docs, they give an example for complex numbers.
If I've misunderstood you, a specific (pseudo-)code example of your
problem would be helpful.

Cheers,
Chris
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

2010-11-03 Thread Jed Smith

On Wed, Nov 3, 2010 at 4:02 AM, John Bond  wrote:
> My normal inbox is getting unmanageable, and I think I need to find a new way
> of following this and other lists.

I have to second (or third) the Gmail suggestion. I use Google Apps
against my domain, and the Gmail interface is frightfully good at
creating filters. For example, on most lists (particularly Mailman), I
can hit "Filter messages like this", and Gmail automatically harvests
the List header and writes a filter for it.

I just prefer the Gmail philosophy to mail, with tags that are *like*
folders but not really.

-- 
Jed Smith
j...@jedsmith.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Tkinter/ttk compatibility with Citrix/WTS (Windows Terminal Services)?

2010-11-03 Thread python

Anyone have any experience using Python Tkinter/ttk applications
with Citrix or WTS (Windows Terminal Services)?
Any concerns, gotchas, or workarounds we should be aware of?
I googled this topic [1], [2] and came up with nothing. No news
is good news ... but just checking to make sure.
Thanks,
Malcolm
[1] tkinter (citrix | ts|terminal services)
[2] tcl (citrix | ts|terminal services)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Serializing a user-defined class

> On Wed, Nov 3, 2010 at 11:18 AM, Chris Rebert  wrote:
>> > On Wed, Nov 3, 2010 at 10:35 AM, Chris Rebert  wrote:
>> >> On Wed, Nov 3, 2010 at 8:30 AM, T.J. Simmons 
>> >> wrote:
>> >> > Hi all, got a question regarding serializing classes that I've
>> >> > defined.
>> >> > I
>> >> > have some classes like
>> >> > class Foo:
>> >> >      def __init__(self, x, y):
>> >> >           self.x = x, self.y = y
>> >> > then a class that can contain multiple Foos, such as:
>> >> > class Bar:
>> >> >      def __init__(self):
>> >> >           self.foos = [Foo(a, b), Foo(1, 2)]
>> >> >
>> >> > While that's a gross oversimplification of the real structure (it
>> >> > gets
>> >> > much,
>> >> > much more nested than that), that's a pretty decent overview. The
>> >> > actual
>> >> > data for this is coming from a pseudo-XML file without any actual
>> >> > structure,
>> >> > so I wrote a parser according to the spec given to me, so I now have
>> >> > all
>> >> > the
>> >> > data in a series of classes I've defined, with actual structure.
>> >> > What I'm wanting to do is take this data I have and spit it out into
>> >> > JSON,
>> >> > but I really don't see a good way (I'm new to Python, this is my
>> >> > first
>> >> > real
>> >> > project with it).
>> >>
>> >> Did you google for "python json"? The std lib `json` module is the
>> >> very first hit:
>> >> http://docs.python.org/library/json.html
>>
>> On Wed, Nov 3, 2010 at 8:39 AM, T.J. Simmons 
>> wrote:
>> > Right, I know about the json module; that's not the problem. My problem
>> > is
>> > with the fact that different instances of the same class, with different
>> > data, have the same keys. Foo, in this instance, can be both a list of
>> > Foos
>> > inside Bar, and also a list of Foos outside Bar. I'm just unsure of how
>> > to
>> > get the data into a serializable form.
>>
>> So, if I'm understanding you correctly, your classes make use of
>> dynamic typing and you think this will cause serialization problems?
>> In that case, just define an appropriate JSONEncoder or object_hook;
>> see the module docs, they give an example for complex numbers.
>> If I've misunderstood you, a specific (pseudo-)code example of your
>> problem would be helpful.

On Wed, Nov 3, 2010 at 9:26 AM, T.J. Simmons  wrote:
> The issue with serialization is how I'm giving the data back to the
> serializer, since I'm using dicts. Multiple dictionaries with a key of Foo
> will overwrite each other, which isn't my desired behavior.

Eh? There should be no key collision. The *outer attribute's* name
(e.g. "foos") should be the key, not the value's type's name (e.g.
"Foo"). The type information for an object should go inside that
object's own dict. Again, see the example for `complex` in the json
module docs.

Also, avoid top-posting in the future.

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Serializing a user-defined class

2010-11-03 Thread T.J. Simmons

The way it actually is now, there will be key collision in the dictionaries
because each Foo has the same keys. I'm about to dive into the json docs for
how it's done on complex, because that seems to be pretty much what I'm
looking for.

And I was about to ask what top-posting was, but then I realized I wasn't
sending this back to the list. So I'm going to assume what that was.

Thanks.

On Wed, Nov 3, 2010 at 11:42 AM, Chris Rebert  wrote:

> > On Wed, Nov 3, 2010 at 11:18 AM, Chris Rebert  wrote:
> >> > On Wed, Nov 3, 2010 at 10:35 AM, Chris Rebert 
> wrote:
> >> >> On Wed, Nov 3, 2010 at 8:30 AM, T.J. Simmons <
> theimmortal...@gmail.com>
> >> >> wrote:
> >> >> > Hi all, got a question regarding serializing classes that I've
> >> >> > defined.
> >> >> > I
> >> >> > have some classes like
> >> >> > class Foo:
> >> >> >  def __init__(self, x, y):
> >> >> >   self.x = x, self.y = y
> >> >> > then a class that can contain multiple Foos, such as:
> >> >> > class Bar:
> >> >> >  def __init__(self):
> >> >> >   self.foos = [Foo(a, b), Foo(1, 2)]
> >> >> >
> >> >> > While that's a gross oversimplification of the real structure (it
> >> >> > gets
> >> >> > much,
> >> >> > much more nested than that), that's a pretty decent overview. The
> >> >> > actual
> >> >> > data for this is coming from a pseudo-XML file without any actual
> >> >> > structure,
> >> >> > so I wrote a parser according to the spec given to me, so I now
> have
> >> >> > all
> >> >> > the
> >> >> > data in a series of classes I've defined, with actual structure.
> >> >> > What I'm wanting to do is take this data I have and spit it out
> into
> >> >> > JSON,
> >> >> > but I really don't see a good way (I'm new to Python, this is my
> >> >> > first
> >> >> > real
> >> >> > project with it).
> >> >>
> >> >> Did you google for "python json"? The std lib `json` module is the
> >> >> very first hit:
> >> >> http://docs.python.org/library/json.html
> >>
> >> On Wed, Nov 3, 2010 at 8:39 AM, T.J. Simmons 
> >> wrote:
> >> > Right, I know about the json module; that's not the problem. My
> problem
> >> > is
> >> > with the fact that different instances of the same class, with
> different
> >> > data, have the same keys. Foo, in this instance, can be both a list of
> >> > Foos
> >> > inside Bar, and also a list of Foos outside Bar. I'm just unsure of
> how
> >> > to
> >> > get the data into a serializable form.
> >>
> >> So, if I'm understanding you correctly, your classes make use of
> >> dynamic typing and you think this will cause serialization problems?
> >> In that case, just define an appropriate JSONEncoder or object_hook;
> >> see the module docs, they give an example for complex numbers.
> >> If I've misunderstood you, a specific (pseudo-)code example of your
> >> problem would be helpful.
>
> On Wed, Nov 3, 2010 at 9:26 AM, T.J. Simmons 
> wrote:
> > The issue with serialization is how I'm giving the data back to the
> > serializer, since I'm using dicts. Multiple dictionaries with a key of
> Foo
> > will overwrite each other, which isn't my desired behavior.
>
> Eh? There should be no key collision. The *outer attribute's* name
> (e.g. "foos") should be the key, not the value's type's name (e.g.
> "Foo"). The type information for an object should go inside that
> object's own dict. Again, see the example for `complex` in the json
> module docs.
>
> Also, avoid top-posting in the future.
>
> Cheers,
> Chris
> --
> http://blog.rebertia.com
>
-- 
http://mail.python.org/mailman/listinfo/python-list

imaplib Search for Messages by Time

2010-11-03 Thread bw

Hello everyone.

I've been writing a program that interfaces with a user's GMail
account using OAuth, and I'm trying to find a way to search for
messages that were received only after a certain date AND time.

It seems pretty easy to get messages after a certain date.  Here's the
relevant code that I have now, which works:

...
imap_conn = imaplib.IMAP4_SSL(imap_hostname)
imap_conn.authenticate('XOAUTH', lambda x: xoauth_string)
imap_conn.select('INBOX')
(typ, data) = imap_conn.search(None, '(SINCE "01-Nov-2010")')
...

But ideally I'd be able to do something like '(SINCE "01-Nov-2010
10:00:00")'.

I know that I can do this locally, but time is a critical factor here
so I'd like to avoid downloading any messages that I don't need.
Thanks!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Serializing a user-defined class

On Wed, Nov 3, 2010 at 9:48 AM, T.J. Simmons  wrote:

> And I was about to ask what top-posting was, but then I realized I wasn't
> sending this back to the list. So I'm going to assume what that was.

Nope, actually it's about placing your reply below the quoted message
you're replying to. (See Wikipedia's "Posting style" article)
Though yes, you should also generally Reply-All on a mailinglist.

Cheers,
Chris
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Must be a bug in the re module [was: Why this result with the re module]

2010-11-03 Thread MRAB


On 03/11/2010 04:10, John Bond wrote:

On 3/11/2010 4:02 AM, MRAB wrote:

On 03/11/2010 03:42, Yingjie Lan wrote:

Matches an empty string, returns ''

The result is therefore ['Mar', '', '', 'lam', '', '']


Thanks, now I see it through with clarity.
Both you and JB are right about this case.
However, what if the regex is ((.a.)*)* ?


Actually, in hindsight, my explanation is slightly wrong!

re.search and the others return None for an unmatched group, but
re.findall returns '' for an unmatched group, so instead of saying:

Matches an empty string, returns ''

I should have said:

The group doesn't match at all, so .findall returns ''

As for "((.a.)*)*", the inner group and repeat match like before, but
then the outer repeat and group try again.

The inner group can't match again, so it's unchanged (and it still
remembers the last successful capture), and the outer group therefore
matches an empty string.

Therefore the outer (first) group is always an empty string and the
inner (second) group is the same as the previous example (the last
capture or '' if no capture).


Now I'm confused - how can something with "zero or more occurrences" not
match?


Perhaps I just phrased it badly.

Given a regex like "(.a.)*", the group might not match, but the regex
itself will.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Must be a bug in the re module [was: Why this result with the re module]

2010-11-03 Thread MRAB


On 03/11/2010 06:32, Yingjie Lan wrote:

--- On Wed, 11/3/10, John Bond  wrote:

I just explained that (I think!)! The outer capturing group
uses
repetition, so it returns the last thing that was matched
by the inner
group, which was an empty string.


According to yourself, the last match of the
inner group is also empty!

Generally speaking,
as a match for the outer group always
contains some matches for the inner group,
it must be the case that the last match
for the inner group must be contained
inside the last match of the outer group.
So if the last match of the
outer group is empty, then the last
match for the inner group must
also be empty.


[snip]
The outer group is repeated, so it can match again, but the inner group
can't match again because it captured all it could the previous time.

Therefore the outer group matches and captures an empty string and the
inner group remembers its last capture.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Man pages and info pages

2010-11-03 Thread Jason Earl

On Wed, Nov 03 2010, rustom wrote:

> On Nov 3, 3:11 pm, Daniel da Silva  wrote:
>> Guys, this really has nothing to do with python.
>
> ?? python docs have nothing to do with python??  python docs by
> default on linux are read with info and many seem to find info
> unpleasant to use.

Actually, the Python documentation is no longer available in info
format.  Which is unfortunate, as that was the documentation format that
I personally preferred.

> Myself an old emacs user and cant say info helps me as much as google.
> However comparing info and man is also a bit strange.  The printed
> python docs come to several thousand pages.  Do we want them to be 1
> manpage? a hundred? a thousand?

I am pretty conversant with the Python documentation.  I almost never
need to search them.  I do miss being able to read (and search) the
documentation in my editor though.

Jason
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

2010-11-03 Thread Wolfgang Strobl

John Bond :

>Hope this isn't too O/T - I was just wondering how people read/send to this 
>mailing list, eg. normal email client, gmane, some other software or online 
>service?

I'm reading comp.lang.python on usenet, using Forté Agent as a
newsreader, which connects via nntp to a locally managed leafnode, which
in turn is fed by http://news.individual.net/ (for most newsgroups) and
http://news.gmane.org/ (for some mailing lists which are only available
there). I usually try to avoid reading mailing lists as mail.

>My normal inbox is getting unmanageable, and I think I need to find a new way 
>of following this and other lists.

Another way to regain control is to use separate mail adresses for
different purposes. I'm adding another alias for a new subscription or a
new registration email adress each time I subscribe to something. 


-- 
Thank you for observing all safety precautions
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On 2010-11-03, Steven D'Aprano  wrote:
> On Tue, 02 Nov 2010 19:26:56 +, Tim Harig wrote:
>
>> I agree with Seebs, Python is the only language I know that promotes the
>> use of spaces over tabs; 
>
> Really? I'm not aware of *any* language that promotes tabs over spaces. I 
> thought the tabs vs spaces war was mostly won by spaces over a decade ago 
> (apart from a few plucky freedom fighters who will never surrender).

Python is the only language that I know that *needs* to specify tabs versus
spaces since it is the only language I know of which uses whitespace
formating as part of its syntax and structure.  Mixed usage may be annoying
in other languages; but, it breaks Python.

Otherwise, it is my experience that the preference for tabs versus spaces
depends on the users chosen platform.  *nix users prefer tabs while Windows
users prefer spaces.

>> and there are equally picky syntaxs (ie,
>> Makefiles) that mandate the use of tabs.  I personally prefer tabs as it
>> lets *me* decide how far the apparent indentations are in the code. You
>> may like four spaces; but, I agree with Linus Torvalds that eight spaces
>> is much clearer.  The beautiful thing about tabs is that we can both set
>> our tab stops to match our own viewing preferences.
>
> Actually I agree with you about tabs. I think tabs are far more logical 
> and sensible. But I'm stuck with broken tools that don't deal with tabs, 

Where you not the one a few posts back telling Seebs that he needed to
change his broken tools?

> and with PEP 8 that mandates the use of spaces, and popular opinion that 
> says make is crazy for using tabs.

Stupid rules are meant to be broken.

> So, I bite my lip, stop using broken tools that make dealing with space-
> indents painful, and just deal with it. And you know what? It's not so 
> bad after all.

If I am using somebody elses project, then I will post my output using
their code conventions.  I have smart conversion scripts that convert
between different indent formats.  I edit in the format that I prefer and,
in my projects, the indentation in the SCM is in my preferred format.

>> This is Python's most noticable blemish outside of the community.
>> Everybody knows that Python is the language that forces you to use a
>> particular style of formatting; and, that is a turn-off for many people.
>
> Their loss. I don't miss the flame wars over the One True Brace Style. 
> There are enough disagreements over coding conventions without adding to 
> them.

This choice has obviously not been effective in stopping flame wars.  I can
cite multiple threads where it has caused them.

>> It is a big mistake that whenever the issue arises, the community
>> effectively attacks anybody who might have disagreements with the
>> tradeoffs made for the Python language.  This tends to set people on the
>> defensive and gives them a bad taste about the language as a whole.
>
> That's very insightful. Why don't you apply some of that insight to the 
> other side? It is *incredibly* annoying to see the same old people making 
> the same old snide remarks about the same old issues over and over again, 
> particularly when:

A large part of the reason that the issue keeps coming up is that the
community never really deals with it when it does.  I have enough customer
support experience to know that a client is never really satisfied until
you acknowledge their problem.  Until the problem is acknowledged, the
client will have put up psychological communcation block that prevents
them from hearing any workarounds that you might have.

The community never acknowledges the problem.  It simply sweeps the
problem under the rug telling the people raising these issues that they
don't know what they are talking about; strengthening the psychological
block and further impeding the communication.  The people with these
problems therefore never feel that they have been heard, become unwilling
to listen to the solutions,  and will thus keep bringing the problem
back up.

> * it's not an issue for thousands of other users;

You are now hearing the testimony of those who have had problems.  I also
know that it is human nature for advocates to simply overlook the problems
when they arise.  That doesn't mean that the problem is there.

I have used Python for over a decade in spite of its problems because I
believe that the benefits outway the detriments.  I am however objective
enough to be congnizant of the problems; and, I am fully aware of there
effects on new members of the community.

When prospective Python programmers approach me with these problems I:

1. Acknowledge that the problem exits.

2. Explain the trade-offs that have lead to the problem.

3. Suggest ways to work around the problem.

4. Point out why I believe the benefits of using Python outway its
idiosyncrasies.

I don't just tell them that there is no problem or that the problems they
may be experiencing a

Re: What people are using to access this mailing list

2010-11-03 Thread Martin Gregorie

On Wed, 03 Nov 2010 13:05:23 +, Grant Edwards wrote:

> On 2010-11-03, Paul Rudin  wrote:
>> John Bond  writes:
>>
>>> On 3/11/2010 11:17 AM, Steven D'Aprano wrote:
 On Wed, 03 Nov 2010 08:02:29 +, John Bond wrote:

> Hope this isn't too O/T - I was just wondering how people read/send
> to this mailing list, eg. normal email client, gmane, some other
> software or online service?
 Usenet via my ISP, on comp.lang.python.

>>> Using what client (or web client)?
>>
>> Emacs, of course :-;
> 
> Slrn, of course.

Pan since I'm on Linux. 

Agent if I was still a Windows user. Its the best news reader I've used.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org   |
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

On 2010-11-03, Grant Edwards  wrote:
> On 2010-11-03, Paul Rudin  wrote:
>> John Bond  writes:
>>
>>> On 3/11/2010 11:17 AM, Steven D'Aprano wrote:
 On Wed, 03 Nov 2010 08:02:29 +, John Bond wrote:

> Hope this isn't too O/T - I was just wondering how people read/send to
> this mailing list, eg. normal email client, gmane, some other software
> or online service?
 Usenet via my ISP, on comp.lang.python.

>>> Using what client (or web client)?
>>
>> Emacs, of course :-;
>
> Slrn, of course.

Of, course.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

On 2010-11-03, Tim Harig  wrote:
> On 2010-11-03, Grant Edwards  wrote:
>> On 2010-11-03, Paul Rudin  wrote:
>>> John Bond  writes:
>>>
 On 3/11/2010 11:17 AM, Steven D'Aprano wrote:
> On Wed, 03 Nov 2010 08:02:29 +, John Bond wrote:
>
>> Hope this isn't too O/T - I was just wondering how people read/send to
>> this mailing list, eg. normal email client, gmane, some other software
>> or online service?
>
> Usenet via my ISP, on comp.lang.python.

 Using what client (or web client)?
>>>
>>> Emacs, of course :-;
>>
>> Slrn, of course.
>
> Of, course.

The OP could have figured all this out by himself by merely looking at
the headers for a sampling of articles.

Heck, with about 50 lines of Python, one could probably produced a
fairly comprehensive statistical report on access methods and clients
used by posters to "this mailing list".  [An NNTP client module is one
of the "batteries", and that module's docs contains most of the code
needed to access the articles.]

Finding out the access methods used by people who don't post is
somewhat more difficult. :)

-- 
Grant Edwards   grant.b.edwardsYow! Boy, am I glad it's
  at   only 1971...
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

On Wed, 03 Nov 2010 11:58:07 +, John Bond wrote:

> On 3/11/2010 11:17 AM, Steven D'Aprano wrote:
>> On Wed, 03 Nov 2010 08:02:29 +, John Bond wrote:
>>
>>> Hope this isn't too O/T - I was just wondering how people read/send to
>>> this mailing list, eg. normal email client, gmane, some other software
>>> or online service?
>> Usenet via my ISP, on comp.lang.python.
>>
>>
>>
> Using what client (or web client)?

Usually Pan, sometimes KNode.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

2010-11-03 Thread Emile van Sebille


On 11/3/2010 11:49 AM Tim Harig said...


A large part of the reason that the issue keeps coming up is that the
community never really deals with it when it does.  I have enough customer
support experience to know that a client is never really satisfied until
you acknowledge their problem.


Then you likely also have enough experience to know that once the 
customer has made the decision you accept their call.  As a consultant 
you move on after having done your duty bringing the issue to light. 
The same applies here -- it's not changing, so you (generic you) accept 
it and move on.  The community has dealt with the issue by acknowledging 
that differing opinions exist and the BDFL makes the final call, which 
is certainly something the community accepts.  I imagine a PEP could be 
submitted suggesting change, and it hasn't been done because the outcome 
is certain.


Otherwise, there's always whython...

http://writeonly.wordpress.com/2010/04/01/whython-python-for-people-who-hate-whitespace/

Emile



--
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On Wed, 03 Nov 2010 02:40:11 +, Seebs wrote:

> Sure, but there's also no way for you to spot that something looks
> suspicious.  In Python, if something is misindented, it does what you
> told it to do, and there's no way for you to tell, by looking at it,
> that it isn't what was intended.  In C, if something is misindented, it
> does what you told it to do, but it's obvious looking at the code that
> something went wrong.

If it's that obvious, why do people keep causing those indentation-
related bugs in C?

I'm glad for you that you have a finely trained attention to detail that 
is able to instantly spot misindented C code (or is that misplaced braces 
and correctly indented?), but it is a notoriously common error which 
suggests that it's not anywhere near as obvious as you think.

It's *far* more common than Python code being misindented.

There's even a commonly suggested style for C programmers: always use 
braces any time the syntax allows them, even when they're not needed, 
because the next guy who maintains the file may not be as careful and may 
forget to add the braces when needed.

>> But I can see the other end of the block in Python.  I don't need any
>> tricks to make sure that it is the end.  And if your block is too big
>> to see the structure easily then that just means that some code should
>> be factored out to a method.
> 
> This level of dogmatism about what should always be the case is not
> conducive to good software engineering practices.

I question that assertion. Good engineering practices is about setting 
best practices, and following them, not avoiding them because there might 
be the odd exception here and there.

> It is not obvious to me that it's *always* the case.

So what if there is an exception one time in twenty thousand? You don't 
design a tool (such as a programming language) on the basis of what's 
good for the rare exceptional cases, but on what's good for the common 
cases. The common case is that functions and methods should be short 
enough to see the structure by eye. If it isn't, you have more problems 
than just the lack of begin/end markers. The language shouldn't make 
everyone carry the burden of supporting two-page functions all the time, 
just to save you an insignificant amount of trouble on the vanishingly 
rare occasion you need a function that is two pages long.

-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On Wed, 03 Nov 2010 18:49:06 +, Tim Harig wrote:

>> Actually I agree with you about tabs. I think tabs are far more logical
>> and sensible. But I'm stuck with broken tools that don't deal with
>> tabs,
> 
> Where you not the one a few posts back telling Seebs that he needed to
> change his broken tools?

Yes, and I also said that I sympathized with him if he couldn't.

>>> It is a big mistake that whenever the issue arises, the community
>>> effectively attacks anybody who might have disagreements with the
>>> tradeoffs made for the Python language.  This tends to set people on
>>> the defensive and gives them a bad taste about the language as a
>>> whole.
>>
>> That's very insightful. Why don't you apply some of that insight to the
>> other side? It is *incredibly* annoying to see the same old people
>> making the same old snide remarks about the same old issues over and
>> over again, particularly when:
> 
> A large part of the reason that the issue keeps coming up is that the
> community never really deals with it when it does.

No. The community does deal with it. It deals with it by saying "It isn't 
going to change." If you want a language that forces you to wrap ever 
block in BEGIN END tags, you have a thousand choices. Python is not one 
of them. What is so hard to understand about this?

> I have enough
> customer support experience to know that a client is never really
> satisfied until you acknowledge their problem.  Until the problem is
> acknowledged, the client will have put up psychological communcation
> block that prevents them from hearing any workarounds that you might
> have.

Yes, well that too goes both ways. *I* have a psychological communication 
block that prevents me from hearing any complaints about the lack of 
braces from people who refuse to acknowledge that having to type braces 
is stupid and annoying, and that the use of braces in a language hurts 
readability.

Frankly, I DON'T CARE how often your editor breaks your source code. I 
don't care about Seeb's mail server that converts his Python code to 
HTML. I don't give a rat's arse about how many times some buggy ftp 
client has mangled the indentation on Python files. Not my problem. Your 
pain is not my pain, and any solution to these problems that involves 
changing the way I read and write Python code is an anti-solution to a 
non-problem to me.

Until the "Python is broken 'cos it has no braces" crowd acknowledge this 
fact, I just harden my heart against their complaints. Why should *I* 
have to acknowledge their issues when they don't acknowledge mine?

-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On Wed, 03 Nov 2010 01:25:56 +, Seebs wrote:

> Whitespace damage is, indeed, wrong.  It's a bad thing.  It is an
> *extremely common* bad thing, 

I question that.

You've claimed that you have to deal with broken indentation on a regular 
basis. I've *never* had to deal with broken whitespace, except for 
certain websites that mangle leading whitespace when you post a comment. 
So I don't post code on those websites.

> and I fundamentally don't think it was a
> good choice to build a system with no redundancy against it.

Python does have some redundancy against indentation mangling. Not all 
combinations of indentation are legal.

# Not legal:
y = x + 1
z = x*y

# Not legal:
if x:
do_something()

# Not legal:
if x: do something()
else:
do_something_else()

And so on. True, there are some failure modes which can't be easily 
recovered from without reading and understanding the code. That's okay. 
Such failure modes are vanishingly rare -- for every twenty thousand 
braces you avoid typing, you might, if you're unlucky, need to fix an 
instance of broken indentation.

> That
> "redundant" information saves our hides on a regular basis in an
> imperfect world.

So you say.

-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On 2010-11-03, Steven D'Aprano  wrote:
> On Wed, 03 Nov 2010 02:40:11 +, Seebs wrote:
>> Sure, but there's also no way for you to spot that something looks
>> suspicious.  In Python, if something is misindented, it does what you
>> told it to do, and there's no way for you to tell, by looking at it,
>> that it isn't what was intended.  In C, if something is misindented, it
>> does what you told it to do, but it's obvious looking at the code that
>> something went wrong.

> If it's that obvious, why do people keep causing those indentation-
> related bugs in C?

I don't think they do.  I can't remember the last time I've seen one.

> I'm glad for you that you have a finely trained attention to detail that 
> is able to instantly spot misindented C code (or is that misplaced braces 
> and correctly indented?), but it is a notoriously common error which 
> suggests that it's not anywhere near as obvious as you think.

It's "notoriously common", but can you show me an actual example of
it happening in real code?  Not a "hey guys look how misleading this
would be" example conjured up for illustration, but an *actual* example
in live code?

I can't remember one, except I think maybe I saw one somewhere in...
hmm.  No, wait, that was perl.

>> This level of dogmatism about what should always be the case is not
>> conducive to good software engineering practices.

> I question that assertion. Good engineering practices is about setting 
> best practices, and following them, not avoiding them because there might 
> be the odd exception here and there.

I don't think I buy this.  I've seen a whole lot of good writers and good
programmers, and in both groups, they consistently report that you have
to know how the rules work before you break them.

> The language shouldn't make 
> everyone carry the burden of supporting two-page functions all the time, 
> just to save you an insignificant amount of trouble on the vanishingly 
> rare occasion you need a function that is two pages long.

I don't think there's a particularly big burden there.

Explicit is better than implicit.  It is *better* to explicitly mark the
ends of things than to have it be implicit in dropping indentation.  That's
not a burden, it's good engineering practice.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On 2010-11-03, Steven D'Aprano  wrote:
> On Wed, 03 Nov 2010 01:25:56 +, Seebs wrote:
>> Whitespace damage is, indeed, wrong.  It's a bad thing.  It is an
>> *extremely common* bad thing, 

> I question that.

> You've claimed that you have to deal with broken indentation on a regular 
> basis.

I'd guess I see something which got screwed up somehow every couple of
weeks, usually while refactoring stuff.

>> and I fundamentally don't think it was a
>> good choice to build a system with no redundancy against it.

> Python does have some redundancy against indentation mangling. Not all 
> combinations of indentation are legal.

True, but it doesn't seem to catch the most common failure modes.

> And so on. True, there are some failure modes which can't be easily 
> recovered from without reading and understanding the code. That's okay. 
> Such failure modes are vanishingly rare -- for every twenty thousand 
> braces you avoid typing, you might, if you're unlucky, need to fix an 
> instance of broken indentation.

This is ridiculous overstatement.  Moving a single block of overly-nested
code out into a separate method could generate several indentation
mishaps if Something Goes Wrong, which it does sometimes.  I haven't
written more than a couple hundred blocks in Python, so I'm a factor of a
hundred out from twenty thousand braces, and I've had six or seven
indentation problems.

And yes, I can just recreate it, but it takes more effort, since I can't
do things like just handing it to an automated tool that can correct
it completely automatically.

Furthermore, I don't WANT to skip closing braces.  EXPLICIT IS BETTER
THAN IMPLICIT.  I *WANT* to have the beginnings and ends marked.

I want end braces or "end" or something at the end of a block for
the same reason that I prefer:
x = "hello, world"
to
x = "hello, world
where we just assume the string ends at the end of the line.

>> That
>> "redundant" information saves our hides on a regular basis in an
>> imperfect world.

> So you say.

Well, it works for me.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python documentation too difficult for beginners

2010-11-03 Thread Cameron Simpson

On 02Nov2010 03:42, jk wrote:
| I've been coding in PHP and Java for years, and their documentation is
| concise, well structured and easy to scan.

While I agree about Java, at least the core Java docs, and javadoc
output in general (_great_ cross referencing!) I have mixed feelings
about the PHP docs. Though I suspect that stems from a dislike of the
PHP library API in general more than the docs, perhaps.

| Others have mentioned this apparently for years (see:
|
http://stackoverflow.com/questions/4046166/easy-to-navigate-online-python-reference-manual/4070851
| and http://www.russellbeattie.com/blog/python-library-docs-still-suck
| and http://xahlee.org/perl-python/xlali_skami_cukta.html).
|
| Compare for instance the differences in ease of use, and speed of use,
| of these:
|
| http://docs.python.org/library/functions.html#open
| http://uk.php.net/manual/en/function.fopen.php
|
| The former is difficult to find (try searching for 'open' in the
| search box and see what you get).

I confess I almost never use the search box - as you say the result
relevance can be dodgy.

However, I do find the docs easy to use and pleasant to read on the
whole. My use is as follows:

For speed and convenience I have the docs locally stored.

I open the front page and then usually both the modules and index in
adjacent brwoser tabs.

I go to the index if I'm not sure of the module.

The strength of the index is that it tends to contain stuff that people
thought should be indexed (versus searches, which often have no
contextual understanding of the text, so their relevance is weaker).
The weakness of the index is that it can be hard to pick the relevant
entry. Open-link-in-new-tab is my friend here:-(

| It is simply a collection of
| paragraphs without strong enough contrast to differentiate the
| different parts - parameters, parameter values, return types,
| exceptions and related functions. It is slow to read and doesn't allow
| easy visual scanning.

That is true (the scanning). But by contrast, it does read like prose
and lends itself to a visit that gets you a complete feel for the
function.

[...]
| Has anyone else struggled while trying to learn the language? The
| whole documentation system seems geared towards people who already
| know what they're looking for and is close to useless for beginners.
| I'm not the only one who finds google an easier way to find
| documentation about python.

I certainly don't find the core docs hard to use (with some exceptions;
I still don't really understand the urllib stuff for the cases where
configuration is needed - weird proxy setups etc).

I've only been using Python for a few years and have generally found
that language easy to learn and the docs easy to read. I rarely reach
for The Google unless I'm seeking examples; the docs could do with a few
more of these IMHO.

I understand the attraction of the structured layout javadoc yields but
find it leads to "drier" documentation. It also works well for Java
because it is strongly typed - a great deal of the structure in the docs
can come directly from the code because argument counts, names and types
are always explicit (or deducable).

These are just initial responses. Now to wade the whole thread:-)
--
Cameron Simpson DoD#743
http://www.cskk.ezoshosting.com/cs/

On the contrary of what you may think, your hacker is fully aware
of your company's dress code. He is fully aware of the fact that it
doesn't help him to do his job.
- Gregory Hosler
--
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On 2010-11-03, Seebs  wrote:

> Explicit is better than implicit.  It is *better* to explicitly mark the
> ends of things than to have it be implicit in dropping indentation.  That's
> not a burden, it's good engineering practice.

Dededenting does explicitly mark the end of a block.

-- 
Grant Edwards   grant.b.edwardsYow! What PROGRAM are they
  at   watching?
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On 2010-11-03, Steven D'Aprano  wrote:
> On Tue, 02 Nov 2010 19:26:56 +, Tim Harig wrote:
>> I agree with Seebs, Python is the only language I know that promotes the
>> use of spaces over tabs; 

> Really?

Yes.

> I'm not aware of *any* language that promotes tabs over spaces.

Makefiles.

> I 
> thought the tabs vs spaces war was mostly won by spaces over a decade ago 
> (apart from a few plucky freedom fighters who will never surrender).

No.  However, you've got a fallacy of the excluded middle here -- you're
ignoring the very large set of "doesn't care either way", and looking only
at things that prefer one or the other.

> So, I bite my lip, stop using broken tools that make dealing with space-
> indents painful, and just deal with it. And you know what? It's not so 
> bad after all.

I don't consider it broken for a tool to favor a more logical style which
is *actually* required by at least one format, and not a problem for anything
I've ever used except (sort of) Python.

In fact, Python works perfectly with tabs; it's just other Python
programmers who get fussy.  :)

> Their loss. I don't miss the flame wars over the One True Brace Style. 
> There are enough disagreements over coding conventions without adding to 
> them.

I don't miss them, or care about them; after all, I can just run indent/cb
to format something however I like, and run it again to match any given
coding style standard.  Problem solved.

> * it's not an issue for thousands of other users;

This is a non-argument.  That something isn't a problem for other people
makes no difference to the people for whom it's a problem.

> * even if it were an issue, if you use the right tool for the job, the 
> issue disappears;

I have never found any other editor that I like as much as the one I use
now.

> * and even if there is no right tool for the job, the feature isn't going 
> to change;

I think you miss the point of the observation.  I'm not expecting it to
change; I'm pointing out that insisting that it's not a problem is
*insulting* to the people for whom it is a problem.

> * and even if it would change, the people doing the whinging aren't going 
> to volunteer to make the change.

Oh, I'd happily contribute code if it'd matter.  But it wouldn't.

>> It would be much better if the community would simply acknowledge that
>> this is a tradeoff the the language has made and one which is often
>> misunderstood by many first time Python programmers.

> Been there, done that. This is *old news*.

I haven't seen it done yet.  I've seen a whole lot of people tell me that
an editor I've been using for twenty years is "broken" because I found
a program that is brittle with regards to its inputs that is prone to
being triggered by a behavior which has been free of problems (and indeed
in some cases *mandatory*) for everything else.  I've seen people smugly
tell me that I'd love this if I just tried it.  That didn't work for
pickles, it didn't work for Player-vs-Player fighting in video games,
and it's not gonna work for the lack of end markers.

Explicit is better than implicit.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On 2010-11-03, Grant Edwards  wrote:
> On 2010-11-03, Seebs  wrote:
>> Explicit is better than implicit.  It is *better* to explicitly mark the
>> ends of things than to have it be implicit in dropping indentation.  That's
>> not a burden, it's good engineering practice.

> Dededenting does explicitly mark the end of a block.

If you can't point to the token, it's implicit.  :)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python documentation too difficult for beginners

2010-11-03 Thread Cameron Simpson

On 02Nov2010 04:23, jk  wrote:
| This (http://epydoc.sourceforge.net/stdlib/) is what I'm talking
| about.
| 
| Why aren't the official docs like this, and why has it taken me 2 days
| of searching? All this needs is a search engine behind it and it'd be
| perfect.

It looks a lot like javadoc. But its weakness is stuff like this:

  http://epydoc.sourceforge.net/stdlib/Canvas.Polygon-class.html

Automatic docness, no useful information.

And of course the ugliness; I find the python docs much nicer to look
at. But I do wish the cross referencing was a bit better, often.
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

In an insane society, the sane man must appear insane.
- Keith A. Schauer 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python documentation too difficult for beginners

2010-11-03 Thread Martin Gregorie

On Thu, 04 Nov 2010 08:03:37 +1100, Cameron Simpson wrote:

> On 02Nov2010 04:23, jk  wrote: | This
> (http://epydoc.sourceforge.net/stdlib/) is what I'm talking | about.
> |
> | Why aren't the official docs like this, and why has it taken me 2 days
> | of searching? All this needs is a search engine behind it and it'd be
> | perfect.
> 
> It looks a lot like javadoc. But its weakness is stuff like this:
> 
>   http://epydoc.sourceforge.net/stdlib/Canvas.Polygon-class.html
> 
> Automatic docness, no useful information.
>
You get the same problem in Java and it has exactly the same root: a lazy 
programmer who can't be arsed to document his code.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org   |
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ways of accessing this mailing list?

Grant Edwards  writes:

> On 2010-11-02, John Bond  wrote:
> > My normal inbox is getting unmanageable, and I think I need to find
> > a new way of following this and other lists.
>
> Point an NNTP client at new.gmane.org.

Ditto, but the correct hostname is ‘news.gmane.org’.

> This "list" is also a Usenet newsgroup (comp.lang.python), and there
> are a number of cheap/low-cost text-only Usenet providers.

Moreover, Gmane is (as John probably knows) an NNTP interface to many
forums that would otherwise not be available via NNTP.

-- 
 \“Members of the general public commonly find copyright rules |
  `\implausible, and simply disbelieve them.” —Jessica Litman, |
_o__)  _Digital Copyright_ |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

John Bond  writes:

> On 3/11/2010 11:17 AM, Steven D'Aprano wrote:
> > Usenet via my ISP, on comp.lang.python.
> Using what client (or web client)?

Gnus on Emacs.

-- 
 \“Perchance you who pronounce my sentence are in greater fear |
  `\   than I who receive it.” —Giordano Bruno, burned at the stake by |
_o__)  the Catholic church for the heresy of heliocentrism, 1600-02-16 |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On 2010-11-03, Steven D'Aprano  wrote:
> On Wed, 03 Nov 2010 18:49:06 +, Tim Harig wrote:
>>> Actually I agree with you about tabs. I think tabs are far more logical
>>> and sensible. But I'm stuck with broken tools that don't deal with
>>> tabs,
>> 
>> Where you not the one a few posts back telling Seebs that he needed to
>> change his broken tools?
>
> Yes, and I also said that I sympathized with him if he couldn't.

Perhaps it would be more constructive, for everybody, to make suggestions
on how to reliably transfer code using channels that distort whitespace.

>>> That's very insightful. Why don't you apply some of that insight to the
>>> other side? It is *incredibly* annoying to see the same old people
>>> making the same old snide remarks about the same old issues over and
>>> over again, particularly when:
>> 
>> A large part of the reason that the issue keeps coming up is that the
>> community never really deals with it when it does.
>
> No. The community does deal with it. It deals with it by saying "It isn't 
> going to change." If you want a language that forces you to wrap ever 
> block in BEGIN END tags, you have a thousand choices. Python is not one 
> of them. What is so hard to understand about this?

Please to not mix my contentions with somebody else's.  I have not,
anywhere in this thread, asked to change the language.  I certainly
didn't say *anything* about adding "BEGIN END" tags to the code itself.
I did say that I found code folding markers in the comments to be a
useful form for expressing code structure; but, that has nothing to with
chainging Python itself.  I also expressed my opinion that I felt spaces
for indenting was a poor choice for the standard; but, since it is also
not part of the language proper, it can safely be ignored.

What I did suggest was a more constructive way of dealing with these
criticisms.  You said that you found it "*incredibly* annoying" to have
this to see the same old "snide remarks" from "the same old people."  I
merely suggested that if the community changes its attitude towards those
making those remarks, that it might go a long way towards silencing some of
those descents.  The fact that you are unwilling to make these changes
makes me question your conviction when you claim to be so annoyed.

>> I have enough
>> customer support experience to know that a client is never really
>> satisfied until you acknowledge their problem.  Until the problem is
>> acknowledged, the client will have put up psychological communcation
>> block that prevents them from hearing any workarounds that you might
>> have.
>
> Yes, well that too goes both ways. *I* have a psychological communication 
> block that prevents me from hearing any complaints about the lack of 
> braces from people who refuse to acknowledge that having to type braces 
> is stupid and annoying, and that the use of braces in a language hurts 
> readability.

I understand that you don't like braces; but, I have nowhere advocated
adding them to the Python langauge.  That is a different argument that you
are having with Seebs.

> Frankly, I DON'T CARE how often your editor breaks your source code. I 

Only you have even mentioned editors in this thread.

> don't care about Seeb's mail server that converts his Python code to 
> HTML. I don't give a rat's arse about how many times some buggy ftp 
> client has mangled the indentation on Python files. Not my problem. Your 

Nobody else mentioned ftp servers in this either; but, I must admit that
you are doing a good job of providing evidence for the alternate viewpoint.

> pain is not my pain, and any solution to these problems that involves 
> changing the way I read and write Python code is an anti-solution to a 
> non-problem to me.

Then why bother adding to the noise in this thread at all since it has
nothing to do with you?  I see however, since you have brought all this
baggage to the table that was not otherwise in the thread, that you
obviously have a axe to grind.

> Until the "Python is broken 'cos it has no braces" crowd acknowledge this 
> fact, I just harden my heart against their complaints. Why should *I* 
> have to acknowledge their issues when they don't acknowledge mine?

Then please state your Python language issues rather simply grinding your axe
against those who are stating theirs.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On Wed, 03 Nov 2010 20:35:20 +, Seebs wrote:

>>> This level of dogmatism about what should always be the case is not
>>> conducive to good software engineering practices.
> 
>> I question that assertion. Good engineering practices is about setting
>> best practices, and following them, not avoiding them because there
>> might be the odd exception here and there.
> 
> I don't think I buy this.  I've seen a whole lot of good writers and
> good programmers, and in both groups, they consistently report that you
> have to know how the rules work before you break them.

Yes. How does that contradict what I said?

There is a huge difference between knowing when to break the rules, and 
avoiding the rules because there might someday be an exception.

>> The language shouldn't make
>> everyone carry the burden of supporting two-page functions all the
>> time, just to save you an insignificant amount of trouble on the
>> vanishingly rare occasion you need a function that is two pages long.
> 
> I don't think there's a particularly big burden there.

Good for you.

> Explicit is better than implicit.

Ah, argument by misunderstanding the Zen!

> It is *better* to explicitly mark the
> ends of things than to have it be implicit in dropping indentation. 
> That's not a burden, it's good engineering practice.

Python does explicitly mark blocks. It does it by changes in indentation. 
An indent is an explicit start-block. An outdent is an explicit end-
block. There is nothing implicit in a change in indent level.

To illustrate the difference, this is how a hypothetical language might 
use implicit end of blocks:

if condition:
true_clause()
another_true_clause()
else:
false_clause()

The if block ends implicitly when you reach an else statement, and the 
else clause implicitly ends... where?

It gets worse:

if condition:
if another_condition:
true_clause()
else:
false_clause()
another_clause()

Such a hypothetical language might decide on a rule that else will always 
match the closest if, or the outermost if that is legal. That would be an 
implicit end of block. This is not even within the same galaxy as what 
Python does.

It simply isn't possible to have implicit start/end block markers, unless 
you restrict your language in ways that exclude most blocks. E.g. if all 
if blocks were restricted to a single statement, then you could have an 
implicit block -- the block in one statement. Stating that Python uses 
implicit block markers is simply wrong.

-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Subject: Re: problem with opening a new python program in a new window (and keeping track of the process)

2010-11-03 Thread Zak Kinion

>> What I want to do:  launch seperate python programs from one main
>> program (multi-threading will not achieve this because the mechanize
>> library uses one shared global opener object which will not suit my
>> needs)  I want the scripts launched to be in seperate windows that i
>> can see the output of on screen, seperate processes.  I can accomplish
>> this in win32 by:
>>
>> import subprocess;
>> args = ["cmd", "/c", "START", "python", "myScript.py"];
>> process1 = subprocess.Popen(args, shell=False);
>
> Pass CREATE_NEW_CONSOLE as one of the creationflags:
>
> 
> import os, sys


Yep, that definitely works. :)


> import subprocess
>
> processes = []
> cmd = [sys.executable, "-c", "import os; print os.getpid (); raw_input ()"]
> for i in range (3):
>  processes.append (subprocess.Popen (cmd, 
> creationflags=subprocess.CREATE_NEW_CONSOLE))
>
> #
> # Keep looping round to see the current status
> #
> while True:
>  for p in processes:
>    print p.poll ()
>
>  raw_input ()
>
> 
>
> TJG
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>



-- 
Zak Kinion
zkin...@gmail.com
(702) 287-5613
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What people are using to access this mailing list

2010-11-03 Thread Rhodri James


On Wed, 03 Nov 2010 11:58:07 -, John Bond  wrote:


On 3/11/2010 11:17 AM, Steven D'Aprano wrote:

On Wed, 03 Nov 2010 08:02:29 +, John Bond wrote:


Hope this isn't too O/T - I was just wondering how people read/send to
this mailing list, eg. normal email client, gmane, some other software
or online service?

Usenet via my ISP, on comp.lang.python.




Using what client (or web client)?


Opera (as an NNTP client, not a web client).

--
Rhodri James *-* Wildebeest Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On 2010-11-03, Steven D'Aprano  wrote:
> Yes. How does that contradict what I said?

Once you understand that you do have to break the rules occasionally,
it is a good idea to design things that will be robust when the rules
are broken.

> Ah, argument by misunderstanding the Zen!

I see.  So explicit boundaries are a good thing, except when they are
one specific special case.

Let us imagine a hypothetical mirror-universe person, who is otherwise
like you, but:

1.  Has a goatee.
2.  Actually hates the indentation rules, wishes Python had braces,
but has become emotionally invested in defending the status quo because
if he had to suffer, dammit, everyone else should have to suffer too.

You have not yet made a single argument that he wouldn't have made
too.

>> It is *better* to explicitly mark the
>> ends of things than to have it be implicit in dropping indentation. 
>> That's not a burden, it's good engineering practice.

> Python does explicitly mark blocks. It does it by changes in indentation. 
> An indent is an explicit start-block. An outdent is an explicit end-
> block. There is nothing implicit in a change in indent level.

What's the token that marks the end of a block, corresponding to the
colon used to introduce it?

> It simply isn't possible to have implicit start/end block markers, unless 
> you restrict your language in ways that exclude most blocks. E.g. if all 
> if blocks were restricted to a single statement, then you could have an 
> implicit block -- the block in one statement. Stating that Python uses 
> implicit block markers is simply wrong.

No, it isn't.  There's no token telling you where the block ended.

C *allows* implicit blocks, and this is widely regarded as a key flaw.
However, it also allows you to explicitly mark blocks in a way which
is robust against common errors, allowing software to automatically
fix up differences between, say, competing indentation styles.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On Wed, 03 Nov 2010 20:30:43 +, Seebs wrote:

> I'm not expecting it to change;

Then why talk about it? Just to hear the sound of your voice? (Or see the 
font of your writing?) To waste our time? To feel more virtuous than 
those who don't see your point of view?

If you don't expect a change, what's the point of this discussion?

> I'm pointing out that insisting that it's not a problem is
> *insulting* to the people for whom it is a problem.

And insisting that it is a problem is equally insulting to those for whom 
it is not a problem.

-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

2010-11-03 Thread Rhodri James


On Wed, 03 Nov 2010 18:49:06 -, Tim Harig  wrote:

On 2010-11-03, Steven D'Aprano   
wrote:

On Tue, 02 Nov 2010 19:26:56 +, Tim Harig wrote:

I agree with Seebs, Python is the only language I know that promotes  
the

use of spaces over tabs;


Really? I'm not aware of *any* language that promotes tabs over spaces.  
I
thought the tabs vs spaces war was mostly won by spaces over a decade  
ago

(apart from a few plucky freedom fighters who will never surrender).


Python is the only language that I know that *needs* to specify tabs  
versus

spaces since it is the only language I know of which uses whitespace
formating as part of its syntax and structure.  Mixed usage may be  
annoying

in other languages; but, it breaks Python.


I regard this as a strength.  I have wasted far too much time at work  
writing review comments that could be paraphrased as "your broken editor  
settings have made this (C code) unreadable."


--
Rhodri James *-* Wildebeest Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

2010-11-03 Thread Tim Chase


On 11/03/10 15:59, Seebs wrote:

Dededenting does explicitly mark the end of a block.


If you can't point to the token, it's implicit.  :)


Just because you asked for it to be pointed to:

http://svn.python.org/view/python/trunk/Include/token.h?view=markup

The DEDENT token is explicitly defined as the number "6", FWIW...

:)

-tkc




--
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On 2010-11-03, Steven D'Aprano  wrote:
> On Wed, 03 Nov 2010 20:30:43 +, Seebs wrote:
>> I'm not expecting it to change;

> Then why talk about it?

Because I find technical questions interesting in and of themselves.  I
will happily talk with people about the reasons for which the C preprocessor
is the way it is, even though it's never going to change and we all
hate it like poison.

>> I'm pointing out that insisting that it's not a problem is
>> *insulting* to the people for whom it is a problem.

> And insisting that it is a problem is equally insulting to those for whom 
> it is not a problem.

No, it isn't.

A friend of mine is colorblind.  For him, certain red/green pairings are
indistinguishable.  For me to insist that it is not a problem that a
user interface uses those to distinguish two things is insulting to
him; I am dismissing a very real problem.  For him to insist that it
is a problem for him is in no way insulting me.  He's not saying that it's
a problem for me.  He's merely saying that *there exist* people for whom
it is a problem.

No one has claimed that this is a problem *for everybody*.  Just that
there exist real-world workflows for which it is a problem, or people
for whom it is a problem.

This is an asymmetrical situation.  The opposite of "it's never a
problem for anybody" isn't "it is always a problem for everybody"
but "it is at least sometimes a problem for at least some people."

The reality is, the indentation-instead-of-markers thing *does* sometimes
lead to problems.  We could blame it on tools, but the tools could just as
easily blame the language for being brittle.  Given the degree to which
the rest of the world has standardized on not caring how *much*
whitespace is between things (though sometimes caring whether or not
there's *any* whitespace between them), it seems to me that the odd
man out is the one who is creating the burden.

Once many file formats exist which don't care how many spaces you
use, and many tools have been developed with those file formats in
mind, coming up with a new file format which cares how many spaces you
use seems a little short-sighted.  Demanding that all tools be changed
to fit a new paradigm is a pretty big demand to place on people.

On the whole, I don't personally think the benefits have been worth it.
I think Python would be a better, richer, language if it used explicit
end tokens of some sort.  Maybe it wouldn't.  I do know, though, that
of the programmers I know outside the Python newsgroup, not a single
one likes that aspect of Python.  It is consistently regarded as an
annoying quirk.  Some use Python anyway; it has merits, certainly.  If
I were offered a choice between Python and PHP for a project, I would
*absolutely* pick Python.  (Subject, of course, to the assumption that
the project would in some way involve computers, or programming, or
that I would at some point have to either write code for the project
use it, or possibly come within twenty feet of someone who was working
on it; outside of those limitations, I might consider PHP.)

I feel the same way about pretty much every language I use.  C would
be a much better language if the macro processor weren't such a giant
filesystem verification stage for a filesystem distributed across
multiple machines*.  They all have flaws.

Python's the only language I use where an obvious flaw, which is repeatedly
observed by everyone I know who uses the language, is militantly and
stridently defended by dismissing, insulting, and attacking the character
and motives of anyone who suggests that it might be a bit of a nuisance.

I suspect part of that is simply because it *is* a tradeoff, and there
are good reasons for it.  It offers some advantages.  It's not something
that you'd be insane to like; the problems are easily mitigated once you
know about them, and the benefits are worth it.  If I worked with a lot
more novice-level C programmers who hadn't yet had the importance of
careful style drilled into them, I might well find the indentation problems
people keep talking about to be a real thing, possibly even a very
serious one.

But the fact remains, being brittle in the face of whitespace changes *is*
a flaw.  It breaks code under circumstances which are, for better or
worse, common.  As I pointed out before:  There is a *REASON* that diff
has an option for ignoring whitespace changes -- because they are common
enough that such an option is commonly useful for distinguishing between
real changes and inadvertant ones.

Note that "whitespace indentation" in and of itself isn't the thing I'm
describing as a flaw; it's the side-effect of being brittle when whitespace
changes.  The indentation thing as a whole has some definite plusses, and
it's a tradeoff that I think may even be a good fit for a language
specifically focused on easier readability.

-s
[*] clusterfsck.
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <--

Re: Compare source code

2010-11-03 Thread Michael Torrie

On 11/03/2010 02:39 PM, Seebs wrote:
> Furthermore, I don't WANT to skip closing braces.  EXPLICIT IS BETTER
> THAN IMPLICIT.  I *WANT* to have the beginnings and ends marked.

I suggest, then that Pascal or Ruby would suit your needs better than
Python.

> I want end braces or "end" or something at the end of a block for
> the same reason that I prefer:
>   x = "hello, world"
> to
>   x = "hello, world
> where we just assume the string ends at the end of the line.

Not even close to the same thing, sorry.

As for refactoring code, vim makes it really easy to move blocks in and
out.  The only time I could see this becoming an issue is if functions
or blocks of code are too long to see on a page at once.  If this is the
case, break them up.  Sounds to me like your problems with refactoring
and indention in python could be do to these kinds of design issues.
Having curly braces certainly doesn't help in these situations either.
More than once I've had C code I was refactoring that broke due to the
fact that while trying to move blocks around I misplaced a brace, an
issue I never have in Python.

In the meantime, whitespace structure is one of the things about Python
that I like the *most* about the language.  Being able to crank out
executable pseudo-code is pretty addictive.  And I never write
pseudo-code on paper with begin and end blocks cause it's too much
effort when scribbling by hand.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

Seebs  writes:

> On 2010-11-03, Steven D'Aprano  wrote:
> > Python does explicitly mark blocks. It does it by changes in
> > indentation. An indent is an explicit start-block. An outdent is an
> > explicit end- block. There is nothing implicit in a change in indent
> > level.
>
> What's the token that marks the end of a block, corresponding to the
> colon used to introduce it?

You have introduced this requirement for tokens; it's fallacious. The
direct answer is: tokens aren't part of the requirement to be explicit.

The more general answer is: the block is explicitly ended where the
indentation ends.

-- 
 \ “I must say that I find television very educational. The minute |
  `\   somebody turns it on, I go to the library and read a book.” |
_o__)—Groucho Marx |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

Seebs  writes:

> Furthermore, I don't WANT to skip closing braces. EXPLICIT IS BETTER
> THAN IMPLICIT. I *WANT* to have the beginnings and ends marked.

Python doesn't require that. You're going to be disappointed by most
Python code if that's what you want.

Which is not a failing of Python.

-- 
 \   “Few things are harder to put up with than the annoyance of a |
  `\  good example.” —Mark Twain, _Pudd'n'head Wilson_ |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Subclassing unittest.TestCase?

In article ,
 Peter Otten <__pete...@web.de> wrote:

> Remove the base class from the module with
> 
> del CommonTestCase
> 
> before you invoke unittest.main().

Wow, what a clever idea!  I tried it, and it does exactly what I need.  
Thanks!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On 2010-11-03, Michael Torrie  wrote:
> I suggest, then that Pascal or Ruby would suit your needs better than
> Python.

In the absence of network effects, I'd just be using Ruby.  I have reason
to work with projects that have a lot of existing Python, though, so I
use it too.

> As for refactoring code, vim makes it really easy to move blocks in and
> out.

Yes, though I mostly use nvi, same thing -- basically.  The issue I've
had is that the automatic-tab thing (which I actively want for everything
else I edit) tends to make it quirky.

> The only time I could see this becoming an issue is if functions
> or blocks of code are too long to see on a page at once.  If this is the
> case, break them up.  Sounds to me like your problems with refactoring
> and indention in python could be do to these kinds of design issues.
> Having curly braces certainly doesn't help in these situations either.
> More than once I've had C code I was refactoring that broke due to the
> fact that while trying to move blocks around I misplaced a brace, an
> issue I never have in Python.

For me, I'd rather have the compiler choke because I have mismatched
braces than have the code run apparently just fine except that something
has unintentionally moved in or out of an else clause because there was
no marker.  I've had both happen, probably.

> In the meantime, whitespace structure is one of the things about Python
> that I like the *most* about the language.  Being able to crank out
> executable pseudo-code is pretty addictive.  And I never write
> pseudo-code on paper with begin and end blocks cause it's too much
> effort when scribbling by hand.

I never write on paper anyway.  :)

Anyway, I'm not disputing that there are things that it makes nicer.  I'm
just observing that there exists a category of failures which is completely
unique to Python, which no other language (except BF, which I'm not sure
I ought to count) has, which tends to show up occasionally until you've
gotten all the changed tools and habits, and even then can show up when
dealing with other people who use tools which, well, work perfectly for
everything else.  But not for this.

Only other tool I know with a comparable dependance on spacing is Makefiles,
and I have never in my life met someone who used them and didn't think
that was a loathesome error which should never have made it into
production code.  Python's not nearly as bad, actually.  :)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

2010-11-03 Thread Emile van Sebille


On 11/3/2010 4:09 PM Seebs said...


What's the token that marks the end of a block, corresponding to the
colon used to introduce it?




My thoughts tend more towards 'can we get Guido to eliminate the colon 
requirements' -- The indent level of the next line ought to suffice.


Seriously.

Emile

--
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

On 2010-11-04, Lawrence D'Oliveiro  wrote:
> In message , Seebs wrote:
>> It is extremely useful to me to have spaces converted to tabs
>> for every other file I edit.

> I???m thinking of going the other way. After many years of treating tabs as 
> four-column steps, I might give up on them and use spaces everywhere.

I *absolutely must* use tabs for Makefiles.

For code in most other languages, it's merely a factor of 8 improvement
in storage.  :)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code