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

[Yingjie Lan]

--- 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.

Regards,

Yingjie


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

> From: John Bond 
> Subject: Re: Must be a bug in the re module [was: Why this result with the re 
> module]
> To: python-list@python.org
> Date: Wednesday, November 3, 2010, 8:43 AM
> On 3/11/2010 4:23 AM, Yingjie Lan
> wrote:
> > --- On Wed, 11/3/10, MRAB 
> wrote:
> >
> >> From: MRAB
> >> Subject: Re: Must be a bug in the re module [was:
> Why this result with the re module]
> >> To: python-list@python.org
> >> Date: Wednesday, November 3, 2010, 8:02 AM
> >> On 03/11/2010 03:42, Yingjie Lan
> >> wrote:
> >> 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 am confused also:
> >
> > If the outer group \1 is empty, how could the inner
> > group \2 actually have something?
> >
> > Yingjie
> >
> >
> >
> 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. I
> 
> If you took away the outer groups repetition:
> 
> re.findall('((.a.)*)', 'Mary has a lamb')
> 
> then, for each of the six matches, it returns the full
> thing that was 
> matched:
> 
> ('Mar', 'Mar'), ('', ''), ('', ''), ('has a lam', 'lam'),
> ('', ''), ('', 
> '')]
> 
> Cheers, JB
> -- 
> http://mail.python.org/mailman/listinfo/python-list
> 


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

How to highlight Label/Text in tkinter ?

[VGNU Linux]

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: text file reformatting

[iwawi]

On Nov 1, 6:50 pm, "cbr...@cbrownsystems.com"
 wrote:
> On Nov 1, 1:58 am, iwawi  wrote:
>
>
>
>
>
> > On 1 marras, 09:59, "cbr...@cbrownsystems.com"
>
> >  wrote:
> > > On Oct 31, 11:46 pm, iwawi  wrote:
>
> > > > On 31 loka, 21:48, Tim Chase  wrote:
>
> > > > > > PRJ01001 4 00100END
> > > > > > PRJ01002 3 00110END
>
> > > > > > I would like to pick only some columns to a new file and put them 
> > > > > > to a
> > > > > > certain places (to match previous data) - definition file (def.csv)
> > > > > > could be something like this:
>
> > > > > > VARIABLE   FIELDSTARTS     FIELD SIZE      NEW PLACE IN NEW DATA 
> > > > > > FILE
> > > > > > ProjID     ;       1       ;       5       ;       1
> > > > > > CaseID     ;       6       ;       3       ;       10
> > > > > > UselessV  ;        10      ;       1       ;
> > > > > > Zipcode    ;       12      ;       5       ;       15
>
> > > > > > So the new datafile should look like this:
>
> > > > > > PRJ01    001       00100END
> > > > > > PRJ01    002       00110END
>
> > > > > How flexible is the def.csv format?  The difficulty I see with
> > > > > your def.csv format is that it leaves undefined gaps (presumably
> > > > > to be filled in with spaces) and that you also have a blank "new
> > > > > place in new file" value.  If instead, you could specify the
> > > > > width to which you want to pad it and omit variables you don't
> > > > > want in the output, ordering the variables in the same order you
> > > > > want them in the output:
>
> > > > >   Variable; Start; Size; Width
> > > > >   ProjID; 1; 5; 10
> > > > >   CaseID; 6; 3; 10
> > > > >   Zipcode; 12; 5; 5
> > > > >   End; 16; 3; 3
>
> > > > > (note that I lazily use the same method to copy the END from the
> > > > > source to the destination, rather than coding specially for it)
> > > > > you could do something like this (untested)
>
> > > > >    import csv
> > > > >    f = file('def.csv', 'rb')
> > > > >    f.next() # discard the header row
> > > > >    r = csv.reader(f, delimiter=';')
> > > > >    fields = [
> > > > >      (varname, slice(int(start), int(start)+int(size)), width)
> > > > >      for varname, start, size, width
> > > > >      in r
> > > > >      ]
> > > > >    f.close()
> > > > >    out = file('out.txt', 'w')
> > > > >    try:
> > > > >      for row in file('data.txt'):
> > > > >        for varname, slc, width in fields:
> > > > >          out.write(row[slc].ljust(width))
> > > > >        out.write('\n')
> > > > >    finally:
> > > > >      out.close()
>
> > > > > Hope that's fairly easy to follow and makes sense.  There might
> > > > > be some fence-posting errors (particularly your use of "1" as the
> > > > > initial offset, while python uses "0" as the initial offset for
> > > > > strings)
>
> > > > > If you can't modify the def.csv format, then things are a bit
> > > > > more complex and I'd almost be tempted to write a script to try
> > > > > and convert your existing def.csv format into something simpler
> > > > > to process like what I describe.
>
> > > > > -tkc- Piilota siteerattu teksti -
>
> > > > > - Näytä siteerattu teksti -
>
> > > > Hi,
>
> > > > Thanks for your reply.
>
> > > > Def.csv could be modified so that every line has the same structure:
> > > > variable name, field start, field size and new place and would be
> > > > separated with semicolomns as you mentioned.
>
> > > > I tried your script (which seems quite logical) but I get this
>
> > > > Traceback (most recent call last):
> > > >   File "testing.py", line 16, in 
> > > >     out.write (row[slc].ljust(width))
> > > > TypeError: an integer is required
>
> > > > Yes - you said it was untested, but I can't figure out how to
> > > > proceed...
>
> > > The line
>
> > >     (varname, slice(int(start), int(start)+int(size)), width)
>
> > > should instead be
>
> > >     (varname, slice(int(start), int(start)+int(size)), int(width))
>
> > > although you give an example where there is no width - what does that
> > > imply? In the above case, it will throw an exception.
>
> > > Anyway, I think you'll find there's something a bit off in the output
> > > loop with the parameter passed to ljust() as well. The value given in
> > > your csv seems to be the absolute position, but as it's implemented by
> > > Tim, it acts as the relative position.
>
> > > Given Tim's parsing into the list fields, I have a feeling that what
> > > you really want instead of
>
> > >     for varname, slc, width in fields:
> > >         out.write(row[slc].ljust(width))
> > >     out.write('\n')
>
> > > is to have
>
> > >     s = ''
> > >     for varname, slc, width in fields:
> > >         s += " "*(width - len(s)) + row[slc]
> > >     out.write(s+'\n')
>
> > > And if that is what you want, then you will surely want to globally
> > > replace the name 'width' with for example 'start_column', because then
> > > it all makes sense :).
>
> > > Cheers - Chas- Piilota siteerattu teksti -
>
> > > - Näytä siteerattu teksti -
>
> > Yes, it's meant to be t

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

[Yingjie Lan]

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

>3) then said there must be >=0 occurrences of what's inside it,
>which of course there is, so that has no effect.
>
>((.a.)*)*

Hi, 

I think there should be a difference: unlike before,
now what's inside the outer group can match an empty 
string. And so by reason of the greediness of the 
quantifier * of the outer group (that is, the last *), 
it should take up the empty string after each 
non-empty match.

So, the first match in 'Mary has a lamb' must be:

'' + 'Mar' + '' (the empty string before the 'y')

(note the first '' is before the 'M')
Then, after skipping the 'y' (remember, the empty 
string before 'y' is already taken), comes a second:

'' (the one between 'y' and ' ')

Then after skipping the space ' ', comes a third:

'has' + ' a ' + 'lam' + '' (the empty string before the 'b')

And finally, it matches the empty string after 'b':

''

So there should be total of four matches -- isn't it?

Yingjie


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

Re: Mail Merge from python data

[Tim Harig]

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.

>> 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.

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.

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).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python documentation too difficult for beginners

[rantingrick]

AD i agree with you! The official python tutorial and the official
docs are pretty much a twisted mass of confusion to the initiated
programmer. Even today when i try yo search the docs i find the result
quite frankly useless. And the search reminds me of the old XP "puppy
dog" search.  The doc ARE fairly well written HOWEVER the search
engine needs an update.

For me, i just Google it, and forget it!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Man pages and info pages

[Tim Harig]

On 2010-11-03, Teemu Likonen  wrote:
> * 2010-11-02 19:36 (UTC), Tim Harig wrote:
>> I thoroughly agree. The default info viewers are quite possibly the
>> most counterintuitive programs I have ever encountered. I never did
>> bother to learn how to use them. I instead installed the more
>> intuitive pinfo program.
>
> It seems that we only agree on the part that I explicitly wrote about:
> people are less familiar with info browsers than "less" pager. I didn't
> mean to imply any reasons why this might be the case. I think "info"

The reason is really simple.  Less' interface derives from more.  Less and
more have a long history on the *nix platform and many programs have
emulated their interface.

When the GNU folk decided to clone *nix they decided that they knew better
and simply decided to create their own interfaces.  I guess they figured
that everybody loves to have to learn multiple varying interfaces to use
different programs.

> browser is intuitive and easy to use. The basic commands:
[SNIP]
> Arrow keys, page up, page down keys work as usual.

Actually, the left arrow key does not work at all intuitively.  One would
expect that it should go back to the previous page as it would in lynx,
etc.  It does not.

By tradition 'n' and 'p' are broken for scrolling in a page.  'b' is often
used in place of p but that seems to take one back to the top of the page.

The s key for a search is another example that has already been discussed.

> What's counter-intuitive in it?

Maybe its intutitive to an emacs user; but, I find pinfo's default key
bindings much easier.

>>> With the text terminal info browser called "info" as well as Emacs'
>>> info browser you can use command "s" (stands for "search"). It
>>> prompts for a regexp pattern to search in the whole document,
>>> including subsections etc.
>>
>> Right, pinfo offers this as well; but, then you have to figure out
>> where in the nodes that the search has taken you and how to navigate
>> from that node to find additional information that you may need.
>
> I usually return to the top node with "t" command or go one or more
> levels up in the tree with "u" command. The first line in the window
> tells where I am.

That assumes that you understand the node structure used or that you don't
mind returning to the top and having to re-walk the node structure every
time that you want to find new piece of information.

I already discussed that just finding the info pages can be difficult
because you have to know that they are stored under the package name and
that multiple pages can be used for man page structure.
-- 
http://mail.python.org/mailman/listinfo/python-list

Coca Cola Scholarship: Are You Qualified?

[PHP.CCC]

Coca Cola Scholarship: Are You Qualified?

Before you apply for Coca Cola scholarship, here are the things you
should know:
Coca-Cola Scholars Foundation programs
There are two types of Coca-Cola Scholars Foundation programs:
·2-Year Colleges Scholarship Program
· Scholars Program for high school seniors
1. 2-Year Colleges Scholarship Program
Read more

http://childschooledu.blogspot.com
-- 
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]

[John Bond]

On 3/11/2010 4:23 AM, Yingjie Lan wrote:

--- On Wed, 11/3/10, MRAB  wrote:


From: MRAB
Subject: Re: Must be a bug in the re module [was: Why this result with the re 
module]
To: python-list@python.org
Date: Wednesday, November 3, 2010, 8:02 AM
On 03/11/2010 03:42, Yingjie Lan
wrote:
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 am confused also:

If the outer group \1 is empty, how could the inner
group \2 actually have something?

Yingjie



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. I


If you took away the outer groups repetition:

re.findall('((.a.)*)', 'Mary has a lamb')

then, for each of the six matches, it returns the full thing that was 
matched:


('Mar', 'Mar'), ('', ''), ('', ''), ('has a lam', 'lam'), ('', ''), ('', 
'')]


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

Re: Man pages and info pages

[Teemu Likonen]

* 2010-11-02 19:36 (UTC), Tim Harig wrote:

> On 2010-11-02, Teemu Likonen  wrote:
>> There is also the problem that people are less familiar with info
>> browsers than the usual "less" pager which is used by "man" command.
>
> I thoroughly agree. The default info viewers are quite possibly the
> most counterintuitive programs I have ever encountered. I never did
> bother to learn how to use them. I instead installed the more
> intuitive pinfo program.

It seems that we only agree on the part that I explicitly wrote about:
people are less familiar with info browsers than "less" pager. I didn't
mean to imply any reasons why this might be the case. I think "info"
browser is intuitive and easy to use. The basic commands:

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

Arrow keys, page up, page down keys work as usual.

What's counter-intuitive in it?

>> With the text terminal info browser called "info" as well as Emacs'
>> info browser you can use command "s" (stands for "search"). It
>> prompts for a regexp pattern to search in the whole document,
>> including subsections etc.
>
> Right, pinfo offers this as well; but, then you have to figure out
> where in the nodes that the search has taken you and how to navigate
> from that node to find additional information that you may need.

I usually return to the top node with "t" command or go one or more
levels up in the tree with "u" command. The first line in the window
tells where I am.
-- 
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]

[John Bond]

OK, I've got that, and I have no problem with the capturing part.
My real problem is with the number of total matches.
*I think it should be 4 matches in total but findall
gives 6 matches*, for the new regex '((.a.)*)*'.
I'd love to know what you think about this.

Many thanks!
Yingjie





We've already been through that, and nothing's changed - all you've done is:

1) taken something that you know (now!) has six matches:

(.a.)*

2) added an outer capturing group (which does not change the actual 
matches, only what gets returned):


((.a.)*)

3) then said there must be >=0 occurrences of what's inside it, which of 
course there is, so that has no effect.


((.a.)*)*

End result: the matching is exactly the same, findall still needs to 
return the 6 things it did in the first place, but now it also has to 
return an extra value at each return location (that being what's 
captured by the new outer group) hence the tuples.


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

Re: Allowing comments after the line continuation backslash

[Ben Finney]

Robert Kern  writes:

> I'd go one step further:
>
> styles = [
> ("normal",  "image", MainWindow.ColorsNormalList),
> ("highlighted", "highlight", MainWindow.ColorsHighlightedList),
> ("selected","select",MainWindow.ColorsSelectedList),
> ]
>
> Keeping the []s separate from the items and using the trailing comma
> means that I can easily add new items or reorder the items.

No problem with that, except I'd still keep the closing character
indented::

styles = [
("normal",  "image", MainWindow.ColorsNormalList),
("highlighted", "highlight", MainWindow.ColorsHighlightedList),
("selected","select",MainWindow.ColorsSelectedList),
]

because it's consistent with how lines are grouped everywhere else in
Python: the grouping continues while the same indentation level
continues, and stops once the indentation stops.

-- 
 \  “By instructing students how to learn, unlearn, and relearn, a |
  `\ powerful new dimension can be added to education.” —Alvin |
_o__)Toffler, _Future Shock_, 1970 |
Ben Finney
-- 
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]

[Yingjie Lan]

--- On Wed, 11/3/10, MRAB  wrote:

> From: MRAB 
> Subject: Re: Must be a bug in the re module [was: Why this result with the re 
> module]
> To: python-list@python.org
> Date: Wednesday, November 3, 2010, 8:02 AM
> On 03/11/2010 03:42, Yingjie Lan
> wrote:

> 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 am confused also:

If the outer group \1 is empty, how could the inner
group \2 actually have something?

Yingjie


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

Py3: decode subprocess output

[Gnarlodious]

Under Python 2.6, commands.getoutput returns text type str containing
ANSI Terminal formatting hex characters:

"\x1b[1;31mSun : \x1b[1;36m114.902\x1b[0m   - 0\xf800' (-)\x1b[1;33m

I have a system for parsing out the relevant parts and I prefer to
keep using that system.

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?

Or alternatively, is there a whizbang Py3 method to parse out strings
delimited by hex? I tried several tricks but it is all beyond my
skills.

Thanks.

-- Gnarlie
-- 
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]

[Yingjie Lan]

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


> Just to clarify - findall is returning:
> 
> [ (only match in outer group, 1st match in inner group)
> , (only match in outer group, 2nd match in inner group)
> , (only match in outer group, 3rd match in inner group)
> , (only match in outer group, 4th match in inner group)
> , (only match in outer group, 5th match in inner group)
> , (only match in outer group, 6th match in inner group)
> ]
> 
> Where "only match in outer group" = "6th match in inner
> group" owing to the way that capturing groups with
> repetition only return the last thing they matched.
> 

---On Wed, 11/3/10, MRAB wrote---

> 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).

OK, I've got that, and I have no problem with the capturing part.
My real problem is with the number of total matches.
I think it should be 4 matches in total but findall 
gives 6 matches, for the new regex '((.a.)*)*'.
I'd love to know what you think about this.

Many thanks!
Yingjie



  
-- 
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]

[John Bond]

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?


Cheers, JB

--
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]

[John Bond]

On 3/11/2010 3:55 AM, John Bond wrote:



Could you please reconsider how would you
work with this new one and see if my steps
are correct? If you agree with my 7-step
execution for the new regex, then:

We finally found a real bug for re.findall:


re.findall('((.a.)*)*', 'Mary has a lamb')

[('', 'Mar'), ('', ''), ('', ''), ('', 'lam'), ('', ''), ('', '')]


Cheers,

Yingjie





Nope, I'm afraid it is lack of understanding again.

The outer capturing group that you've added is matching the entirety 
of what's matched by the inner one (which is six matches, that you now 
accept).  Because it only returns the last of them, it returns one 
thing - an empty string (that being the last thing that the inner 
group matched).  Findall is simply returning that in each of the six 
return values it needs to return because of the inner one.


You just need to accept that findall (like all of re) works fine, and 
if it doesn't seem to do what you expect, it's because the expectation 
is wrong.


Cheers, JB


Just to clarify - findall is returning:

[ (only match in outer group, 1st match in inner group)
, (only match in outer group, 2nd match in inner group)
, (only match in outer group, 3rd match in inner group)
, (only match in outer group, 4th match in inner group)
, (only match in outer group, 5th match in inner group)
, (only match in outer group, 6th match in inner group)
]

Where "only match in outer group" = "6th match in inner group" owing to 
the way that capturing groups with repetition only return the last thing 
they matched.


Cheers, JB


--
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]

[MRAB]

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).
--
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]

[John Bond]

Could you please reconsider how would you
work with this new one and see if my steps
are correct? If you agree with my 7-step
execution for the new regex, then:

We finally found a real bug for re.findall:


re.findall('((.a.)*)*', 'Mary has a lamb')

[('', 'Mar'), ('', ''), ('', ''), ('', 'lam'), ('', ''), ('', '')]


Cheers,

Yingjie





Nope, I'm afraid it is lack of understanding again.

The outer capturing group that you've added is matching the entirety of 
what's matched by the inner one (which is six matches, that you now 
accept).  Because it only returns the last of them, it returns one thing 
- an empty string (that being the last thing that the inner group 
matched).  Findall is simply returning that in each of the six return 
values it needs to return because of the inner one.


You just need to accept that findall (like all of re) works fine, and if 
it doesn't seem to do what you expect, it's because the expectation is 
wrong.


Cheers, JB
--
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]

[Yingjie Lan]

> 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.)*)* ?


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

Re: *** FBI gets a warm welcome in Chicago for their EXCELLENTperformance - cheers to NEW CONS ***

[Gunner Asch]

On Tue, 02 Nov 2010 13:58:16 -0700, Rich Grise 
wrote:

>On Tue, 02 Nov 2010 14:17:29 -0700, Gunner Asch wrote:
>> 
>> But...shrug..there will be far less after the Great Cull
>
>I think some people might be surprised as to exactly _who_ gets "culled".
>
>Good Luck!
>Rich

Indeed. So stock up, and watch your six.

Gunner


"Confiscating wealth from those who have earned it, inherited it,
 or got lucky is never going to help 'the poor.' Poverty isn't
 caused by some people having more money than others, just as obesity 
isn't caused by McDonald's serving super-sized orders of French fries
Poverty, like obesity, is caused by the life choices that dictate
results." - John Tucci,
-- 
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]

[Yingjie Lan]

> Your regex says "Zero or more consecutive occurrences of
> something, always returning the most possible".  That's
> what it does, at every position - only matching emptyness
> where it couldn't match anything (findall then skips a
> character to avoid overlapping/infinite empty
> matches),  and at all other times matching the most
> possible (eg. "has a lam" not "has", " a ", "lam").

You are about to convince me now. 
You are correct for the regex '(.a.)*'.

What I thought was for this regex: '((.a.)*)*', 
I confused myself when I added an enclosing ().

Could you please reconsider how would you
work with this new one and see if my steps 
are correct? If you agree with my 7-step
execution for the new regex, then:

We finally found a real bug for re.findall:

>>> re.findall('((.a.)*)*', 'Mary has a lamb')
[('', 'Mar'), ('', ''), ('', ''), ('', 'lam'), ('', ''), ('', '')]


Cheers,

Yingjie


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

Re: Allowing comments after the line continuation backslash

[Robert Kern]

On 2010-11-02 19:46 , Ben Finney wrote:


Instead, I'd do::

 styles = [
 ("normal",  "image", MainWindow.ColorsNormalList),
 ("highlighted", "highlight", MainWindow.ColorsHighlightedList),
 ("selected","select",MainWindow.ColorsSelectedList)]


I'd go one step further:

styles = [
("normal",  "image", MainWindow.ColorsNormalList),
("highlighted", "highlight", MainWindow.ColorsHighlightedList),
("selected","select",MainWindow.ColorsSelectedList),
]

Keeping the []s separate from the items and using the trailing comma means that 
I can easily add new items or reorder the items.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Re: Python documentation too difficult for beginners

[John Bond]

My 2c:

I use the ActiveState distro, and it's winhelp doco. It's generally ok 
and some things, like Dive Into Python, I've found excellent.


But I do quite regularly find myself cursing at the vagueness of the 
index, and some of the content seems to require that you know it before 
you read it (I wish I could remember an example).


Like everything, it could be improved.

Cheers, JB



--
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]

[MRAB]

On 03/11/2010 01:41, Yingjie Lan wrote:

From: John Bond
Subject: Re: Why this result with the re module
To: "Yingjie Lan"
Cc: python-list@python.org
Date: Tuesday, November 2, 2010, 8:09 PM
On 2/11/2010 12:19 PM, Yingjie Lan
wrote:

From: John Bond
Subject: Re: Why this result with the re module

Firstly, thanks a lot for your patient explanation.
this time I have understood all your points

perfectly.


Secondly, I'd like to clarify some of my points,

which

did not get through because of my poor presentation.

I suggested findall return a tuple of

re.MatchObject(s),

with each MatchObject instance representing a match.
This is consistent with the re.match() function

anyway.

And it will eliminate the need of returning tuples,
and it is much more precise and information rich.

If that's not possible, and a tuple must be returned,
then the whole match (not just subgroups) should
always be included as the first element in the tuple,
as that's group(0) or '\0'. Less surprise would

arise.


Finally, it seems to me the algo for findall is

WRONG.


To re.findall('(.a.)*', 'Mary has a lamb'),
by reason of greediness of '*', and the requirement
of non-overlapping, it should go like this
(suppose an '' is at the beginning and at the end,
and between two consecutive characters there is
one and only one empty string ''. To show the
match of empty strings clearly,
I am concatenating each repeated match below):

Steps for re.findall('(.a.)*', 'Mary has a lamb'):

step 1: Match '' + 'Mar' + '' (gready!)
step 2: skip 'y'
step 3: Match ''
step 4: skip ' '
step 5: Match ''+'has'+' a '+'lam'+'' (greedy!)
step 6: skip 'b'
step 7: Match ''

So there should be exactly 4 matches in total:

'Mar', '', 'has a lam', ''

Also, the matches above shows
that if a repeated subgroup only captures
the last match, the subgroup (.a.)*
should always capture '' here (see steps
1, 3, 5, 7) above.

Yet the execution in Python results in 6 matches!
And, the capturing subgroup with repetition
sometimes got the wrong guy.

So I believe the algorithm for findall must be WRONG.

Regards,

Yingjie

At a guess, I'd say what is happening is something like
this:

Steps for re.findall('(.a.)*', 'Mary has a lamb'):

step 1: Match 'Mar' at string index 0
step 2: Match '' at string index 3 (before 'y')
step 3: skip 'y'
step 4: Match '' at string index 4 (before ' ')
step 5: skip ' '
step 6: Match 'has a lam' at string index 5
step 7: Match '' at string index 14 (before 'b')
step 8: skip 'b'
step 9: Match '' at string index 15 (before EOS)



matches: ('Mar', '', '', 'has a lam', '', '')
returns: ['Mar', '', '', 'lam', '', ''] (*)

(*) "has a " lost due to not being last repetition at that
match point

Which seems about right to me! Greediness has nothing to do
with it, except that it causes 'has a lam' to be matched in
one match, instead of as three separate matches (of 'has', '
a ' and 'lam').


Disagree in this case, where the whole regex
matches an empty string. Greadiness will match
as much as possible. So it will also match
the empty strings between consecutive
characters as much as possible, once
we have properly defined all the unique
empty strings. Because of greadiness,
fewer matches should be found. In this
case, it should find only 4 matches
(shown in my steps) instead of 6 matches
(shown in your steps).


Attempt 1 starts at the beginning of the string:
[Mar]y has a lamb
Matches once, returns 'Mar'

Attempt 2 starts where the previous match ended:
Mar[]y has a lamb
Matches an empty string, returns ''

Attempt 3 starts where the previous match ended:
Mary[] has a lamb
Matches an empty string, returns ''

Attempt 4 starts where the previous match ended:
Mary [has][ a ][lam]b
Matches 3 times, returns 'lam'

Attempt 5 starts where the previous match ended:
Mary has a lam[]b
Matches an empty string, returns ''

Attempt 6 starts where the previous match ended:
Mary has a lamb[]
Matches an empty string, returns ''

The result is therefore ['Mar', '', '', 'lam', '', '']
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python documentation too difficult for beginners

[Lawrence D'Oliveiro]

In message <2010110223050345181-nizum...@mcnuggetscom>, Nizumzen wrote:

> On 2010-11-02 10:42:22 +, jk said:
> 
>> I've been coding in PHP and Java for years, and their documentation is
>> concise, well structured and easy to scan.
> 
> Are you mad? Javadoc is one of the worst examples of source code
> documentation I can possibly imagine.

It appeals to corporate herds of code-cutter drones, though. It follows 
tedious rules that can be officially adopted as corporation policy, and 
cited as a conformance feature by third-party products that these 
corporations seem happy to spend money on. So the comments can be extracted 
from the code, sorted, collated, stamped, filed, indexed, and collated 
again, all as part of the make-work activity that seems to pass for actual 
productivity in so many big corporations.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Trouble with importing

[Seebs]

On 2010-11-02, Ben Ahrens  wrote:
> I did indeed continue to top-post, and you should plonk me.

Edited for accuracy.  Done.

-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

[Seebs]

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.  What I have seen is bugs hidden by the
> indentation not matching the block structure.

Right.  That's *related to* indentation -- it wouldn't be there (we hope)
had the indentation been right.

> Wrong indentation in
> Python *is* a bug.  There's no other visual signal to hide the error.

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.

> 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.  It is not obvious to
me that it's *always* the case.

-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

[Tim Harig]

On 2010-11-03, Tim Harig  wrote:
> On 2010-11-03, D'Arcy J.M. Cain  wrote:
>> On Wed, 3 Nov 2010 00:41:46 + (UTC)
>> Tim Harig  wrote:
>> Identifying the end of the block has some value.  And the braces just
>> make the code noisy.
>
> With good syntax highlighting, you don't notice them unless you are looking
> for something because the markers are in comments and the markers for
> a block are only visible when the block is unfolded.  As a benefit, they 
> allow the folding
> stucture to provide expression of the code structure that cannot be
> expressed in the code itself.

Also note that you can use whatever you like for the folding markers if the
braces intimidate you.  {{{ just happens to be the most recognized
standard.  The Erlang crowd like to use ## for this sort of thing.
-- 
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]

[Chris Melville]

Disagree in this case, where the whole regex
matches an empty string. Greadiness will match
as much as possible. So it will also match
the empty strings between consecutive
characters as much as possible, once
we have properly defined all the unique
empty strings. Because of greadiness,
fewer matches should be found. In this
case, it should find only 4 matches
(shown in my steps) instead of 6 matches
(shown in your steps).

Yingjie


I'm sorry but I really don't understand where your coming from.

Your regex says "Zero or more consecutive occurrences of something, 
always returning the most possible".  That's what it does, at every 
position - only matching emptyness where it couldn't match anything 
(findall then skips a character to avoid overlapping/infinite empty 
matches),  and at all other times matching the most possible (eg. "has a 
lam" not "has", " a ", "lam").


Perhaps someone else can look at this and comment on whether findall is 
doing what it is supposed to, or not. To me, it is.


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

Re: Py3: Import relative path module

[MRAB]

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.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Tim Harig]

On 2010-11-03, D'Arcy J.M. Cain  wrote:
> On Wed, 3 Nov 2010 00:41:46 + (UTC)
> Tim Harig  wrote:
>> On 2010-11-02, D'Arcy J.M. Cain  wrote:
>> Actually, I have found similar markers to be useful everywhere.  I don't
>> like the way my editor tries to fold Python code, so I started inserting
>> folding markers myself:
>> 
>>  # foo {{{
>>  if foo:
>
> Now that is redundant.  We know it's "foo" at the top of the block.

In practice the comment would explain why and how the conditional is
being used just like any other comment.  Since your example as abstract,
I didn't have anything useful to say about it as I would for real code.

When the code is folded, I will see nothing but the comments.  It is often
helpful to look at a section of code with all of the code blocks folded to
gain a high level understanding of the code before zeroing in on the
specific section that I wish to edit.  When I do edit a section, I unfold
no more code blocks then necessary.  If I have to unfold too many blocks to
to edit a single section of code, then it is a powerful indication that
either the code block is not properly self contained or that the comments
of the surrounding code blocks are insufficient to convey information about
their code block.

> Identifying the end of the block has some value.  And the braces just
> make the code noisy.

With good syntax highlighting, you don't notice them unless you are looking
for something because the markers are in comments and the markers for
a block are only visible when the block is unfolded.  As a benefit, they allow 
the folding
stucture to provide expression of the code structure that cannot be
expressed in the code itself.

I often group blocks together that would not otherwise be indented or
otherwise expressed together as they were in your example.

# top level group {{{

# part 1 {{{
code
# }}}

# part 2 {{{
code
# }}}

# part 3 {{{
code
# }}}

# }}}

Folded in my editor, it looks like this:

 44 +--- 15 lines: # top level group ---

Unfolding the top level group, it looks like this:

 44 # top level group {{{
 45
 46 +  3 lines: # part 1 ---
 49
 50 +  3 lines: # part 2 ---
 53
 54 +  3 lines: # part 3 ---
 57
 58 # }}}

It is therefore clear that all three of the parts are logically connected.
I can keep them all folded and view them as a group or a can look into the
group and edit just the relevant section of the group:

 44 # top level group {{{
 45
 46 +  3 lines: # part 1 ---
 49
 50 # part 2 {{{
 51 code
 52 # }}}
 53
 54 +  3 lines: # part 3 ---
 57
 58 # }}}

I have effectively added a meta structure to the blocks inside of
the fuction at a finer grain then is supported by the syntax itself.
Should I decide later that the top level group is becoming autonomous
enough to warrant moving to a separate function, I can simply grab the
entire folded block as an entity and move it to its own function body.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py3: Import relative path module

[Gnarlodious]

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.

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

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

[Yingjie Lan]

> From: John Bond 
> Subject: Re: Why this result with the re module
> To: "Yingjie Lan" 
> Cc: python-list@python.org
> Date: Tuesday, November 2, 2010, 8:09 PM
> On 2/11/2010 12:19 PM, Yingjie Lan
> wrote:
> >> From: John Bond
> >> Subject: Re: Why this result with the re module
> > Firstly, thanks a lot for your patient explanation.
> > this time I have understood all your points
> perfectly.
> >
> > Secondly, I'd like to clarify some of my points,
> which
> > did not get through because of my poor presentation.
> >
> > I suggested findall return a tuple of
> re.MatchObject(s),
> > with each MatchObject instance representing a match.
> > This is consistent with the re.match() function
> anyway.
> > And it will eliminate the need of returning tuples,
> > and it is much more precise and information rich.
> >
> > If that's not possible, and a tuple must be returned,
> > then the whole match (not just subgroups) should
> > always be included as the first element in the tuple,
> > as that's group(0) or '\0'. Less surprise would
> arise.
> >
> > Finally, it seems to me the algo for findall is
> WRONG.
> >
> > To re.findall('(.a.)*', 'Mary has a lamb'),
> > by reason of greediness of '*', and the requirement
> > of non-overlapping, it should go like this
> > (suppose an '' is at the beginning and at the end,
> > and between two consecutive characters there is
> > one and only one empty string ''. To show the
> > match of empty strings clearly,
> > I am concatenating each repeated match below):
> >
> > Steps for re.findall('(.a.)*', 'Mary has a lamb'):
> >
> > step 1: Match '' + 'Mar' + '' (gready!)
> > step 2: skip 'y'
> > step 3: Match ''
> > step 4: skip ' '
> > step 5: Match ''+'has'+' a '+'lam'+'' (greedy!)
> > step 6: skip 'b'
> > step 7: Match ''
> >
> > So there should be exactly 4 matches in total:
> >
> > 'Mar', '', 'has a lam', ''
> >
> > Also, the matches above shows
> > that if a repeated subgroup only captures
> > the last match, the subgroup (.a.)*
> > should always capture '' here (see steps
> > 1, 3, 5, 7) above.
> >
> > Yet the execution in Python results in 6 matches!
> > And, the capturing subgroup with repetition
> > sometimes got the wrong guy.
> >
> > So I believe the algorithm for findall must be WRONG.
> >
> > Regards,
> >
> > Yingjie
> At a guess, I'd say what is happening is something like
> this:
> 
> Steps for re.findall('(.a.)*', 'Mary has a lamb'):
> 
> step 1: Match 'Mar' at string index 0
> step 2: Match '' at string index 3 (before 'y')
> step 3: skip 'y'
> step 4: Match '' at string index 4 (before ' ')
> step 5: skip ' '
> step 6: Match 'has a lam' at string index 5
> step 7: Match '' at string index 14 (before 'b')
> step 8: skip 'b'
> step 9: Match '' at string index 15 (before EOS)
> 
> 
> 
> matches: ('Mar', '', '', 'has a lam', '', '')
> returns: ['Mar', '', '', 'lam', '', ''] (*)
> 
> (*) "has a " lost due to not being last repetition at that
> match point
> 
> Which seems about right to me! Greediness has nothing to do
> with it, except that it causes 'has a lam' to be matched in
> one match, instead of as three separate matches (of 'has', '
> a ' and 'lam').

Disagree in this case, where the whole regex 
matches an empty string. Greadiness will match
as much as possible. So it will also match
the empty strings between consecutive 
characters as much as possible, once
we have properly defined all the unique
empty strings. Because of greadiness, 
fewer matches should be found. In this
case, it should find only 4 matches 
(shown in my steps) instead of 6 matches
(shown in your steps).

Yingjie


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

Re: Compare source code

[D'Arcy J.M. Cain]

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.  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.

> on dozens of occasions.  Being able to recover has been nice.  (So's being
> able to use fence matching to jump to the other end of a block.)

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.

-- 
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: Compare source code

[Seebs]

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.

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.

-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

[D'Arcy J.M. Cain]

On Wed, 3 Nov 2010 00:41:46 + (UTC)
Tim Harig  wrote:
> On 2010-11-02, D'Arcy J.M. Cain  wrote:
> Actually, I have found similar markers to be useful everywhere.  I don't
> like the way my editor tries to fold Python code, so I started inserting
> folding markers myself:
> 
>  # foo {{{
>  if foo:

Now that is redundant.  We know it's "foo" at the top of the block.
Identifying the end of the block has some value.  And the braces just
make the code noisy.

-- 
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: Compare source code

[Seebs]

On 2010-11-02, Tim Harig  wrote:
> 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.

Honestly, I could probably live with that; the killer is the impossibility
of recovering from white space damage.  I have had many things happen to
code over the years which required someone to run them through indent/cb.

> 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.

Yes.  It does not create an impression that this is an engineering tradeoff
which has been considered and understood; it creates the impression that
people are defensive enough about it that they're not able to confidently
acknowledge the shortcomings while maintaining that the tradeoff is worth
it.

I like C.  If you tell me that C's macro processor sucks, I will agree
with you.  I don't have to make excuses or pretend that there's no
downsides; I can justify my preference for the language even *granting*
those downsides (and downsides aplenty are to be found).

> 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.  Then it is possible
> transition to Python's strengths.  Don't simply ignore that there *are*
> potential downfalls to this approach.

Amen.

I am fine with this tradeoff.  It's not what I would have picked, but
hey, I'm not Dutch.  What I'm not fine with is people telling me that
it's not a tradeoff and that all the problems are my fault.

If someone designed a protocol where a particular kind of file was required
to be sent via email, as plain text, with many lines starting "From ", and
the protocol died horribly whenever it encountered ">From " at the
beginning of a line, no amount of pointing out that the mail servers in
question were wrong would make it a good design for a protocol.

Whitespace damage is, indeed, wrong.  It's a bad thing.  It is an
*extremely common* bad thing, and I fundamentally don't think it was
a good choice to build a system with no redundancy against it.  That
"redundant" information saves our hides on a regular basis in an
imperfect world.

-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

[Seebs]

On 2010-11-02, D'Arcy J.M. Cain  wrote:
> "Large" is no excuse for incompetency.

It is in practice.

> So configure it to recognize Python files and act accordingly.

So far as I know, it doesn't have a feature to do this.  In any event,
I work around it okay.

>> No, they aren't.  See... That would work *if I knew for sure what the intent
>> was*.
>> 
>>  if foo:
>>  bar
>>  else:
>>  baz
>>  quux
>> 
>> Does it look right?  We have *no idea*, because we don't actually know
>> whether quux was *intended* to be in the else branch or whether that's a 
>> typo.

> And C has the same problem.

Not quite!

> if (foo)
> bar;
> else
> baz;
>
> quux;

> Is quux meant to be part of the else clause?  The writer's indentation
> suggests "yes" but the code says "no".

Right.

And that's the thing:  In C, I know there's something wrong here.  I may not
know what it is, but I know *something* is wrong.

> Same is true for the C code.

Pretty much!

> In both cases you can tell what the code
> will do (modulo weird macros in the C code) but the intention is
> impossible to determine without mind reading abilities in both cases.
> We do know that the Python code *appears* to be doing exactly what the
> author intended and the C code *appears* to not be.

Yes.  And in my experience, that means that since the code must be
wrong (or I wouldn't be looking at it), it's very nice that in one of
them, I've just been told for sure that the writer was confused right
here at this line.  In the other, I have no way of knowing that the
writer was confused.

What was it someone once said?  "Explicit is better than implicit."

I *like* my parity bits.

-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

[Seebs]

On 2010-11-02, Emile van Sebille  wrote:
> What is right is that there's no question that quux is subsequent to baz 
> in all cases barring exceptions (and assuming no tabs intermixed)

Yes, but that doesn't mean it does what the programmer intended, just
that it does what it does.

> The apparent structure in python _is_ the structure, whereas otherwise 
> you've got to count your ;'s and {}'s etc to determine and verify the 
> structure matches the apparent structure provided by the programmer.

Yes.

I understand this.

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
on dozens of occasions.  Being able to recover has been nice.  (So's being
able to use fence matching to jump to the other end of a block.)

-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: Re: Multiple cookie headers and urllib2

[evilmrhenry]

Ian Kelly wrote:



On Tue, Nov 2, 2010 at 4:50 PM, evilmrhenry > wrote:


Python 2.6.4 on Ubuntu. I'm not sure if this is a bug or if I'm just
doing this wrong...

I'm trying to include two cookies when I use urllib2 to view a page.
#Code Start
import urllib2

opener = urllib2.build_opener(urllib2.HTTPCookieProcessor())
opener.addheaders.append(("Cookie", "user=abcd"))
opener.addheaders.append(("Cookie", "password=12345"))
print opener.addheaders
r = opener.open("http://emhsoft.com/docs/cookies.php";)
print r.readlines()
#Code End

http://emhsoft.com/docs/cookies.php is live, and just includes

The output is
[('User-agent', 'Python-urllib/2.6'), ('Cookie', 'user=abcd'),
('Cookie', 'password=12345')]
['Array\n', '(\n', '[user] => abcd\n', ')\n', ' ']

I expected both of the cookies to show up, not just one.


It is expected that all the cookies are contained within a single 
header, e.g.:


opener.addheaders.append(("Cookie", "user=abcd; password=12345"))

You probably shouldn't be manually adding Cookie headers if you're using 
HTTPCookieProcessor; they will tend to clobber each other.  You could 
add the cookies to the cookie jar object directly, although it's not 
really designed for that use case.  Better to just let the web app set 
the cookies -- if you want to log in programmatically, pass the username 
and password in the POST data, and then the web app can set whatever 
cookies it wants to remember the session.


And in case you aren't aware, storing the user's password in a cookie is 
generally considered bad form as it poses a greater security risk than 
storing an opaque session token.  That way the password need only be 
sent across the wire once and cannot be discovered by inspecting the 
user's browser cache.


Cheers,
Ian


Yes, this works. Thank you.

(I am aware of the cookie jar, and would normally use it. It just 
wouldn't work well in this case. Also, the user/pass was just an 
example, and *not* how I was going to do this.)

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

Re: Multiple cookie headers and urllib2

[Ian Kelly]

On Tue, Nov 2, 2010 at 4:50 PM, evilmrhenry  wrote:

> Python 2.6.4 on Ubuntu. I'm not sure if this is a bug or if I'm just doing
> this wrong...
>
> I'm trying to include two cookies when I use urllib2 to view a page.
> #Code Start
> import urllib2
>
> opener = urllib2.build_opener(urllib2.HTTPCookieProcessor())
> opener.addheaders.append(("Cookie", "user=abcd"))
> opener.addheaders.append(("Cookie", "password=12345"))
> print opener.addheaders
> r = opener.open("http://emhsoft.com/docs/cookies.php";)
> print r.readlines()
> #Code End
>
> http://emhsoft.com/docs/cookies.php is live, and just includes
> 
> The output is
> [('User-agent', 'Python-urllib/2.6'), ('Cookie', 'user=abcd'), ('Cookie',
> 'password=12345')]
> ['Array\n', '(\n', '[user] => abcd\n', ')\n', ' ']
>
> I expected both of the cookies to show up, not just one.
>

It is expected that all the cookies are contained within a single header,
e.g.:

opener.addheaders.append(("Cookie", "user=abcd; password=12345"))

You probably shouldn't be manually adding Cookie headers if you're using
HTTPCookieProcessor; they will tend to clobber each other.  You could add
the cookies to the cookie jar object directly, although it's not really
designed for that use case.  Better to just let the web app set the cookies
-- if you want to log in programmatically, pass the username and password in
the POST data, and then the web app can set whatever cookies it wants to
remember the session.

And in case you aren't aware, storing the user's password in a cookie is
generally considered bad form as it poses a greater security risk than
storing an opaque session token.  That way the password need only be sent
across the wire once and cannot be discovered by inspecting the user's
browser cache.

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

Re: Allowing comments after the line continuation backslash

[Ben Finney]

Roy Smith  writes:

> In article ,
>  Lawrence D'Oliveiro  wrote:
>
> > In message , Roy Smith wrote:
> > 
> > > In this case, I think I would do:
> > > 
> > > styles = [("normal",  "image", MainWindow.ColorsNormalList),
> > >   ("highlighted", "highlight", MainWindow.ColorsHighlightedList),
> > >   ("selected","select",MainWindow.ColorsSelectedList)]
> > > 
> > > for in description, attr, color_list in styles:
> > >blah, blah, blah

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)]

for in description, attr, color_list in styles:
# blah, blah, blah

A single consistent level of indentation on continuation lines, no
matter what happens to the first line.

> Where we seem to disagree is whether that makes things more or less
> readable :-) To me, it makes is more readable because it lets me
> understand one chunk, then move on to understanding the next chunk.

Agreed.

> You may disagree.  That's OK.

It's okay until that code gets out in the wild; then it's no longer just
a matter of one person's taste. Hence the need for conventions.

-- 
 \   “Anyone who puts a small gloss on [a] fundamental technology, |
  `\  calls it proprietary, and then tries to keep others from |
_o__)   building on it, is a thief.” —Tim O'Reilly, 2000-01-25 |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Tim Harig]

On 2010-11-02, D'Arcy J.M. Cain  wrote:
> "Redundant" is right.  However, there is a use for such comments:
>
> if foo:
> bar
> else:
> baz
> if snafu:
> cookie
> #endif snafu
> quux
> #endif foo

Actually, I have found similar markers to be useful everywhere.  I don't
like the way my editor tries to fold Python code, so I started inserting
folding markers myself:

 # foo {{{
 if foo:
 
 bar
 
 else:

 baz

 # snafu {{{
 if snafu:
 cookie
 # }}}

 quux

 # }}}

If the bar, baz, and quux blocks are large enough logical units, I will
fold them as well.

What I found is that the makers become an incredibly useful form of
organzational tool.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python documentation too difficult for beginners

[Kee Nethery]

> 
>> 
>> Therefore, if you truly want changes in the documentation, I suggest that,
>> rather then whining to the group, you make some of the changes yourself.
> 
> I agree up to here, with a different interpretation of the last clause.
> Work within the existing system. There are currently 250 open doc issues on 
> the tracker at bugs.python.org.

wow, a backlog of 250. Either 250 is the weekly submittal amount and they get 
dealt with within a week, OR the backlog is months old and the bug system is 
not an effective way to get changes or enhancements to the documentation. 
Either way, 250 open doc issues gives me the feeling that the existing 
documentation system is not working for the people trying to use it.

> After registering, go to the search page
> http://bugs.python.org/iss...@template=search&status=1
> select Components: Documentation and hit Return (or [Search])
> 
> Find an issue that is waiting for someone to suggest a new or replacement 
> sentence or paragraph, and make one. No .diff patch required, just put it in 
> the message. Or look at existing suggestions and comment.

Given that newbies are the ones who run into these issues and have a great 
desire to spare others the pain they have suffered trying to learn Python, and 
newbies typically do not know about the bug tracking system as the way to 
request enhancements to the docs (that's not how wikipedia and other sites do 
changes to information), perhaps it would be useful to put a link to a page 
that explains how to improve the docs, on each doc page? 

I have to agree with others. My preferred Python documentation is either the 
books I have, or a search on Google. A google search typically has several 
postings from people on non-official sites with the exact same confusion I 
have, and what they have tried and what ultimately worked. The suggestion was 
made that people create their own documentation if they don't like the official 
documentation, and that does seem to be a good source for python documentation.

Kee Nethery


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

Re: Allowing comments after the line continuation backslash

[Roy Smith]

In article ,
 Lawrence D'Oliveiro  wrote:

> In message , Roy Smith wrote:
> 
> > In this case, I think I would do:
> > 
> > styles = [("normal",  "image", MainWindow.ColorsNormalList),
> >   ("highlighted", "highlight", MainWindow.ColorsHighlightedList),
> >   ("selected","select",MainWindow.ColorsSelectedList)]
> > 
> > for in description, attr, color_list in styles:
> >blah, blah, blah
> 
> And so you have managed to separate one set of looping conditions into two 
> parts. What is the significance of the name “styles”? 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.

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

Where we seem to disagree is whether that makes things more or less 
readable :-)  To me, it makes is more readable because it lets me 
understand one chunk, then move on to understanding the next chunk.

You may disagree.  That's OK.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Grant Edwards]

On 2010-11-02, Lawrence D'Oliveiro  wrote:
> In message , Grant Edwards wrote:
>
>> On 2010-11-01, Lawrence D'Oliveiro 
>> wrote:
>>
>>> In message <8j8am4fk2...@mid.individual.net>, Peter Pearson wrote:

> diff -b oldfile newfile
 
 Warning: "diff -b" won't detect changes in indentation.  Changes in
 indentation can change a Python program.
>>>
>>> I'm getting less and less keen on that particular feature of Python...
>> 
>> Why?
>> 
>> 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.

Huh? Indentation is invisible?  You can't see the indentation in
Python source code?

I'm baffled...

-- 
Grant


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

Re: Python documentation too difficult for beginners

[James Mills]

On Wed, Nov 3, 2010 at 9:05 AM, Nizumzen  wrote:
> Are you mad? Javadoc is one of the worst examples of source code
> documentation I can possibly imagine. I would go as far to say that the
> Python guys should do exactly the opposite of Javadoc.

For what it's worth, I concur.

cheers
James


-- 
-- James Mills
--
-- "Problems are solved by method"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python documentation too difficult for beginners

[AD.]

On Nov 3, 7:43 am, Tim Harig  wrote:
> On 2010-11-02, jk  wrote:
>
> > As for the 9 paragraphs statement, there's a usability book that
> > applies here - it's called "Don't make me think". I shouldn't have to
>
> Anything that promotes a lack of thinking sends up red flags in my head.
> We want to recruit smart people who think, not idiots.

"Don't make me think" is the UI equivalent of "There should be one and
preferably only one obvious way to do it". Not about advocating no
thinking, but about reducing the amount of unimportant decisions you
require your users to make. But I don't think the book specifically
addresses Dutch users though.

Back on topic - I do like the Python docs overall. Especially compared
to the PHP docs. I like the overall look and format of the new Sphinx
generated ones too.

My only criticism is that the content can sometimes be a little too
terse/concise. It's fine for experienced developers, but in some
places a little more explanation and/or examples would help out the
less experienced. I can usually figure out how to do something
eventually, but the docs for some modules take more deciphering than
others.

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

Re: *** FBI gets a warm welcome in Chicago for their EXCELLENTperformance - cheers to NEW CONS ***

[Michael A. Terrell]

Gunner Asch wrote:
> 
> On Tue, 02 Nov 2010 22:13:40 GMT, david.bostw...@chemistry.gatech.edu
> (David Bostwick) wrote:
> 
> ?In article 
> ?47e0b3a3-54fb-4489-95a8-b5ec6015c...@j25g2000yqa.googlegroups.com?, small 
> Pox ?smallpox...@gmail.com? wrote:
> ?[...]
> ?
> ?Some WD40 on your keyboard might help keep the Caps Lock key from sticking so
> ?often.
> 
> The mentally ill often use mostly caps lock key strokes to emphasize
> their postings as they rant and rave.
> 
> Shrug
> 
> Get used to it.
> 
> There are a lot of those poor sick bastards out there.
> 
> But...shrug..there will be far less after the Great Cull



   Concertina neckties.  They won't dare move.


-- 
Politicians should only get paid if the budget is balanced, and there is
enough left over to pay them.
-- 
http://mail.python.org/mailman/listinfo/python-list

Multiple cookie headers and urllib2

[evilmrhenry]

Python 2.6.4 on Ubuntu. I'm not sure if this is a bug or if I'm just 
doing this wrong...


I'm trying to include two cookies when I use urllib2 to view a page.
#Code Start
import urllib2

opener = urllib2.build_opener(urllib2.HTTPCookieProcessor())
opener.addheaders.append(("Cookie", "user=abcd"))
opener.addheaders.append(("Cookie", "password=12345"))
print opener.addheaders
r = opener.open("http://emhsoft.com/docs/cookies.php";)
print r.readlines()
#Code End

http://emhsoft.com/docs/cookies.php is live, and just includes

The output is
[('User-agent', 'Python-urllib/2.6'), ('Cookie', 'user=abcd'), 
('Cookie', 'password=12345')]

['Array\n', '(\n', '[user] => abcd\n', ')\n', ' ']

I expected both of the cookies to show up, not just one.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Allowing comments after the line continuation backslash

[Lawrence D'Oliveiro]

In message , Roy Smith wrote:

> In this case, I think I would do:
> 
> styles = [("normal",  "image", MainWindow.ColorsNormalList),
>   ("highlighted", "highlight", MainWindow.ColorsHighlightedList),
>   ("selected","select",MainWindow.ColorsSelectedList)]
> 
> for in description, attr, color_list in styles:
>blah, blah, blah

And so you have managed to separate one set of looping conditions into two 
parts. What is the significance of the name “styles”? 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.

Here’s another example for you to chew on:

for \
name, reg, doindir \
in \
(
("R0", 0, True),
("R1", 1, True),
("R2", 2, True),
("R3", 3, True),
("R4", 4, True),
("R5", 5, True),
("R6", 6, True),
("SP", 6, True),
("R7", 7, False),
("PC", 7, False),
) \
:
...
#end for

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

Re: Python documentation too difficult for beginners

[Lawrence D'Oliveiro]

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?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python documentation too difficult for beginners

[Nizumzen]

On 2010-11-02 10:42:22 +, jk said:


Hi,

I've been coding in PHP and Java for years, and their documentation is
concise, well structured and easy to scan.


Are you mad? Javadoc is one of the worst examples of source code 
documentation I can possibly imagine. I would go as far to say that the 
Python guys should do exactly the opposite of Javadoc.


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

Re: Compare source code

[Lawrence D'Oliveiro]

In message , Grant Edwards wrote:

> On 2010-11-01, Lawrence D'Oliveiro 
> wrote:
>
>> In message <8j8am4fk2...@mid.individual.net>, Peter Pearson wrote:
>>>
 diff -b oldfile newfile
>>> 
>>> Warning: "diff -b" won't detect changes in indentation.  Changes in
>>> indentation can change a Python program.
>>
>> I'm getting less and less keen on that particular feature of Python...
> 
> Why?
> 
> 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”.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python documentation too difficult for beginners

[Terry Reedy]

On 11/2/2010 2:43 PM, Tim Harig wrote:


The real question is what do you want to gain by your posts here.  You
should already know that most groups are, by their very nature, slow to
make changes to the status quo.  The problem tends to be exasperated in
open source projects where any changes mean that people have to donate
their time to make anything happen.  You will in general find two things to
be true:

1. Since they are dontating their time, you will find that people tend to
scratch their own iches first.

2. People who do take the time to contribute to open source projects are
people of action.  They don't tend to be appreciative of those who
constantly generate feature requests but have no inclination to do
any of the work themselves.  They do appreciate other people of
action who are interested in making the project better.

Therefore, if you truly want changes in the documentation, I suggest that,
rather then whining to the group, you make some of the changes yourself.


I agree up to here, with a different interpretation of the last clause.
Work within the existing system. There are currently 250 open doc issues 
on the tracker at bugs.python.org.


After registering, go to the search page
http://bugs.python.org/iss...@template=search&status=1
select Components: Documentation and hit Return (or [Search])

Find an issue that is waiting for someone to suggest a new or 
replacement sentence or paragraph, and make one. No .diff patch 
required, just put it in the message. Or look at existing suggestions 
and comment.


--
Terry Jan Reedy

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

Re: Compare source code

[Lawrence D'Oliveiro]

In message , Emile van 
Sebille wrote:

> On 11/1/2010 4:22 PM Lawrence D'Oliveiro said...
>
>> In message, Emile van
>> Sebille wrote:
>>
>>> At least you can look at python code and _know_ that spurious placement
>>> of required line noise don't have the ability to impact what the code
>>> does.
>>
>> But it does. What is spurious whitespace if not noise, after all?
> 
> But it does so by intent.  Other languages lend only an appearance of
> structure through the indentation style of the writer.

No, the indentation is there to make the structure clearer, not to act as a 
substitute for the structure. Try to conflate the two, and you end up with 
problems such as we are discussing.

> It's as good as outdated comments.

Outdated comments are a bug like any other, and should be fixed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: *** FBI gets a warm welcome in Chicago for their EXCELLENTperformance - cheers to NEW CONS ***

[silver light]

On Nov 2, 1:58 pm, Rich Grise  wrote:
> On Tue, 02 Nov 2010 14:17:29 -0700, Gunner Asch wrote:
>
> > But...shrug..there will be far less after the Great Cull
>
> I think some people might be surprised as to exactly _who_ gets "culled".
>
> Good Luck!
> Rich

On Nov 2, 11:03 am, t...@sevak.isi.edu (Thomas A. Russ) wrote:
> silver light  writes:
> > *** FBI gets a warm welcome in Chicago for their EXCELLENT performance
> > - cheers to NEW CONS ***
>
> Oh geez.  Just when we've beaten back the infix hordes, someone comes up
> and suggests replacing CONS with something, new different and most
> likely inferior.
>
> - Grumpy Old Programmer.
>
> --
> Thomas A. Russ,  USC/Information Sciences Institute

Google censored my post and deleted it not because they are trying to
defend the FBI or cover them up. They just dont like silverlight which
is from Microsoft.

It is well known that google and oracle are trying to get control of
the whole cyberspace either alone or in alliance with each other.

This way they can control the federal government. Most senators and
congressmen are pea brain and go along with whatever the corporations
show them with music, viagra, champagne, food, cruise tickets, girls
and pocket money.

==
Submitted by jkeogh on Tue, 11/02/2010 - 6:44am

http://911blogger.com/news/2010-10-20/foia-funds-request

Litigation seeking the release of never before seen 9/11 FBI records
is currently underway in the federal courts. There is a immediate need
for a FOIA attorney to assist with the case. The defendants are
operating with a nearly unlimited funding and have a large body of
legal experts working to prevent the release of these records. A
public interest FOIA attorney has offered their services at a reduced
public interest rate. We need the research communities help to raise
the required funds. Release of these requested records may help settle
questions surrounding the Pentagon and Shanksville controversies, as
well as others. Release of these records could also help overcome
future claims of release exemption by the FBI for other 9/11 records
requests.




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

Re: *** FBI gets a warm welcome in Chicago for their EXCELLENT performance - cheers to NEW CONS ***

[silver light]

On Nov 2, 11:03 am, t...@sevak.isi.edu (Thomas A. Russ) wrote:
> silver light  writes:
> > *** FBI gets a warm welcome in Chicago for their EXCELLENT performance
> > - cheers to NEW CONS ***
>
> Oh geez.  Just when we've beaten back the infix hordes, someone comes up
> and suggests replacing CONS with something, new different and most
> likely inferior.
>
> - Grumpy Old Programmer.
>
> --
> Thomas A. Russ,  USC/Information Sciences Institute

Google censored my post and deleted it not because they are trying to
defend the FBI or cover them up. They just dont like silverlight which
is from Microsoft.

It is well known that google and oracle are trying to get control of
the whole cyberspace either alone or in alliance with each other.

This way they can control the federal government. Most senators and
congressmen are pea brain and go along with whatever the corporations
show them with music, viagra, champagne, food, cruise tickets, girls
and pocket money.

==
Submitted by jkeogh on Tue, 11/02/2010 - 6:44am

http://911blogger.com/news/2010-10-20/foia-funds-request

Litigation seeking the release of never before seen 9/11 FBI records
is currently underway in the federal courts. There is a immediate need
for a FOIA attorney to assist with the case. The defendants are
operating with a nearly unlimited funding and have a large body of
legal experts working to prevent the release of these records. A
public interest FOIA attorney has offered their services at a reduced
public interest rate. We need the research communities help to raise
the required funds. Release of these requested records may help settle
questions surrounding the Pentagon and Shanksville controversies, as
well as others. Release of these records could also help overcome
future claims of release exemption by the FBI for other 9/11 records
requests.




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

Re: Python documentation too difficult for beginners

[John McMonagle]

On 03/11/10 05:04, John Nagle wrote:

>Right.  Google does a far better job of organizing Python's
> documentation than the Python community does.  I don't even try
> looking up anything starting at Python.org; I always start
> with a Google search.  Even though Python.org's search is
> powered by Google, it's inferior to a general search.
> 
>Compare:
> 
> http://www.google.com/search?domains=www.python.org&sitesearch=www.python.org&q=open
> 
> 
> http://www.google.com/search?q=Python+open
> 


Even better:


http://www.google.com/search?sitesearch=docs.python.org&q=open


Regards,

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

Re: *** FBI gets a warm welcome in Chicago for their EXCELLENTperformance - cheers to NEW CONS ***

[Rich Grise]

On Tue, 02 Nov 2010 14:17:29 -0700, Gunner Asch wrote:
> 
> But...shrug..there will be far less after the Great Cull

I think some people might be surprised as to exactly _who_ gets "culled".

Good Luck!
Rich

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

Re: Trouble with importing

[Ben Ahrens]

I did indeed use the particular revision compiled with the addons.  I
discovered that if I log in as root or make myself a user with full
privileges I can successfully import the rfid module, just not using
sudo.  Of course neither of those options are particularly good ones,
but that's the only way I've gotten it to work thus far.

Ben

On Tue, Nov 2, 2010 at 4:01 PM, Jerry Hill  wrote:
> On Tue, Nov 2, 2010 at 3:33 PM, Ben Ahrens  wrote:
>> Jerry, thanks for the reply, I was swamped with other things for the
>> better part of a week.. Anyway, I tried using the verbose flag when
>> attempting the import.  I didn't see anything that meant anything to
>> me, but here's the bit surrounding the part where it fails:
>>
>> # /usr/lib/python2.6/dist-packages/gnuradio/__init__.pyc matches
>> /usr/lib/python2.6/dist-packages/gnuradio/__init__.py
>> import gnuradio # precompiled from
>> /usr/lib/python2.6/dist-packages/gnuradio/__init__.pyc
>> # /usr/lib/python2.6/re.pyc matches /usr/lib/python2.6/re.py
>> import re # precompiled from /usr/lib/python2.6/re.pyc
>> # /usr/lib/python2.6/sre_compile.pyc matches 
>> /usr/lib/python2.6/sre_compile.py
>> import sre_compile # precompiled from /usr/lib/python2.6/sre_compile.pyc
>> import _sre # builtin
>> # /usr/lib/python2.6/sre_parse.pyc matches /usr/lib/python2.6/sre_parse.py
>> import sre_parse # precompiled from /usr/lib/python2.6/sre_parse.pyc
>> # /usr/lib/python2.6/sre_constants.pyc matches
>> /usr/lib/python2.6/sre_constants.py
>> import sre_constants # precompiled from /usr/lib/python2.6/sre_constants.pyc
>> Traceback (most recent call last):
>>  File "", line 1, in 
>> ImportError: cannot import name rfid
>> # clear __builtin__._
>> # clear sys.path
>> # clear sys.argv
>>
>>
>> As for the permissions, as a bit of a python novice, I wasn't sure
>> whether permissions on the package referred to the gnuradio folder or
>> to something else.  The permissions on the gnuradio folder are
>> drwxr-sr-x.  I have sort of the same problem with the rfid module, but
>> hopefully this gives you the info you were asking about:
>>
>> -rwxr-xr-x 1 root staff   1067 2010-10-14 15:27 _rfid.la
>> -rw-r--r-- 1 root staff  17988 2010-10-14 15:27 rfid.py
>> -rw-r--r-- 1 root staff  30771 2010-10-14 15:27 rfid.pyc
>> -rw-r--r-- 1 root staff  30771 2010-10-14 15:27 rfid.pyo
>> -rwxr-xr-x 1 root staff 939872 2010-10-14 15:27 _rfid.so
>>
>>
>> Thanks again for giving this some thought.  Let me know if you have
>> any other tips!
>
> I'm copying your reply back to the list.  You'll get more and better
> responses if you keep all of the discussion on there.
>
> I don't see anything unusual going on there either.  I do see that the
> project page for gen2_rfid is asking for a particular SVN revision of
> gnuradio with custom edits applied.  Is that how you installed
> gnuradio?  I'm looking at the notes in
> https://www.cgran.org/browser/projects/gen2_rfid/trunk/README.txt and
> https://www.noisebridge.net/wiki/RFID_Hacking/usrp/
>
> --
> Jerry
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: *** FBI gets a warm welcome in Chicago for their EXCELLENTperformance - cheers to NEW CONS ***

[Gunner Asch]

On Tue, 02 Nov 2010 22:13:40 GMT, david.bostw...@chemistry.gatech.edu
(David Bostwick) wrote:

>In article 
><47e0b3a3-54fb-4489-95a8-b5ec6015c...@j25g2000yqa.googlegroups.com>, small Pox 
> wrote:
>[...]
>
>Some WD40 on your keyboard might help keep the Caps Lock key from sticking so 
>often.

The mentally ill often use mostly caps lock key strokes to emphasize
their postings as they rant and rave.

Shrug

Get used to it. 

There are a lot of those poor sick bastards out there.

But...shrug..there will be far less after the Great Cull

Gunner

"Confiscating wealth from those who have earned it, inherited it,
 or got lucky is never going to help 'the poor.' Poverty isn't
 caused by some people having more money than others, just as obesity 
isn't caused by McDonald's serving super-sized orders of French fries
Poverty, like obesity, is caused by the life choices that dictate
results." - John Tucci,
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: *** FBI gets a warm welcome in Chicago for their EXCELLENTperformance - cheers to NEW CONS ***

[David Bostwick]

In article <47e0b3a3-54fb-4489-95a8-b5ec6015c...@j25g2000yqa.googlegroups.com>, 
small Pox  wrote:
[...]

Some WD40 on your keyboard might help keep the Caps Lock key from sticking so 
often.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Ethan Furman]

Grant Edwards wrote:

On 2010-11-02, Ethan Furman  wrote:

Steven D'Aprano wrote:
Personally, I'm more disturbed by the default prompt in the interactive 
interpreter. >>> clashes with the symbol used for quoting text in email 
and news. That causes me far more distress than indentation.


I finally did "sys.ps1 = '--> '" in my interactive startup file.  :)


So _now_ what are going to whinge about?

   ^-
 \
 missing a word?  ;)

If the word is "you" -- how about complaints about the documentation?

elif the word is "we" -- maybe lack of reading comprehension?

elif the word is "Steven" -- absolutely no clue  ;)

else -- maybe multiple inheritance being a bug...
http://bugs.python.org/issue2667

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

Re: Trouble with importing

[Jerry Hill]

On Tue, Nov 2, 2010 at 3:33 PM, Ben Ahrens  wrote:
> Jerry, thanks for the reply, I was swamped with other things for the
> better part of a week.. Anyway, I tried using the verbose flag when
> attempting the import.  I didn't see anything that meant anything to
> me, but here's the bit surrounding the part where it fails:
>
> # /usr/lib/python2.6/dist-packages/gnuradio/__init__.pyc matches
> /usr/lib/python2.6/dist-packages/gnuradio/__init__.py
> import gnuradio # precompiled from
> /usr/lib/python2.6/dist-packages/gnuradio/__init__.pyc
> # /usr/lib/python2.6/re.pyc matches /usr/lib/python2.6/re.py
> import re # precompiled from /usr/lib/python2.6/re.pyc
> # /usr/lib/python2.6/sre_compile.pyc matches /usr/lib/python2.6/sre_compile.py
> import sre_compile # precompiled from /usr/lib/python2.6/sre_compile.pyc
> import _sre # builtin
> # /usr/lib/python2.6/sre_parse.pyc matches /usr/lib/python2.6/sre_parse.py
> import sre_parse # precompiled from /usr/lib/python2.6/sre_parse.pyc
> # /usr/lib/python2.6/sre_constants.pyc matches
> /usr/lib/python2.6/sre_constants.py
> import sre_constants # precompiled from /usr/lib/python2.6/sre_constants.pyc
> Traceback (most recent call last):
>  File "", line 1, in 
> ImportError: cannot import name rfid
> # clear __builtin__._
> # clear sys.path
> # clear sys.argv
>
>
> As for the permissions, as a bit of a python novice, I wasn't sure
> whether permissions on the package referred to the gnuradio folder or
> to something else.  The permissions on the gnuradio folder are
> drwxr-sr-x.  I have sort of the same problem with the rfid module, but
> hopefully this gives you the info you were asking about:
>
> -rwxr-xr-x 1 root staff   1067 2010-10-14 15:27 _rfid.la
> -rw-r--r-- 1 root staff  17988 2010-10-14 15:27 rfid.py
> -rw-r--r-- 1 root staff  30771 2010-10-14 15:27 rfid.pyc
> -rw-r--r-- 1 root staff  30771 2010-10-14 15:27 rfid.pyo
> -rwxr-xr-x 1 root staff 939872 2010-10-14 15:27 _rfid.so
>
>
> Thanks again for giving this some thought.  Let me know if you have
> any other tips!

I'm copying your reply back to the list.  You'll get more and better
responses if you keep all of the discussion on there.

I don't see anything unusual going on there either.  I do see that the
project page for gen2_rfid is asking for a particular SVN revision of
gnuradio with custom edits applied.  Is that how you installed
gnuradio?  I'm looking at the notes in
https://www.cgran.org/browser/projects/gen2_rfid/trunk/README.txt and
https://www.noisebridge.net/wiki/RFID_Hacking/usrp/

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

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

[Zak Kinion]

Hello all,

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);

however, doing will open a new window, but will lose the process id:

e.g.  process1.poll() will always return 0 no matter if the process is
open or not, meaning that python always thinks its closed.
It should return None if the process is still running.

I can do it without using cmd /c start, but then the newly launched
python script is trapped in my original cmd terminal where i launched
the script from in the first place.  I can keep track of the process
now, but the one cmd window open is insufficient to keep track of the
output that a multitude of programs running will produce.  Doing it
without the /c argument will still keep the new script in the same
console.

Yes, I have read I can do this in linux with Konsole or whatever like:
 child = subprocess.Popen("konsole -e python foo.py", shell=True)

however, I need this to run in windows.


Any help or solution is appreciated,


-- 
Zak Kinion
zkin...@gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: *** FBI gets a warm welcome in Chicago for their EXCELLENTperformance - cheers to NEW CONS ***

[small Pox]

If you want to act like a NETCOP then you must identify yourself and
your organization or else you are considered a FACELESS COWARD
CRIMINAL whose sole intent is to carry out CENSORSHIP of truth.

Unless you ACTIVELY apply the same PURSUIT to ALL OTHER IRRELEVANT
postings, you will be considered a STALKER, A CRIMINAL, A RACIST, A
CENSORER, and SUPPRESSOR OF TRUTH and PARTNER CRIMINAL in the CRIME WE
ARE TRYING TO EXPOSE.

On Nov 1, 6:35 pm, Chris Rebert   wrote:

- Hide quoted text -
- Show quoted text -
> > -Original Message-
> > From: silver light 
> > Sender: python-list-bounces+brf256=gmail@python.org
> > Date: Mon, 1 Nov 2010 18:10:36
> > To: 
> > Cc: 
> > Subject: *** FBI gets a warm welcome in Chicago for their EXCELLENT
> >performance - cheers to NEW CONS ***

> > *** FBI gets a warm welcome in Chicago for their EXCELLENT performance
> > - cheers to NEW CONS ***

> 

> On Mon, Nov 1, 2010 at 6:21 PM,   wrote:
> > How exactly does this relate to python?

> It doesn't. It's spam that was apparently also cross-posted to
> sci.math, sci.physics, comp.text.tex, and comp.unix.shell.

IT IS MOST CERTAINLY NOTT a SPAM.

THIS FBI CENSORSHIP MOTHER FOCKER is the REAL SPAMMER AND CRIMINAL who
wants to limit the news of their HEINOUS CRIMES and INCOMPETENCE to be
SPREAD.

The fact is that the real spammers are those who post PORNOGRAPHIC and
COMMERCIAL messages on which the FBI CIA BLACKWATER and MOSSAD mother
fockers masterbate  and  rape their mothers daily.

AND NEVER SPEAK OUT. The truth of 911 bites them like the sting of a
snake and truth it is.

- Hide quoted text -
- Show quoted text -
> I advise reporting the sender, lightsilv...@gmail.com, to Gmail's abuse 
> team:http://mail.google.com/support/bin/request.py?contact_type=abuse

> Cheers,
> Chris


On Nov 2, 1:12 am, Seebs  wrote:
> On 2010-11-02, brf...@gmail.com  wrote:
>
> > How exactly does this relate to python?
>
> 1.  It doesn't.  It's spam.  Duh.
> 2.  Don't respond to spam.
> 3.  Don't top-post.
> 4.  If I see even one more post from you where the entire previous post
> is quoted under your text, I will plonk you.  I warn you now because
> most posters will do the same thing, and you will get very lonely
> once no one bothers to read your posts.
>
> -s
> --
> Copyright 2010, all wrongs reversed.  Peter Seebach / 
> usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and 
> funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get 
> educated!
> I am not speaking for my employer, although they do rent some of my opinions.

If you want to act like a NETCOP then you must identify yourself and
your organization or else you are considered a FACELESS COWARD
CRIMINAL whose sole intent is to carry out CENSORSHIP of truth.

Unless you ACTIVELY apply the same PURSUIT to ALL OTHER IRRELEVANT
postings, you will be considered a STALKER, A CRIMINAL, A RACIST, A
CENSORER, and SUPPRESSOR OF TRUTH and PARTNER CRIMINAL in the CRIME WE
ARE TRYING TO EXPOSE.

I am doing a sandwich posting - its called the BIG MAC ... cheers
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Grant Edwards]

On 2010-11-02, Ethan Furman  wrote:
> Steven D'Aprano wrote:
>> Personally, I'm more disturbed by the default prompt in the interactive 
>> interpreter. >>> clashes with the symbol used for quoting text in email 
>> and news. That causes me far more distress than indentation.
>
> Here here!
>
> I finally did "sys.ps1 = '--> '" in my interactive startup file.  :)

So _now_ what are going to whinge about?

-- 
Grant Edwards   grant.b.edwardsYow! I am NOT a nut
  at   
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Man pages and info pages (was: Python documentation too difficult for beginners)

[Tim Harig]

On 2010-11-02, Tim Harig  wrote:
> On 2010-11-02, Teemu Likonen  wrote:
>> With the text terminal info browser called "info" as well as Emacs' info
>> browser you can use command "s" (stands for "search"). It prompts for a
>> regexp pattern to search in the whole document, including subsections
>> etc.
>
> Right, pinfo offers this as well; but, then you have to figure out where in
> the nodes that the search has taken you and how to navigate from that node
> to find additional information that you may need.  I have, in general, come
> to think of info pages as a failed experiment and I know very few people
> who actually prefer them over the simpler man pages.

I should add two more things here:

1. Another confusing aspect of the info pages is that you often have to
know what package a command came from or you don't get the
information that you are looking for.

2. Series of man pages can be used in a way that seem like they have a
structure as they can effectively link to other pages.  If I open
one of the ncurses man pages in pinfo, I can follow what seem like
links to other man pages.  I can open the main curses page and I
effectively get an index to all of the other curses functions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[rustom]

Sigh! How flame-wars tend to lose the original question:

On Oct 31, 5:02 pm, jf  wrote:
> Hi,
>
> I've a project with tabs and spaces mixed (yes I know it's bad).

Do python aficionados want to suggest that mixing spaces and tabs is a
'good thing'?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Man pages and info pages (was: Python documentation too difficult for beginners)

[Tim Harig]

On 2010-11-02, Teemu Likonen  wrote:
> * 2010-11-02 18:43 (UTC), Tim Harig wrote:
>
>> The manual format contains all of the information on one page that can
>> be easily searched whereas the info pages are split into sections that
>> must be viewed individually. With the man pages, you can almost always
>> find what you want with a quick search through the document. Info
>> pages are much harder to use because you have to try and figure out
>> which section the author decided to place the information that you are
>> looking for.
>
> There is also the problem that people are less familiar with info
> browsers than the usual "less" pager which is used by "man" command.

I thoroughly agree.  The default info viewers are quite possibly the most
counterintuitive programs I have ever encountered.  I never did bother to
learn how to use them.  I instead installed the more intuitive pinfo
program.

> With the text terminal info browser called "info" as well as Emacs' info
> browser you can use command "s" (stands for "search"). It prompts for a
> regexp pattern to search in the whole document, including subsections
> etc.

Right, pinfo offers this as well; but, then you have to figure out where in
the nodes that the search has taken you and how to navigate from that node
to find additional information that you may need.  I have, in general, come
to think of info pages as a failed experiment and I know very few people
who actually prefer them over the simpler man pages.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-02, Grant Edwards  wrote:
> And you think compatibility with your broken e-mail server is a good
> reason to change the syntax of a programming language?

No.  I never said that.

>> Many editors helpfully convert spaces to tabs by default some or all
>> of the time.  And so on.

> Such editors are broken.

If I use an editor for twenty years, and it works beautifully with fifteen
different programming languages across five operating systems, and someone
comes along with a file format which tends to silently break when treated
the same way, my first response is not to blame the editor.

> I think it's brilliant (indentation that actually means something, not
> scanf).

It is.  However, it's also brittle.

>> The "problem" it fixes is something that's hardly ever been a problem
>> for me in C or related languages -- and which could be completely
>> eliminated by automated indenters, which were actually conceptually
>> possible.

> They're only possible if you put redundant block markers in the
> source.

Yes.  Or make the block markers not-redundant.

> Then you're doing something terribly wrong.  I find indentation-based
> structure to be completely effortless.

And it is *ABSOLUTELY CERTAIN* that, if any two people have different
experiences of how easy or hard something is, it's because one of them
is doing something wrong, right?

Because people are *never* actually different.  There is no such thing
as "preferences".  There is no such thing as a "matter of taste".  No,
no.  If one person finds something comfortable, and another dislikes it,
it's because the second one is *doing something terribly wrong*.

> Are you using an editor that
> doesn't have a Python mode?

Yes.  I haven't used "modes" in editors until now.  I've never needed to.
Every other file format I work with is robust about this.

-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

[Seebs]

On 2010-11-02, Grant Edwards  wrote:
> True, but the fact that diff has an option that for Python sources
> will produces useless results doesn't seem like a valid indictment of
> Python's syntax and semantics.

The question is *why* diff has that option.

The answer is because whitespace changes (spaces to tabs, different
tab stops, etcetera) are an extremely common failure mode, such that
it's quite common for files to end up with unintentional whitespace
changes.

This, in turn, is why there are so many tools to automatically fix up
whitespace type issues, such as cb/indent for C, auto-indentation for
many languages (including stuff like XML) features in editors, and so
on -- because it's a common problem.

-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: ANN: PyQt v4.8.1 Released

[Дамјан Георгиевски]

>> PyQt is available under the GPL and a commercial license.
> 
> Surely you mean “proprietary” rather than “commercial”. There is
> nothing about the GPL that prevents “commercial” use.

I think he means a license that *he* sells comercially :)



-- 
дамјан ((( http://damjan.softver.org.mk/ )))

Religion ends and philosophy begins, 
just as alchemy ends and chemistry begins 
and astrology ends, and astronomy begins.

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

Re: Compare source code

[Tim Harig]

On 2010-11-02, Seebs  wrote:
> On 2010-11-02, Steven D'Aprano  wrote:
>> If your 
>> editor changes spaces to tabs, or visa versa, without being told to do so 
>> (either by an explicit command or an obvious setting), then your editor 
>> is broken.
>
> Yes.  But that's the thing -- I *want* that behavior for every other tool,
> file format, or other thing I work with.

I agree with Seebs, Python is the only language I know that promotes
the use of spaces over tabs; 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.

>> If you are stuck with broken mail servers and broken editors and broken 
>> tools because of political reasons, then you have my sympathy. But stop 
>> insisting that everybody has to carry the overhead of your work-arounds 
>> for your broken tools.
>
> I have made no such insistance.  I have not said Python should change.  I
> have not said other people should want what I want.  I'm not the one telling
> other people that editors they've used happily for twenty years without
> any problems are clearly wrong.

Indeed, a simple script is enough to identify how levels are indented and
convert the present indenting to whatever is your preference.

> There are reasons for it to be this way, and I don't object to the
> existence of people who prefer that side of the tradeoff.  I do dislike
> it when people smugly tell me off for having different preferences.

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.
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.

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.  Then it is possible
transition to Python's strengths.  Don't simply ignore that there *are*
potential downfalls to this approach.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python documentation too difficult for beginners

[Kee Nethery]

On Nov 2, 2010, at 11:07 AM, Ian wrote:

> On 02/11/2010 14:47, jk wrote:
>> I think the key difference is that I don't want to have to *read*
>>  the
>> python docs - I want to be able to scan for what I'm looking for and
>> find it easily. That makes me productive.
>> 
> Hi jk, 
> 
> I totally agree. But you will get nowhere. 
> 
> A few weeks back I complained that 
> http://docs.python.org/reference/executionmodel.html#naming-and-binding
> was more than a little opaque - and was not understood by Python noobs such 
> as myself. 
> 
> I was invited to rewrite it and submit an improved version.  

In this world of moderated wikis one would think that noobs such as myself 
could enhance the docs when we find something confusing in the docs. 

Kee

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

Re: Compare source code

[Ethan Furman]

Steven D'Aprano wrote:
Personally, I'm more disturbed by the default prompt in the interactive 
interpreter. >>> clashes with the symbol used for quoting text in email 
and news. That causes me far more distress than indentation.


Here here!

I finally did "sys.ps1 = '--> '" in my interactive startup file.  :)

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

Re: Python documentation too difficult for beginners

[John Nagle]

On 11/2/2010 7:53 AM, Paul Rudin wrote:

Steven D'Aprano  writes:


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.



OTOH googling for "python open" gives you the correct (for 2.7) page as
hit #1 - although you then have to use your browser's "find" facilty to
actually get to the description of the function in question.


   Right.  Google does a far better job of organizing Python's
documentation than the Python community does.  I don't even try
looking up anything starting at Python.org; I always start
with a Google search.  Even though Python.org's search is
powered by Google, it's inferior to a general search.

   Compare:

http://www.google.com/search?domains=www.python.org&sitesearch=www.python.org&q=open

http://www.google.com/search?q=Python+open



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

Man pages and info pages (was: Python documentation too difficult for beginners)

[Teemu Likonen]

* 2010-11-02 18:43 (UTC), Tim Harig wrote:

> The manual format contains all of the information on one page that can
> be easily searched whereas the info pages are split into sections that
> must be viewed individually. With the man pages, you can almost always
> find what you want with a quick search through the document. Info
> pages are much harder to use because you have to try and figure out
> which section the author decided to place the information that you are
> looking for.

There is also the problem that people are less familiar with info
browsers than the usual "less" pager which is used by "man" command.

With the text terminal info browser called "info" as well as Emacs' info
browser you can use command "s" (stands for "search"). It prompts for a
regexp pattern to search in the whole document, including subsections
etc.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python documentation too difficult for beginners

[Ian]

On Nov 2, 8:47 am, jk  wrote:
> You're right in that the python docs in this case are less lines, but
> that's one of the problems. It doesn't mention anywhere the extra
> detail you've added regarding exceptions thrown. That's the kind of
> thing that probably comes through experience or some kind of
> convention which isn't obvious to beginners. Having things split into
> sections - parameters, return types, exceptions, etc - lets me find
> what I'm looking for quickly.

It doesn't mention it because those exceptions don't actually have
anything to do with the id() function.  They're just what happens any
time an unbound variable name is evaluated, in any context.  The exact
same thing could be said about any Python function in existence that
takes at least one argument.

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

Re: Python documentation too difficult for beginners

[Tim Harig]

On 2010-11-02, jk  wrote:
> As for the 9 paragraphs statement, there's a usability book that
> applies here - it's called "Don't make me think". I shouldn't have to

Anything that promotes a lack of thinking sends up red flags in my head.
We want to recruit smart people who think, not idiots.

> go through freeform text to find what I'm looking for when a list
> would make that information easier to find. And splitting the docs
> into sections would allow me to skip to what I'm looking for. I really
> would be much happier with your example documentation.

ctrl-f will bring up a search dialog in most graphical browsers.  '/' will
in many others.  With some practice, your fingers will be able to find
something far faster then your eyes can see it happen.

There is a religious war in the GNU community between info page as
documentation versus the traditional manual format.  The manual format
contains all of the information on one page that can be easily searched
whereas the info pages are split into sections that must be viewed
individually.  With the man pages, you can almost always find what you want
with a quick search through the document.  Info pages are much harder to
use because you have to try and figure out which section the author decided
to place the information that you are looking for.  The information may be
stored several levels deep, which means that it can be a deep productivity
hit if you don't guess the proper location on the first try.

> I think the key difference is that I don't want to have to *read* the
> python docs - I want to be able to scan for what I'm looking for and
> find it easily. That makes me productive.

The real question is what do you want to gain by your posts here.  You
should already know that most groups are, by their very nature, slow to
make changes to the status quo.  The problem tends to be exasperated in
open source projects where any changes mean that people have to donate
their time to make anything happen.  You will in general find two things to
be true:

1. Since they are dontating their time, you will find that people tend to
scratch their own iches first.

2. People who do take the time to contribute to open source projects are
people of action.  They don't tend to be appreciative of those who
constantly generate feature requests but have no inclination to do
any of the work themselves.  They do appreciate other people of
action who are interested in making the project better.

Therefore, if you truly want changes in the documentation, I suggest that,
rather then whining to the group, you make some of the changes yourself.
When you are finished, you can post a link to your alternate documentation
to this group.  If you documentation is truly better then the existing
documentation, you will not have to say another word.  People within the
community will rally around it and promote it.  If it gains wide enough
support, then there will be a movement to use it to supplant the existing
documentation.  It is the difference between whining from the sidelines and
actively participating in the game.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[D'Arcy J.M. Cain]

On Tue, 2 Nov 2010 18:15:03 + (UTC)
Grant Edwards  wrote:
> You can add redundant, semantically empty structure info to Python
> programs just as easily as you can to C programs:
> 
> if foo:
> bar
> else:
> baz
> quux
> #endif

"Redundant" is right.  However, there is a use for such comments:

if foo:
bar
else:
baz
if snafu:
cookie
#endif snafu
quux
#endif foo

Useful in more complicated code, of course.

-- 
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: Compare source code

[D'Arcy J.M. Cain]

On 02 Nov 2010 17:58:06 GMT
Seebs  wrote:
> On 2010-11-02, D'Arcy J.M. Cain  wrote:
> > "No one
> > knows why" email is being "magically" transformed?
> 
> Yay for a large company IT department with both MS and Blackberry
> stuff involved.

"Large" is no excuse for incompetency.

> > Your editor has a
> > mind of its own?  Yikes!
> 
> It is extremely useful to me to have spaces converted to tabs
> for every other file I edit.

So configure it to recognize Python files and act accordingly.

> No, they aren't.  See... That would work *if I knew for sure what the intent
> was*.
> 
>   if foo:
>   bar
>   else:
>   baz
>   quux
> 
> Does it look right?  We have *no idea*, because we don't actually know
> whether quux was *intended* to be in the else branch or whether that's a typo.

And C has the same problem.

if (foo)
bar;
else
baz;

quux;

Is quux meant to be part of the else clause?  The writer's indentation
suggests "yes" but the code says "no".

> So the only way I can figure that out is by fully figuring out the function

Same is true for the C code.  In both cases you can tell what the code
will do (modulo weird macros in the C code) but the intention is
impossible to determine without mind reading abilities in both cases.
We do know that the Python code *appears* to be doing exactly what the
author intended and the C code *appears* to not be.

In either case,  != .

-- 
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: Python documentation too difficult for beginners

[Ian]

On 02/11/2010 14:47, jk wrote:

I think the key difference is that I don't want to have to*read*  the
python docs - I want to be able to scan for what I'm looking for and
find it easily. That makes me productive.

Hi jk,

I totally agree. But you will get nowhere.

A few weeks back I complained that
http://docs.python.org/reference/executionmodel.html#naming-and-binding
was more than a little opaque - and was not understood by Python noobs 
such as myself.


I was invited to rewrite it and submit an improved version.

Remember I said I was a noob and did not understand it. Just how can I 
rewrite it from that base?


But I'm sure that the trouble is with me. It is clear from this 
statement (rom that page)...


"If a name binding operation occurs anywhere within a code block, all 
uses of the name within the block are treated as references to the 
current block."


that, (in the given situation), name binding does not bind a name to a 
variable but to a block.



Just for the record,  I really know it is not me. English is my mother 
tongue, and I have some programming experience, in a variety of 
languages. I wrote my first program in 1964, and have been earning a 
living programming since '74. I have used Cobol, Lisp, Smalltalk, C, 
Javascript, Notes, PHP and many other languages in a commercial 
environment over the last 36 (good gracious!) years.


This lack of documentation is almost universal. You will have heard of 
the "with batteries" tag. This means that, whatever you want to do, 
there are usually many libraries available to help you do it. Every one 
will be poorly documented and most are hard to find. Yes there are 
batteries - but it is not clear which is more productive: write what is 
needed from scratch, or investigate what "batteries" are available and 
risk finding that the one you chose is missing some important feature 
down the line?


Observe though that having poor introductory documentation sells a lot 
of "How to Program in Python" type books.


Its sad really.  Python is a great little language, and deserves better. 
Without an on-ramp, noobs will struggle to get on the freeway.  And yet, 
enough will get on, that these pleas for better documentation can be 
ignored by those who know and could do something about it.


Regards

Ian

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

Re: Compare source code

[Grant Edwards]

On 2010-11-02, Emile van Sebille  wrote:
> On 11/2/2010 10:58 AM Seebs said...
>> No, they aren't.  See... That would work *if I knew for sure what the intent
>> was*.
>>
>>  if foo:
>>  bar
>>  else:
>>  baz
>>  quux
>>
>> Does it look right?  We have *no idea*, because we don't actually know
>> whether quux was *intended* to be in the else branch or whether that's a 
>> typo.
>
> What is right is that there's no question that quux is subsequent to baz 
> in all cases barring exceptions (and assuming no tabs intermixed)
>
> The apparent structure in python _is_ the structure, whereas otherwise 
> you've got to count your ;'s and {}'s etc to determine and verify the 
> structure matches the apparent structure provided by the programmer.
>
> Whether that's what the specs called for or not is always a source
> for bugs.

Yup.  I've never found that the ability to write incorrect code that
_appears_ correct to be a good thing.  Nor do I find the ability to
write correct code that appears to be incorrect to be valuable.

In Python, if the structure looks right, then structure _is_ right.

-- 
Grant Edwards   grant.b.edwardsYow! Now we can become
  at   alcoholics!
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Grant Edwards]

On 2010-11-02, Seebs  wrote:
> On 2010-11-02, D'Arcy J.M. Cain  wrote:
>> You have problems.  Indentation as syntax isn't one of them.
>
> In the absence of indentation as syntax, they haven't bugged me.
>
>> "No one
>> knows why" email is being "magically" transformed?
>
> Yay for a large company IT department with both MS and Blackberry
> stuff involved.
>
>> Your editor has a
>> mind of its own?  Yikes!
>
> It is extremely useful to me to have spaces converted to tabs
> for every other file I edit.
>
>>> I've lost more time to indentation issues in Python in a month than
>>> I've lost to mismatches between indentation and flow in C in twenty
>
>> Your experience is 180 from mine.
>
> Could be.  But really, I've simply never seen a real problem with
> flow/indentation mismatches in C.
>
>>> At least in C, if I see:
>>> if (foo)
>>> a;
>>> else
>>> b;
>>> c;
>>> 
>>> I *know* that something is wrong.
>
>> Does it look right?  With Python looking right and being right are the
>> same thing.
>
> No, they aren't.  See... That would work *if I knew for sure what the intent
> was*.
>
>   if foo:
>   bar
>   else:
>   baz
>   quux
>
> Does it look right?  We have *no idea*, because we don't actually know
> whether quux was *intended* to be in the else branch or whether that's a typo.
>
> So the only way I can figure that out is by fully figuring out the function
> of all the code bits -- meaning I have to fully understand the code, same
> as I would to debug the C.  The fact that indentation is flow control
> just means I have only one set of cues, so I can't watch for mismatches.

You can add redundant, semantically empty structure info to Python
programs just as easily as you can to C programs:

if foo:
bar
else:
baz
quux
#endif


-- 
Grant Edwards   grant.b.edwardsYow! With YOU, I can be
  at   MYSELF ...  We don't NEED
  gmail.comDan Rather ...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Emile van Sebille]

On 11/2/2010 10:58 AM Seebs said...

No, they aren't.  See... That would work *if I knew for sure what the intent
was*.

if foo:
bar
else:
baz
quux

Does it look right?  We have *no idea*, because we don't actually know
whether quux was *intended* to be in the else branch or whether that's a typo.


What is right is that there's no question that quux is subsequent to baz 
in all cases barring exceptions (and assuming no tabs intermixed)


The apparent structure in python _is_ the structure, whereas otherwise 
you've got to count your ;'s and {}'s etc to determine and verify the 
structure matches the apparent structure provided by the programmer.


Whether that's what the specs called for or not is always a source for bugs.

Emile




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

Re: Compare source code

[Seebs]

On 2010-11-02, Steven D'Aprano  wrote:
> I've lost more time to reading people's bitching about indentation than I 
> have dealing with indentation problems.

Doesn't totally surprise me.  :)

> But then, I don't insist on using tools which are broken by design.

Neither do I.

> If your email server converts plain text to HTML, it is broken.

Yup.  I have an open ticket with the IT department.  :)

> If your 
> editor changes spaces to tabs, or visa versa, without being told to do so 
> (either by an explicit command or an obvious setting), then your editor 
> is broken.

Yes.  But that's the thing -- I *want* that behavior for every other tool,
file format, or other thing I work with.

> If you are stuck with broken mail servers and broken editors and broken 
> tools because of political reasons, then you have my sympathy. But stop 
> insisting that everybody has to carry the overhead of your work-arounds 
> for your broken tools.

I have made no such insistance.  I have not said Python should change.  I
have not said other people should want what I want.  I'm not the one telling
other people that editors they've used happily for twenty years without
any problems are clearly wrong.

I have merely observed that Python is, in this respect, gratuitously
brittle.  It doesn't observe the robustness principle; it is
conservative in what it accepts, and in particular, is vulnerable to a
category of problem which is fairly common, well-known, and likely to
remain common for the next few decades.

There are reasons for it to be this way, and I don't object to the
existence of people who prefer that side of the tradeoff.  I do dislike
it when people smugly tell me off for having different preferences.

-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

[Seebs]

On 2010-11-02, D'Arcy J.M. Cain  wrote:
> You have problems.  Indentation as syntax isn't one of them.

In the absence of indentation as syntax, they haven't bugged me.

> "No one
> knows why" email is being "magically" transformed?

Yay for a large company IT department with both MS and Blackberry
stuff involved.

> Your editor has a
> mind of its own?  Yikes!

It is extremely useful to me to have spaces converted to tabs
for every other file I edit.

>> I've lost more time to indentation issues in Python in a month than
>> I've lost to mismatches between indentation and flow in C in twenty

> Your experience is 180 from mine.

Could be.  But really, I've simply never seen a real problem with
flow/indentation mismatches in C.

>> At least in C, if I see:
>>  if (foo)
>>  a;
>>  else
>>  b;
>>  c;
>> 
>> I *know* that something is wrong.

> Does it look right?  With Python looking right and being right are the
> same thing.

No, they aren't.  See... That would work *if I knew for sure what the intent
was*.

if foo:
bar
else:
baz
quux

Does it look right?  We have *no idea*, because we don't actually know
whether quux was *intended* to be in the else branch or whether that's a typo.

So the only way I can figure that out is by fully figuring out the function
of all the code bits -- meaning I have to fully understand the code, same
as I would to debug the C.  The fact that indentation is flow control
just means I have only one set of cues, so I can't watch for mismatches.

-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 equivalent of SOAP-ISIWoK

[John Nagle]

On 11/2/2010 1:58 AM, Johann Spies wrote:

SOAP-ISIWoK is a Perl library for assessing Thomson Reuters Web of
Knowledge Web Services.  I don't know Perl well enough to use that
library without spending too much time on it.

Is there a Python equivalent available?


   The "Suds" library can call SOAP interfaces, and is not difficult
to use.

https://fedorahosted.org/suds/


Regards
Johann
--
 May grace and peace be yours in abundance through the full knowledge
of God and of Jesus our Lord!  His divine power has given us
everything we need for life and godliness through the full knowledge
of the one who called us by his own glory and excellence.
2 Pet. 1:2b,3a


   God helps those who help themselves.
   Benj. Franklin





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

Re: functions, list, default parameters

[Paul Rudin]

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.



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

Re: Python documentation too difficult for beginners

[Terry Reedy]

On 11/2/2010 6:42 AM, jk wrote:


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).


duh. 'open' is a common word and if you make an unstructured search for 
it in all text, you should get a lot of hits.


The Python docs have both a Global Module Index (which I use constantly) 
and a General Index of functions (methods), classes, and terms. Learn to 
use them. If you look in the [o] section for 'open', the first entry is 
"open() (built-in function)" -- just what you were looking for. There 
are also about 30 more nicely labelled entries for 'open' in various 
modules.


> 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.


It is possible that this particular entry could be improved.


Is there much chance that the Python maintainers will change their
documentation system to make it more like Java or PHP?


There are plans to make doc feedback from users easier.

--
Terry Jan Reedy

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

Re: functions, list, default parameters

[Ian]

On Nov 2, 5:59 am, Steven D'Aprano  wrote:
> Certainly it's the mediocre programmers who seem to be incapable of
> understanding that Python has no way of telling whether arbitrary objects
> are mutable or not.
>
> def foo(x, y=list()):
>     pass
>
> Is y a mutabledefaultor not?
>
> For the benefit of any mediocre programmers out there, be careful before
> you answer. This *is* a trick question.

I fail to see your point.  You might as well argue that Python has no
way of knowing whether it should raise a TypeError in the following
example:

my_tuple = (1, 2, 3) + list(xrange(4, 7))

Dynamic typing means that these sorts of checks must be delayed until
runtime, but that doesn't make them useless or impossible.

It seems to me that there is a rather simple case to be made for
allowing mutable default arguments: instances of user-defined classes
are fundamentally mutable.  Disallowing mutable default arguments
would mean disallowing instances of user-defined classes entirely.
That would be excessive and would violate Python's general rule of
staying out of the programmer's way.

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

Re: functions, list, default parameters

[Robert Kern]

On 11/2/10 2:12 AM, Lawrence D'Oliveiro wrote:

In message, Robert Kern
wrote:


On 2010-11-01 22:31 , Lawrence D'Oliveiro wrote:


In message<8j1seqfa1...@mid.individual.net>, Gregory Ewing wrote:


Steven D'Aprano wrote:


And how does Python know whether some arbitrary default object is
mutable or not?


It doesn't, that's the whole point.


Of course it knows. It is the one defining the concept in the first
place, after all.


No, the Python interpreter doesn't define the concept. The Python language
developers did.


The Python language developers said “let there be light”, and the Python
interpreter gave forth light. So which one defines the concept of “light”?


I'm sorry, but that's not even a meaningful reply. They said no such thing and 
the interpreter does no such thing. Let's talk about things the developers did 
say and the things the interpreter does do, shall we?


The Python language developers defined the concept of mutable objects. However, 
they defined it in human terms, not algorithmic ones. They did not imbue the 
interpreter with a way of determining immutability.



"Immutable objects" are just those without an obvious API for modifying
them.


They are ones with NO legal language constructs for modifying them. Hint: if
a selector of some part of such an object were to occur on the LHS of an
assignment, and that would raise an error, then the object is immutable. The
interpreter already knows all this.


Incorrect. RHS method calls can often modify objects. set.add() mutates the set 
even though it does not have the usual LHS mutation methods like .__setitem__(). 
And even among the LHS APIs, raising an error does not determine immutability. 
int.__iadd__() does not raise an error, but ints are still immutable. 
list.__iadd__() does not raise an error, and lists are mutable. And even if it 
were reliable, how would the interpreter know what arguments to pass? 
list.__iadd__() doesn't work for any object. And why do you think that testing 
mutability in such a way would be safe since attempting those would necessarily 
alter the object if it is mutable?


Show me the algorithm that the interpreter can use to determine whether or not 
an object is mutable. Or better, since you think the interpreter already knows 
this, show me the implementation in the interpreter's source code.



With various trickeries, I can mutate any immutable object.


None within the Python language itself. Which is what we’re talking about
here: a language construct which is probably one of the top 3 sources of
grief to Python newbies. And not-so-newbies.


"import ctypes" is within the Python language.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Re: functions, list, default parameters

[Terry Reedy]

On 11/2/2010 3:12 AM, Lawrence D'Oliveiro wrote:


"Immutable objects" are just those without an obvious API for modifying
them.


After initial creation ;-)/


They are ones with NO legal language constructs for modifying them.


Suppose I write an nasty C extension that mutates tuples. What then 
would be illegal about


import tuple_mutator
t = (1,2)
tuple_mutator.inc(t)
t
# (2,3)

> Hint: if

a selector of some part of such an object were to occur on the LHS of an
assignment, and that would raise an error, then the object is immutable.


I am not sure what you are saying here, and how it applies to

>>> lt = [(0,)]
>>> lt[0][0] = 1
Traceback (most recent call last):
  File "", line 1, in 
lt[0][0] = 1
TypeError: 'tuple' object does not support item assignment
>>> tl = ([0],)
>>> tl[0][0] = 1
>>> tl
([1],)


--
Terry Jan Reedy

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

Re: factorial of negative one (-1)

[Terry Reedy]

On 11/2/2010 6:11 AM, Hrvoje Niksic wrote:


1.1 .hex()

'0x1.1999ap+0'

Here it is immediately obvious that the final digit of the infinite
sequence "1.1999..." is rounded from 9 to a.  Printing the number with
any more digits would just reveal zeros, as expected.

Does anyone know why Python doesn't accept hex float literals in source
code?


Assuming that the parser would have no problem with them:
1. the format is relatively recent
2. you can write float.fromhex('')
3. it never occurred to anyone to do so
4. literals are values supplied by the programmer; hex float values are 
rare and when they do occur, they are usually the stored output of a 
previous .hex() in Python or similar in other languages.

5. too easy to confuse in quick reading with normal float literals
6. the format is a bit weird and too esoteric for most programmers; they 
should not be part of the basic syntax that everyone has to learn; 
someone who reads float.fromhex(something) can look it up.


--
Terry Jan Reedy

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

Re: Why this result with the re module

[John Bond]

On 2/11/2010 12:19 PM, Yingjie Lan wrote:

From: John Bond
Subject: Re: Why this result with the re module

Firstly, thanks a lot for your patient explanation.
this time I have understood all your points perfectly.

Secondly, I'd like to clarify some of my points, which
did not get through because of my poor presentation.

I suggested findall return a tuple of re.MatchObject(s),
with each MatchObject instance representing a match.
This is consistent with the re.match() function anyway.
And it will eliminate the need of returning tuples,
and it is much more precise and information rich.

If that's not possible, and a tuple must be returned,
then the whole match (not just subgroups) should
always be included as the first element in the tuple,
as that's group(0) or '\0'. Less surprise would arise.

Finally, it seems to me the algo for findall is WRONG.

To re.findall('(.a.)*', 'Mary has a lamb'),
by reason of greediness of '*', and the requirement
of non-overlapping, it should go like this
(suppose an '' is at the beginning and at the end,
and between two consecutive characters there is
one and only one empty string ''. To show the
match of empty strings clearly,
I am concatenating each repeated match below):

Steps for re.findall('(.a.)*', 'Mary has a lamb'):

step 1: Match '' + 'Mar' + '' (gready!)
step 2: skip 'y'
step 3: Match ''
step 4: skip ' '
step 5: Match ''+'has'+' a '+'lam'+'' (greedy!)
step 6: skip 'b'
step 7: Match ''

So there should be exactly 4 matches in total:

'Mar', '', 'has a lam', ''

Also, the matches above shows
that if a repeated subgroup only captures
the last match, the subgroup (.a.)*
should always capture '' here (see steps
1, 3, 5, 7) above.

Yet the execution in Python results in 6 matches!
And, the capturing subgroup with repetition
sometimes got the wrong guy.

So I believe the algorithm for findall must be WRONG.

Regards,

Yingjie

At a guess, I'd say what is happening is something like this:

Steps for re.findall('(.a.)*', 'Mary has a lamb'):

step 1: Match 'Mar' at string index 0
step 2: Match '' at string index 3 (before 'y')
step 3: skip 'y'
step 4: Match '' at string index 4 (before ' ')
step 5: skip ' '
step 6: Match 'has a lam' at string index 5
step 7: Match '' at string index 14 (before 'b')
step 8: skip 'b'
step 9: Match '' at string index 15 (before EOS)



matches: ('Mar', '', '', 'has a lam', '', '')
returns: ['Mar', '', '', 'lam', '', ''] (*)

(*) "has a " lost due to not being last repetition at that match point

Which seems about right to me! Greediness has nothing to do with it, except 
that it causes 'has a lam' to be matched in one match, instead of as three 
separate matches (of 'has', ' a ' and 'lam').


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

Re: Python documentation too difficult for beginners

[Bruno Desthuilliers]

jk a écrit :

Hi,

I've been coding in PHP and Java for years, and their documentation is
concise, well structured and easy to scan.

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).


Totally unrelated, but the last example is nothing but a reference - 
xahlee is one of the worst internet troll ever.




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


Sorry but as far as I'm concerned, PHP doc sucks big time, and I find 
Javadoc-style stuff close to useless.



(snip)


Has anyone else struggled while trying to learn the language?


Not as far as I'm concerned. I found Python the easiest language to 
learn right from the beginning. Not to say the doc couldn't be improved, 
or that alternate documentations could help, but I never had any problem 
with it.



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

Re: extracting variables accessed and written from function / rule-based function calls

[Daniel]

> >> You might be interested by the story of how AstraZeneca tackled that
> >> kind of problem in PyDrone:http://www.python.org/about/success/astra/
that is interesting! So it seems they store the values in a
dictionary.
For each value they associate a function that gets called when the
value is not available.
This function uses the same dictionary to access the other values,
which might trigger more evaluations.
I like this approach. Unfortunately in my case it would not work,
because I might have more than one rule associated with each function,
depending on which values are available. If the wrong rule gets called
which needs to call other (wrong) rules I could end up in a loop, even
though everything
could be computed in principle.
lets say a follows from b or c (r1, r2) , b follows from a or c (r3,
r4) and c is given. Using this approach I would end up in a loop of
rules r1 and r3 to compute a.
I don't see how this approach could be made to work the other way
round, each value could have a rule attached that, given the
availability of other dependencies computes the
dependent values. That seems complicated, because one rule would need
to be associated with several values.

One possibility I thought of was to write the rules as python
functions and use the ast module to extract all the variables that are
being referenced. In principle this should be
possible. Is there any library around that does that?


Dan

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