Re: Why this result with the re module
> From: John Bond
> re.findall('(.a.)+', 'Mary has a lamb')
> > ['Mar', 'lam']
> It's because you're using capturing groups, and because of
> how they work - specifically they only return the LAST match
> if used with repetition (and multiple matches occur).
It seems capturing groups is assumed by default,
but this is somehow against my intuition...
Ituitively, it should be what matches the
whole regex '(.a.)+', shouldn't it?
Regards,
Yingjie
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why this result with the re module
> From: John Bond
> Subject: Re: Why this result with the re module
> re.findall('(.a.)*', 'Mary has a lamb')
> > ['Mar', '', '', 'lam', '', '']
> So - see if you can explain the first "problematic" result
> now.
Thanks a lot for explaining to me the second "problematic" result!
But the first one is even more puzzling...mainly because the
pattern matches any empty string. Here are more examples:
>>> re.findall('(.a.)*','')
['']
>>> re.findall('(.a.)*',' ') #one space
['', '']
>>> re.findall('(.a.)*',' ') #two spaces
['', '', '']
>>> len(re.findall('(.a.)*',' '*4)) #four
5
>>> len(re.findall('(.a.)*',' '*8)) #eight
9
I must need more details of the matching algorithm to explain this?
Regards,
Yingjie
--
http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
In message , Seebs wrote: > At least in C, if I see: >if (foo) >a; >else >b; >c; > > I *know* that something is wrong. This is why, when I started learning Python, I soon developed the habit of inserting explicit “#end” markers. To Pythonize your example my way, it would have come out as if foo : a else : b #end if c which should also give a hint that something might be wrong. -- http://mail.python.org/mailman/listinfo/python-list
Re: functions, list, default parameters
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”? > "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. > 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: functions, list, default parameters
On Fri, Oct 22, 2010 at 12:36 AM, Steven D'Aprano wrote: > On Thu, 21 Oct 2010 19:53:53 -0700, John Nagle wrote: >>> This is a common newbie stumbling-block: Don't use lists (or anything >>> mutable) as default argument values >> >> That really should be an error. > > No it shouldn't. Punishing everybody for a newbie mistake that nobody > makes twice would be the error. > > Default mutable arguments have their place But it's a rather obscure one where it is almost never strictly necessary to venture. Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Why this result with the re module
On 2/11/2010 7:00 AM, Yingjie Lan wrote:
re.findall('(.a.)*',' ') #two spaces
['', '', '']
I must need more details of the matching algorithm to explain this?
Regards,
Yingjie
Sorry - I hit enter prematurely on my last message.
To take the above as an example (all your examples boil down to the same
issue), you're asking findall to look for all occurances of something
that can exist ZERO or more times, in a string where it doesn't actually
exist anywhere. So you get three matches of zero occurrences each - one
before the first space, one between the two spaces, and one after the
last space. An empty string (indicating that the match consumed no
text) is returned for each. The spaces themselves don't match because
they aren't zero or more occurrences of '.a.', so they are skipped.
You might wonder why something that can match no input text, doesn't
return an infinite number of those matches at every possible position,
but they would be overlapping, and findall explicitly says matches have
to be non-overlapping.
Cheers, JB
--
http://mail.python.org/mailman/listinfo/python-list
Re: *** FBI gets a warm welcome in Chicago for their EXCELLENTperformance - cheers to NEW CONS ***
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.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
Python equivalent of SOAP-ISIWoK
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? 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why this result with the re module
> From: John Bond
> You might wonder why something that can match no input
> text, doesn't return an infinite number of those matches at
> every possible position, but they would be overlapping, and
> findall explicitly says matches have to be non-overlapping.
That scrabbed my itches, though the notion of overlapping
empty strings is quite interesting in itself. Obviously
we have to assume there is one and only one empty string
between two consecutive characters.
Now I slightly modified my regex, and it suddenly looks
self-explanatory:
>>> re.findall('((.a.)+)', 'Mary has a lamb')
[('Mar', 'Mar'), ('has a lam', 'lam')]
>>> re.findall('((.a.)*)', 'Mary has a lamb')
[('Mar', 'Mar'), ('', ''), ('', ''), ('has a lam', 'lam'), ('', ''), ('', '')]
BUT, but.
1. I expected findall to find matches of the whole
regex '(.a.)+', not just the subgroup (.a.) from
>>> re.findall('(.a.)+', 'Mary has a lamb')
Thus it is probably a misunderstanding/bug??
2. Here is an statement from the documentation on
non-capturing groups:
see http://docs.python.org/dev/howto/regex.html
"Except for the fact that you can’t retrieve the
contents of what the group matched, a non-capturing
group behaves exactly the same as a capturing group; "
Thus, I'm again confused, despite of your
previous explanation. This might be a better
explanation: when a subgroup is repeated, it
only captures the last repetition.
3. It would be convenient to have '(*...)' for
non-capturing groups -- but of course, that's
only a remote suggestion.
4. By reason of greediness of '*', and the concept
of non-overlapping, it should go like this 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 7: skip 'b'
step 8: Match ''
So there should be 4 matches in total:
'Mar', '', 'has a lam', ''
Also, if a repeated subgroup only captures
the last repetition, the repeated
subgroup (.a.)* should always be ''.
Yet the execution in Python results in 6 matches.
Here is the documentation of re.findall:
findall(pattern, string, flags=0)
Return a list of all non-overlapping matches in the string.
If one or more groups are present in the pattern, return a
list of groups; this will be a list of tuples if the pattern
has more than one group.
Empty matches are included in the result.
Thus from
>>> re.findall('(.a.)*', 'Mary has a lamb')
I should get this result
[('',), ('',), ('',), ('',)]
Finally, The name findall implies all matches
should be returned, whether there are subgroups in
the pattern or not. It might be best to return all
the match objects (like a re.match call) instead
of the matched strings. Then there is no need
to return tuples of subgroups. Even if tuples
of subgroups were to be returned, group(0) must
also be included in the returned tuple.
Regards,
Yingjie
--
http://mail.python.org/mailman/listinfo/python-list
Re: functions, list, default parameters
In message , Chris Rebert wrote: > On Fri, Oct 22, 2010 at 12:36 AM, Steven D'Aprano > wrote: >> >> Default mutable arguments have their place > > But it's a rather obscure one where it is almost never strictly > necessary to venture. Mediocre programmers with a hankering towards cleverness latch onto it as an ingenious way of maintaing persistent context in-between calls to a function, completely overlooking the fact that Python offers much more straightforward, comprehensible, flexible, and above all maintainable ways of doing that sort of thing. -- http://mail.python.org/mailman/listinfo/python-list
how to sync file on client and server
I want to sync the file foder in different server,and I can't use ftp protocl. I try to sync files during defferent server and not use username and password to login. Anyone has good ideas? -- http://mail.python.org/mailman/listinfo/python-list
Re: playful coding problems for 10 year olds
On Nov 1, 8:31 pm, Daniel Fetchinson wrote: > Hi folks, > > My niece is interested in programming and python looks like a good > choice (she already wrote a couple of lines :)) She is 10 and I > thought it would be good to have a bunch of playful coding problems > for her, stuff that she could code herself maybe after some initial > help. > > Do you guys know problems like these? Or a good resource where to look them > up? > > Cheers, > Daniel > > -- > Psss, psss, put it down! -http://www.cafepress.com/putitdown There's a great book valled 'Invent your own computer games using Python', aimed at kids, which teaches programming from tne ground up, in the context of writing games, starting with terminal word games, ending with Pygame fullscreen 2D vector graphic & bitmaps affairs. http://inventwithpython.com/ The website says aimed at kids 'ages 10 to 12 and upwards', so it sounds like she's on the minimum cusp. (now I come to look at the website, one of the quotes he features is from an Amazon review I wrote months ago! :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: [Beginer Question] I heard about python needing somesort of_VariableName_ boiler plate?
Its the entry point if the script is executed directly. This message was sent from my 7 years old Dell D800 (without cables) Am 01.11.2010 19:18, schrieb brad...@hotmail.com: Sorry that is what I mean. What is it for? Sent wirelessly from my BlackBerry. -Original Message- From: MRAB Sender: python-list-bounces+bradenf=hotmail@python.org Date: Mon, 01 Nov 2010 17:33:22 To: Reply-To: python-list@python.org Subject: Re: [Beginer Question] I heard about python needing some sortof_VariableName_ boiler plate? On 01/11/2010 04:51, Ben Finney wrote: brad...@hotmail.com writes: Sorry, to clarify I heard that when you declare a variable in python you have to use some sort of standard boiler plate _variable_ however this has not been my experience using IDLE so is this even true? I don't know what “some sort of boiler plate _variable_” might mean. Can you point to someone's actual message saying this, so we can see what they might be talking about? Perhaps the OP means: if __name__ == "__main__": ... although the "declare a variable" bit has me puzzled. -- http://mail.python.org/mailman/listinfo/python-list
Re: factorial of negative one (-1)
Ken Watford writes: > 1.1 .as_integer_ratio() >> (2476979795053773, 2251799813685248) > > Handy, but if you need the exact representation, my preference is > float.hex, which seems to be the same as C99's %a format. [...] > Granted, it's not as easy for humans to interpret, but it's useful for > certain things. Since it's used by both C99 and Java, supporting it is a nice interoperability feature: http://download.oracle.com/javase/6/docs/api/java/lang/Double.html#toHexString(double) In fact, the float output provides educational insight of its own because it shows rounding effects without the apparent "garbage digits" syndrome: >>> 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: Why this result with the re module
On 2/11/2010 8:53 AM, Yingjie Lan wrote:
BUT, but.
1. I expected findall to find matches of the whole
regex '(.a.)+', not just the subgroup (.a.) from
re.findall('(.a.)+', 'Mary has a lamb')
Thus it is probably a misunderstanding/bug??
Again, as soon as you put a capturing group in your expression, you
change the nature of what findall returns as described in the
documentation. It then returns what gets assigned to each capturing
group, not what chunk of text was matched by the whole expression at
each matching point in the string.
A capturing group returns what was matched by the regex fregment *inside
it*. If you put repetition *outside it* (as you have - "(.a.)*+*") that
doesn't change but, if the repetition clause results in it being matched
multiple times, only the last match is returned as the capturing groups
single, only allowed return value.
I find that strange, and limiting (why not return a list of all matches
caused by the repetition?) but that's the way it is.
Have you read the "Regular Exp[ression HOWTO" in the docs? It explains
all this stuff.
2. Here is an statement from the documentation on
non-capturing groups:
see http://docs.python.org/dev/howto/regex.html
"Except for the fact that you can’t retrieve the
contents of what the group matched, a non-capturing
group behaves exactly the same as a capturing group; "
In terms of how the regular expression works when matching text, which
is what the above is addressing, that's true. In terms of how the
results are returned to API callers, it isn't true.
Thus, I'm again confused, despite of your
previous explanation. This might be a better
explanation: when a subgroup is repeated, it
only captures the last repetition.
That's true, but it's not related to the above.
3. It would be convenient to have '(*...)' for
non-capturing groups -- but of course, that's
only a remote suggestion.
Fair enough - each to their own preferences.
4. By reason of greediness of '*', and the concept
of non-overlapping, it should go like this 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 7: skip 'b'
step 8: Match ''
So there should be 4 matches in total:
'Mar', '', 'has a lam', ''
Also, if a repeated subgroup only captures
the last repetition, the repeated
subgroup (.a.)* should always be ''.
Yet the execution in Python results in 6 matches.
.
All you have done is wrapped one of your earlier regexes, '*(*.a.*)**'
in another, outer capturing group, to make '*(*(.a.)**)*'. This doesn't
change what is actually matched, so there are still the same six matches
found. However it does change what is *returned *- you now have two
capturing groups that findall has to return information about (at each
match), so you will see that it returns 6 tuples (each with two items -
one for each capturing group) instead of six strings, ie:
re.findall('(.a.)*', 'Mary has a lamb')
['Mar', '', '', 'lam', '', '']
becomes:
re.findall('((.a.)*)', 'Mary has a lamb')
[('Mar', 'Mar'), ('', ''), ('', ''), ('has a lam', 'lam'), ('', ''),
('', '')]
As you can see, the top set of results appear in the bottom set (in the
second item in each tuple, because the original capturing group is the
second one now - the new, outer one is the first).
If you look at the fourth tuple, ('has a lam', 'lam'), you can see the
"capturing group with repetition only returns the last match" rule in
action. The inner capturing group (which has repetition) returns 'lam'
because that was the last occurrence of ".a." in the three ("has", " a
", "lam") that it matched that time. However the outer capturing group,
which doesn't have repetition, returns the whole thing ('has a lam').
Finally, The name findall implies all matches
should be returned, whether there are subgroups in
the pattern or not. It might be best to return all
the match objects (like a re.match call) instead
of the matched strings. Then there is no need
to return tuples of subgroups. Even if tuples
of subgroups were to be returned, group(0) must
also be included in the returned tuple.
Regards,
Yingjie
All matches are returned by findall, so I don't understand that.
I really do suggest that you read the above-mentioned HOWTO, or any of
the numerous tutorials on the net. Regexes are hard to get your head
around at first, not helped by a few puzzling API design choices, but
it's worth the effort, and those will be far more useful than lots of
typed explanations here.
--
http://mail.python.org/mailman/listinfo/python-list
Mail Merge from python data
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). 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? -- "The UNIX system has a command, nice ... in order to be nice to the other users. Nobody ever uses it." - Andrew S. Tanenbaum -- http://mail.python.org/mailman/listinfo/python-list
Python documentation too difficult for beginners
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). 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). 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. The latter has clearly delineated, standardised content areas for each of these without excessive text. It uses tables which are easy to scan for possible opening modes and allows users to contribute their own examples. Sadly, the use of restructured text by python doesn't allow a new document generator to be written - all existing documentation would need updating with docblocks or something similar. Has anyone else struggled while trying to learn the language? The whole documentation system seems geared towards people who already know what they're looking for and is close to useless for beginners. I'm not the only one who finds google an easier way to find documentation about python. Is there much chance that the Python maintainers will change their documentation system to make it more like Java or PHP? How would I go about trying to make that happen? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python documentation too difficult for beginners
If you are really beginner in python you can look into the dive into python,search as in google as the same its quite helpful for beginners.Also you can go for the byte of python. CHEERS CNA 9986229891 On Tue, Nov 2, 2010 at 4:42 PM, jk wrote: > 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). > > 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). 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. > > The latter has clearly delineated, standardised content areas for each > of these without excessive text. It uses tables which are easy to scan > for possible opening modes and allows users to contribute their own > examples. > > Sadly, the use of restructured text by python doesn't allow a new > document generator to be written - all existing documentation would > need updating with docblocks or something similar. > > Has anyone else struggled while trying to learn the language? The > whole documentation system seems geared towards people who already > know what they're looking for and is close to useless for beginners. > I'm not the only one who finds google an easier way to find > documentation about python. > > Is there much chance that the Python maintainers will change their > documentation system to make it more like Java or PHP? How would I go > about trying to make that happen? > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On Mon, 01 Nov 2010 22:24:03 +, Grant Edwards wrote: > On 2010-11-01, Lawrence D'Oliveiro > wrote: [...] >> 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. > > For exmaple, if you remove all of the curly-braces from two C source > files before comparing them, you don't get useful results. Ah, but other languages don't make the guarantee that you can add or remove random whitespace in arbitrary places and still have code that works correctly! Of course, neither does Python, but there's a certain type of personality that is never happy unless they are bitching and moaning, and if they can't find something more substantial to bitch and moan about, they'll bitch and moan about the fact that they can't make random changes to syntactically significant tokens in their source code without things breaking. Boo hoo, cry me a river. 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. Doing a bit of my own bitching and moaning'ly y'rs, -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Allowing comments after the line continuation backslash
On Tue, 02 Nov 2010 11:16:46 +1300, Lawrence D'Oliveiro wrote:
> In message <4cce6ff6.2050...@v.loewis.de>, Martin v. Loewis wrote:
>
>> (in fact, I can't think any situation where I would use the backslash).
>
> for \
> Description, Attr, ColorList \
> in \
> (
> ("normal", "image", MainWindow.ColorsNormalList),
> ("highlighted", "highlight",
> MainWindow.ColorsHighlightedList), ("selected", "select",
> MainWindow.ColorsSelectedList),
> ) \
> :
>...
> #end for
If it were your intention to show why backslashes should be avoided, you
succeeded admirably.
The above can be written much more cleanly as:
for Description, Attr, ColorList in (
("normal", "image", MainWindow.ColorsNormalList),
("highlighted", "highlight", MainWindow.ColorsHighlightedList),
("selected", "select", MainWindow.ColorsSelectedList),
):
pass
with no backslashes required. An even better way would be to given the
tuples descriptive names, so that anyone maintaining this software can
easily see what they are for:
# States should be tuples (description, attribute name, colour list).
standard = ("normal", "image", MainWindow.ColorsNormalList)
highlighted = ("highlighted", "highlight",
MainWindow.ColorsHighlightedList)
selected = ("selected", "select", MainWindow.ColorsSelectedList)
for desc, attr, color_list in (standard, highlighted, selected):
pass
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On Mon, 01 Nov 2010 22:48:16 +, Peter Pearson wrote: > I must concede that some awkwardness results from assigning significance > to something (whitespace) that many tools are inclined to treat as > insignificant. Then the tools are broken. Or perhaps I should say: Th enth etool sarebroke n. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python documentation too difficult for beginners
This (http://epydoc.sourceforge.net/stdlib/) is what I'm talking about. Why aren't the official docs like this, and why has it taken me 2 days of searching? All this needs is a search engine behind it and it'd be perfect. -- http://mail.python.org/mailman/listinfo/python-list
Re: playful coding problems for 10 year olds
>> Hi folks, >> >> My niece is interested in programming and python looks like a good >> choice (she already wrote a couple of lines :)) She is 10 and I >> thought it would be good to have a bunch of playful coding problems >> for her, stuff that she could code herself maybe after some initial >> help. >> >> Do you guys know problems like these? Or a good resource where to look >> them up? >> >> Cheers, >> Daniel >> > > There's a great book valled 'Invent your own computer games using > Python', aimed at kids, which teaches programming from tne ground up, > in the context of writing games, starting with terminal word games, > ending with Pygame fullscreen 2D vector graphic & bitmaps affairs. > http://inventwithpython.com/ > > The website says aimed at kids 'ages 10 to 12 and upwards', so it > sounds like she's on the minimum cusp. > > (now I come to look at the website, one of the quotes he features is > from an Amazon review I wrote months ago! :-) Thanks a lot for everyone for the suggestions, I think I'll be able to cook things up from all the references you sent! Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On Tue, 02 Nov 2010 04:16:28 +, Seebs wrote: > e.g., any email sent > to my work account is being magically transformed into HTML (no one > knows why) on the server, so I can't get correct indentation except > in attachments. I suppose then you're going to insist that Python should stop using > and < for comparison operators, because your mail server converts them to > and < escapes? > 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 years. I've lost more time to reading people's bitching about indentation than I have dealing with indentation problems. But then, I don't insist on using tools which are broken by design. If your email server converts plain text to HTML, it is broken. 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. 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. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python documentation too difficult for beginners
On 02/11/2010 11:23, jk wrote: This (http://epydoc.sourceforge.net/stdlib/) is what I'm talking about. Why aren't the official docs like this, and why has it taken me 2 days of searching? All this needs is a search engine behind it and it'd be perfect. I'm glad you find the epydoc format useful. And I'm glad that various people have taken the trouble to produce documentation for Python in various formats that suit them. But why do you imagine that the core Python documentation -- developed and maintained by a group of people who clearly have some idea what they're doing -- should change to a format which happens to suit you? The Python documentation source and the source code of Python itself are all freely available. Any initiative by you or by others to produce alternative, possibly searchable and commentable, versions of them would I'm sure be welcomed by many. But not everyone finds, eg, the PHP style of user annotation helpful. Not everyone likes epydoc output: I don't myself. In short, please feel free to contribute directly to the core documentation effort, or to produce alternatives yourself and to advertise them here or elsewhere within the Python community. But please don't come along and say "Why aren't the Python docs like which happens to suit me better?" TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Allowing comments after the line continuation backslash
In article ,
Chris Rebert wrote:
> I find the level of deviation from PEP 8 in that file rather disturbing.
> In any case, the backslashes are easily avoided, and readability
> improved IMHO, via refactoring:
>
> desc_attr_colors_triples = (("normal", "image", MainWindow.ColorsNormalList),
> ("highlighted", "highlight", MainWindow.ColorsHighlightedList),
> ("selected", "select", MainWindow.ColorsSelectedList))
> for in description, attr, color_list in desc_attr_colors_triples:
> ...
I like and use PEP-8. At the start of any project involving myself,
other people, and Python, I'll generally suggest we follow PEP-8 style,
and I can't remember ever getting any pushback. That being said, I
don't hold it in awe. Likewise, I don't worry in the least about
deviating when readability would be improved by doing so.
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
For those reading this in a non-fixed width font, I've laid out the
definition of styles as a table, with spaces inserted to make the
columns line up. For data like this, I think it makes it easier to read
and comprehend. As a minor nit, note that I made it a list of tuples,
not a tuple of tuples.
I'm tempted to do an additional refactoring to get rid of the verbose
color list names:
CL_Normal = MainWindow.ColorsNormalList)
CL_Highlighted = MainWindow.ColorsHighlightedList
CL_Selected = MainWindow.ColorsSelectedList
styles = [("normal", "image", CL_Normal),
("highlighted", "highlight", CL_Highlighted),
("selected","select",CL_Selected)]
I haven't decided if this makes things better or worse. For this small
table, I'm inclined to say worse. If the table were much larger and I
were reusing many of the color list names over and over, I would
certainly do that. If MainWindow were a well-designed module and I
could do
import * from MainWindow
without cluttering up my namespace too much, I would do that, then just
use the unadorned names.
Also, depending on what I was doing inside the loop, I might pick
shorter names. For example:
for in d, a, c in styles:
window.set_description(d)
window.set_attribute(a)
window.set_color_list(c)
is perfectly clear. Normally, I don't use single-letter variable names,
but in this particular case, the descriptive function names provide all
the context that's need to explain what they are.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python documentation too difficult for beginners
On 11/02/10 10:42, jk wrote: Is there much chance that the Python maintainers will change their documentation system to make it more like Java or PHP? How would I go about trying to make that happen? I am by no means an authority however since you ask it here I feel compelled to give you my opinion :-) In general I would think that more documentation is always welcome, if you feel like you can make a contribution, excellent, please do! However, I found that the documentation available was enough for me, and I didn't even have to go to the googles for that. Typing help(thing_i_want_info_of) in the interpreter gives me precise consistent information for what I need to do with whatever it is I am doing and yes that is largely a replication of what is mentioned on the site itself (well more the other way around actually). In the odd cases this doesn't help me, I google for examples. If that doesn't help I look at the modules __file__ and open that module to read the source. And when I started 10 odd years ago with Python it was my first language with no prior confusion of other languages, since then I extended my knowledge with C and assembler but on a day to day basis I still use Python. -- mph -- http://mail.python.org/mailman/listinfo/python-list
Re: functions, list, default parameters
On Tue, 02 Nov 2010 22:06:40 +1300, Lawrence D'Oliveiro wrote: > In message , Chris > Rebert wrote: > >> On Fri, Oct 22, 2010 at 12:36 AM, Steven D'Aprano >> wrote: >>> >>> Default mutable arguments have their place >> >> But it's a rather obscure one where it is almost never strictly >> necessary to venture. > > Mediocre programmers with a hankering towards cleverness latch onto it > as an ingenious way of maintaing persistent context in-between calls to > a function, completely overlooking the fact that Python offers much more > straightforward, comprehensible, flexible, and above all maintainable > ways of doing that sort of thing. Perhaps. Or maybe it's the mediocre programmers who find mutable defaults confusing, incomprehensible and unmaintainable. 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 mutable default or not? For the benefit of any mediocre programmers out there, be careful before you answer. This *is* a trick question. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python documentation too difficult for beginners
A tutorial type book can also be great for reference and documentation (as long as its current). I would recommend a non-programmers tutorial to python even if you have started programming in other languages before. Also its a wiki book and is free. -Braden Faulkner Sent wirelessly from my BlackBerry device on the Bell network. Envoyé sans fil par mon terminal mobile BlackBerry sur le réseau de Bell. -- http://mail.python.org/mailman/listinfo/python-list
Re: functions, list, default parameters
On Tue, 02 Nov 2010 20:12:49 +1300, Lawrence D'Oliveiro wrote about mutable defaults: > 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. I call bullshit. Maybe you should spend some time on the tu...@python.org mailing list for a while to see what the common problems newbies actually have. Mutable defaults are *way* down the list. In any case, Python isn't written solely for newbies. Most people will make this mistake once, or twice if they're particularly slow learning. If newbies have a problem with mutable defaults, oh well, they'll learn, or they'll give up and go back to griefing their friends on Facebook. Either way, problem solved. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python documentation too difficult for beginners
On Tue, 2010-11-02 at 04:23 -0700, jk wrote: > This (http://epydoc.sourceforge.net/stdlib/) is what I'm talking > about. Aaaarrr > Why aren't the official docs like this, Because not everyone likes documentation like that. Personally I far prefer the existing documentation to the JavaDoc-style link you sent. > and why has it taken me 2 days of searching? > All this needs is a search engine behind it and it'd be > perfect. Personally I use Google, e.g. "list site:docs.python.org" to bring up documentation about the list type. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why this result with the re module
> 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python documentation too difficult for beginners
On Tue, 2 Nov 2010 04:23:49 -0700 (PDT) jk wrote: > This (http://epydoc.sourceforge.net/stdlib/) is what I'm talking > about. > > Why aren't the official docs like this, and why has it taken me 2 days > of searching? What's wrong with this: http://docs.python.org/library/ ? If you have specific ideas for improvements, you can open issues at http://bugs.python.org. Thank you Antoine. -- http://mail.python.org/mailman/listinfo/python-list
Re: functions, list, default parameters
On Tue, 02 Nov 2010 00:40:17 -0700, Chris Rebert wrote: > On Fri, Oct 22, 2010 at 12:36 AM, Steven D'Aprano > wrote: >> On Thu, 21 Oct 2010 19:53:53 -0700, John Nagle wrote: This is a common newbie stumbling-block: Don't use lists (or anything mutable) as default argument values >>> >>> That really should be an error. >> >> No it shouldn't. Punishing everybody for a newbie mistake that nobody >> makes twice would be the error. >> >> Default mutable arguments have their place > > But it's a rather obscure one where it is almost never strictly > necessary to venture. Very few language features are *strictly* necessary. I mean, all you really need is the ability to set the current memory location, a way to read and write to it, and a way to branch. Everything else is just gravy. Not that I'm suggesting we should all use Turing machines, but there are many things which aren't strictly necessary but are nice to have. In any case, this discussion is pointless. There is code out there that uses this feature, whether you (generic you) like it or not, and changing the behaviour *can't* happen until the moratorium ends. Even if there was consensus to make this change -- and there won't be -- it almost certainly won't happen before Python 4000. Even if it did happen, adding extra type-checks to every def statement with a default value, or adding extra complexity to the parser, won't and can't catch every mutable default because there is no way of telling whether an arbitrary object is mutable. It will just slow down the language for bugger-all benefit. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Why this result with the re module
2010/11/2 Yingjie Lan : >> From: John Bond >> Subject: Re: Why this result with the re module > ... > 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. > > Hi, in that case you may use re.finditer(...), which seem to provide, what you need here. (It returns an iterator over the Match objects, which can be easily fed to tuple(...) if it were needed.) hth, vbr -- http://mail.python.org/mailman/listinfo/python-list
Re: playful coding problems for 10 year olds
On 2010-11-01, Martin v. Loewis wrote: >> My niece is interested in programming and python looks like a good >> choice (she already wrote a couple of lines :)) She is 10 and I >> thought it would be good to have a bunch of playful coding problems >> for her, stuff that she could code herself maybe after some initial >> help. > > I think anything that has to do with drawing and colors will be > attractive, animated if possible. It has to look nice. > > Take a look at the turtle demos. The book _Simply Scheme_ contains a lot of word problems, which I think is quite nice. possessive,is_palindrom, pig_latin, and so forth might make good Python exercises, too. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
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. It's as good as outdated comments. Emile -- http://mail.python.org/mailman/listinfo/python-list
Re: Python documentation too difficult for beginners
On Nov 2, 11:49 am, Tim Golden wrote: > But why do you imagine that the core > Python documentation -- developed and maintained by a group of people > who clearly have some idea what they're doing -- should change to a > format which happens to suit you? It's not just me who's found the current documentation frustrating. And sure, the developers know how to code, but they probably can't see the project with the eyes of a beginner any more. Making a change to how code is documented to allow more javadoc-style documentation to be produced could help people migrate from a java background and ease the learning curve for them, leading to wider adoption of the language. It wouldn't necessarily mean that the current documentation style would need to change either. > In short, please feel free to contribute directly to the core > documentation effort, or to produce alternatives yourself I may well do that. @Tim Wintle > Personally I use Google, e.g. > "list site:docs.python.org" > to bring up documentation about the list type. Surely you shouldn't have to go to google though? Or the interpreter? Maybe it's just what you're used to, but I'd expect the language's web site to provide enough of a reference in itself, while using google for examples. -- http://mail.python.org/mailman/listinfo/python-list
Learning book recommendation?
Hey Everyone! I'm looking for a Python book to start really learning the language since I've been using it more and more. Something similar to what you'd see in a computer science class - a few pages of theory and explanation of commands/syntax/constructs/data structures and then some exercises to help you learn how to put it to work. I've tried the MIT OCW intro to python/CS but it quickly went beyond my abilities (sadly, I am no MIT student). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python documentation too difficult for beginners
On Tue, 02 Nov 2010 03:42:22 -0700, jk wrote: > Hi, > > I've been coding in PHP and Java for years, and their documentation is > concise, well structured and easy to scan. Well, that's one opinion. > Others have mentioned this apparently for years (see: > http://stackoverflow.com/questions/4046166/easy-to-navigate-online- python-reference-manual/4070851 > and http://www.russellbeattie.com/blog/python-library-docs-still-suck > and http://xahlee.org/perl-python/xlali_skami_cukta.html). > > Compare for instance the differences in ease of use, and speed of use, > of these: > > http://docs.python.org/library/functions.html#open > http://uk.php.net/manual/en/function.fopen.php > > The former is difficult to find (try searching for 'open' in the search > box and see what you get). A fair point -- the built-in open comes up as hit #30, whereas searching for open in the PHP page brings up fopen as hit #1. But the PHP search also brings up many, many hits -- ten pages worth. But in any case, the Python search functionality could be smarter. If I had a complaint about the docs, that would be it. Fortunately, I have google :) > 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's *nine* paragraphs, three of which are one-liners, the longest of which is eight lines. If you have trouble reading that, well, you have a problem. The PHP docs for fopen are FIFTY-EIGHT paragraphs. Okay, okay, I was unfair. I counted section headings as separate paragraphs. A more reasonable count is... twenty-six paragraphs, tables, sections and subsections. Plus *dozens* of user-contributed recipes, bug reports, tricks, tips and comments. And you call this concise??? Reading the docs, I'd say that PHP needs all this extra documentation because it's so much more complicated. fopen has all this implicit magic behaviour that needs documenting -- it will try to guess a scheme from the file name, if it can't guess the scheme it will guess that it's a local file, and the behaviour depends on various globals. In comparison, Python's open is very simple: it only opens files. No wonder Python's docs are simpler. The PHP docs felt it necessary to give a warning *three times*, one after the other, about using binary mode when opening files. Apparently once was not enough. The Description subsection of the PHP fopen doc says: fopen() binds a named resource, specified by filename, to a stream. What's a stream? So I read, and read, and read, and eventually, almost at the bottom of the official docs, I find the section "Return Values": Returns a file pointer resource on success, or FALSE on error. Great! Now, what's a file pointer resource, and how does it differ from a stream? No idea. Contrast that with the Python docs. In the *very first sentence*, it says: Open a file, returning an object of the file type described in section File Objects. with both "file" and "File Objects" being hyperlinks to the appropriate part of the docs. I think I'll stick with the Python style, thank you very much. > The latter has clearly delineated, standardised content areas for each > of these without excessive text. It uses tables which are easy to scan > for possible opening modes and allows users to contribute their own > examples. There has been discussion on python-dev about user contributed examples. The pros are that users can add tricks and tips. The cons are that, without constant attention, the user-contributed content will grow old and stale, or worse, be filled with nonsense. However, there is a Python wiki. It doesn't get anywhere near as much love as it deserves, and (I think) the consensus was that the official Python docs should stay official, but link to the wiki for user- contributed content. This hasn't happened yet. http://wiki.python.org/moin/ > Sadly, the use of restructured text by python doesn't allow a new > document generator to be written - all existing documentation would need > updating with docblocks or something similar. > > Has anyone else struggled while trying to learn the language? The whole > documentation system seems geared towards people who already know what > they're looking for and is close to useless for beginners. I'm not the > only one who finds google an easier way to find documentation about > python. Why do you think this is a bad thing? The Python docs are the reference manual, not a tutorial. Quite frankly, if I were a PHP developer, I'd be pretty annoyed at having to read this in the docs for fopen: If you use the wrong line ending characters when writing your files, you might find that other applications that open those files will "look funny". Gosh, really? Thanks for the tip, Captain Obvious. It's always difficult to know how
Re: Learning book recommendation?
Hey there, I would reccomend a non-programmers tutorial to python by Josh coglatti and its a free wiki book. Also I would recommend byte into python. Both are great for beginers. Best of luck! -- Braden Faulkner Sent wirelessly from my BlackBerry device on the Bell network. Envoyé sans fil par mon terminal mobile BlackBerry sur le réseau de Bell. -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On 2010-11-01, Peter Pearson wrote: > On Mon, 1 Nov 2010 22:24:03 + (UTC), 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. >> >> For exmaple, if you remove all of the curly-braces from two C source >> files before comparing them, you don't get useful results. > > True, but diff doesn't come with an "ignore curly braces" option. 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. > I'm not personally repelled by Python's use of significant > indentation, but I must concede that some awkwardness results from > assigning significance to something (whitespace) that many tools are > inclined to treat as insignificant. However, the human brain does treat whitespace as significant. -- Grant Edwards grant.b.edwardsYow! I joined scientology at at a garage sale!! gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On 2010-11-02, Seebs wrote: > On 2010-11-01, Grant Edwards wrote: >> On 2010-11-01, Lawrence D'Oliveiro wrote: >>> 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. > > Sure. > >> For exmaple, if you remove all of the curly-braces from two C source >> files before comparing them, you don't get useful results. > > Right. > > But there's no *reason* to do that, while there are many common daily > events which result in whitespace changes. e.g., any email sent to > my work account is being magically transformed into HTML (no one > knows why) on the server, so I can't get correct indentation except > in attachments. And you think compatibility with your broken e-mail server is a good reason to change the syntax of a programming language? > Many editors helpfully convert spaces to tabs by default some or all > of the time. And so on. Such editors are broken. > The more I use it, the more I think it was an interesting experiment > which has worked out about as well as scanf. I think it's brilliant (indentation that actually means something, not scanf). > 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. > 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 > years. Then you're doing something terribly wrong. I find indentation-based structure to be completely effortless. Are you using an editor that doesn't have a Python mode? > In theory, it sounds like it would help to eliminate the ambiguity. > In practice, eliminating the question of whether code was intended to > follow explicit flow rather than indentation just means that when > there's a mistake you don't even get a warning that someone was > confused. > > At least in C, if I see: > if (foo) > a; > else > b; > c; > > I *know* that something is wrong. I suppose you can add comments to Python if you some syntactically null "redudundacy" to indicate the intended structure. Personally, -- Grant Edwards grant.b.edwardsYow! I'm having a at quadrophonic sensation gmail.comof two winos alone in a steel mill! -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On 2010-11-02, Steven D'Aprano wrote: > Ah, but other languages don't make the guarantee that you can add or > remove random whitespace in arbitrary places and still have code that > works correctly! > > Of course, neither does Python, but there's a certain type of > personality that is never happy unless they are bitching and moaning, > and if they can't find something more substantial to bitch and moan > about, they'll bitch and moan about the fact that they can't make > random changes to syntactically significant tokens in their source > code without things breaking. Boo hoo, cry me a river. :) > 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've tripped over that as well. Not very often, but it's a bigger problem than significant whitespace. I must admit that the first few minutes I worked with Python having significant whitespace seemed awkward -- probably because it invoked unpleasant memories of Fortran IV on punch-cards. After a short time, I suddenly realized that Python got it right: the compiler and my brain are using the _same_thing_ to denote program structure. All those years of my brain using one thing and the compiler using a different thing were (and are) obviously the wrong way to do it. -- Grant Edwards grant.b.edwardsYow! My BIOLOGICAL ALARM at CLOCK just went off ... It gmail.comhas noiseless DOZE FUNCTION and full kitchen!! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python documentation too difficult for beginners
On 2010-11-02, brf...@gmail.com wrote: > A tutorial type book can also be great for reference and > documentation (as long as its current). I would recommend a > non-programmers tutorial to python even if you have started > programming in other languages before. Also its a wiki book and is > free. To what does "it" refer in the last sentence? > Sent wirelessly from my BlackBerry device on the Bell network. That's nice, thank's for sharing. -- Grant Edwards grant.b.edwardsYow! Do you think the at "Monkees" should get gas on gmail.comodd or even days? -- http://mail.python.org/mailman/listinfo/python-list
Re: Why this result with the re module
> From: Vlastimil Brom > Subject: Re: Why this result with the re module > in that case you may use re.finditer(...) Thanks for pointing this out. Still I'd love to see re.findall never discards the whole match, even if a tuple is returned. Yingjie -- http://mail.python.org/mailman/listinfo/python-list
Re: Python documentation too difficult for beginners
On Nov 2, 1:42 pm, Steven D'Aprano wrote: > It's always difficult to know how much information is too much. The PHP > docs seem to take an "everything including the kitchen sink" approach. > Given that approach, it makes sense to divide everything into > subsections, one page per function. But with Python's minimalist > approach, it would just be annoying. Compare the four lines of: > > http://docs.python.org/library/functions.html#id > > with this re-write in the PHP fashion: > > = > id > = > (Python 1.x, Python 2.x, Python 3.x) > > id -- id of an object > > Description > --- > > id(object) > > id returns the numeric "identity" of an object, which is guaranteed to be > unique and constant for this object during its lifetime. > > Note: two objects with non-overlapping lifetimes may have the same id() > value. > > Note: CPython implementation detail: This is the address of the object. > > Parameters > -- > > * object > > Any object. > > Note: all data in Python are objects, even ints and strings. > > Note: there are no undefined objects in Python. If you call > id(variable) on an unbound variable name, Python will raise an > exception. > > Return values > - > > Returns an integer or long integer object representing the ID of the > argument. > > Errors/exceptions > - > > If the argument to id() is a named variable rather than a literal, and > that name is not bound to any object, then a NameError will be raised. > Otherwise every call to id() must succeed. > > Note: if the call to id() is inside a function, the exception may be a > subclass of NameError such as UnboundLocalError. > > Note: literals are not guaranteed to always refer to the same object. > > Changelog > - > > 0.9 First version added (I think). > > Examples > > > id(x) > id(alist[1]) > id(instance.attribute) > id(module.name.attribute['key'].method(arg1, arg2).seq[2]) > > Notes > - > > If you're still reading, I admire your persistence. > > See also > > > Python's object model > Exceptions > > Steven 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. 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 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. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python documentation too difficult for beginners
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: extracting variables accessed and written from function / rule-based function calls
> >> 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
Re: Python documentation too difficult for beginners
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: Why this result with the re module
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: factorial of negative one (-1)
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: functions, list, default parameters
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: functions, list, default parameters
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
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: Python documentation too difficult for beginners
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
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 equivalent of SOAP-ISIWoK
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: Compare source code
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: Compare source code
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
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
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
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: Python documentation too difficult for beginners
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
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: Compare source code
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: Python documentation too difficult for beginners
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: Python documentation too difficult for beginners
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
Man pages and info pages (was: Python documentation too difficult for beginners)
* 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
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
Re: Compare source code
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
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
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: 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
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: Compare source code
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: Man pages and info pages (was: Python documentation too difficult for beginners)
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
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)
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
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: *** FBI gets a warm welcome in Chicago for their EXCELLENTperformance - cheers to NEW CONS ***
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
problem with opening a new python program in a new window (and keeping track of the process)
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: Trouble with importing
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: Compare source code
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: *** FBI gets a warm welcome in Chicago for their EXCELLENTperformance - cheers to NEW CONS ***
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: *** FBI gets a warm welcome in Chicago for their EXCELLENTperformance - cheers to NEW CONS ***
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: Trouble with importing
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 ***
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: Python documentation too difficult for beginners
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 EXCELLENT performance - cheers to NEW CONS ***
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 EXCELLENTperformance - cheers to NEW CONS ***
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: Compare source code
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: Python documentation too difficult for beginners
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
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
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: Python documentation too difficult for beginners
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: Allowing comments after the line continuation backslash
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
Multiple cookie headers and urllib2
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: *** FBI gets a warm welcome in Chicago for their EXCELLENTperformance - cheers to NEW CONS ***
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
Re: Python documentation too difficult for beginners
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
