date:20121121

Robert,

You would never get a better product by accident.

The meaning of better product might differ from team to team but you can not 
ignore excessive complexity. Earlier or later you get back to that code and 
refactor it, thus existence of such fact was driven by your intention to make 
it a bit better (easier to understand, to support, to cover with unit tests, 
etc), with a team of 20 heads you can get even further: the whole 
team adherence. So those drops make the overall picture better. This is what 
you, as a software developer, donate to what the final better product become.

Thanks.

Andriy

> To: python-list@python.org
> From: robert.k...@gmail.com
> Subject: Re: Web Frameworks Excessive Complexity
> Date: Tue, 20 Nov 2012 20:33:46 +
>
> On 20/11/2012 20:22, Andriy Kornatskyy wrote:
> >
> > Robert,
> >
> > I respect your point of view and it definitely make sense to me. I 
> > personally do not have a problem to understand CC but agree, method LoC is 
> > easier to understand. Regardless the path your choose in your next 
> > refactoring (based on method CC, LoC) it gives your better product.
>
> No, refactoring based on CC does not give you a better product, except by 
> accident.
>
> --
> 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

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

RE: Web Frameworks Excessive Complexity


We choose Python for its readability. This is essential principal of language 
and thousands around reading the open source code. Things like PEP8, CC, LoC 
are all to serve you one purpose: bring your attention, teach you make your 
code better.

Thanks.

Andriy



> From: ulrich.eckha...@dominolaser.com
> Subject: Re: Web Frameworks Excessive Complexity
> Date: Wed, 21 Nov 2012 09:33:09 +0100
> To: python-list@python.org
>
> Am 21.11.2012 02:43, schrieb Steven D'Aprano:
> > On Tue, 20 Nov 2012 20:07:54 +, Robert Kern wrote:
> >> The source of bugs is not excessive complexity in a method, just
> >> excessive lines of code.
> >
> > Taken literally, that cannot possibly the case.
> >
> > def method(self, a, b, c):
> > do_this(a)
> > do_that(b)
> > do_something_else(c)
> >
> >
> > def method(self, a, b, c):
> > do_this(a); do_that(b); do_something_else(c)
> >
> >
> > It *simply isn't credible* that version 1 is statistically likely to have
> > twice as many bugs as version 2. Over-reliance on LOC is easily gamed,
> > especially in semicolon languages.
>
> "Don't indent deeper than 4 levels!" "OK, not indenting at all, $LANG
> doesn't need it anyway." Sorry, but if code isn't even structured
> halfway reasonably it is unmaintainable, regardless of what CC or LOC say.
>
>
> > Besides, I think you have the cause and effect backwards. I would rather
> > say:
> >
> > The source of bugs is not lines of code in a method, but excessive
> > complexity. It merely happens that counting complexity is hard, counting
> > lines of code is easy, and the two are strongly correlated, so why count
> > complexity when you can just count lines of code?
>
> I agree here, and I'd go even further: Measuring complexity is not just
> hard, it requires a metric that you need to agree on first. With LOC you
> only need to agree on not semicolon-chaining lines and how to treat
> comments and empty lines. With CC, you effectively agree that an if
> statement has complexity of one (or 2?) while a switch statement has a
> complexity according to its number of cases, while it is way easier to
> read and comprehend than a similar number produced by if statement.
> Also, CC doesn't even consider new-fashioned stuff like exceptions that
> introduce yet another control flow path.
>
>
> >> LoC is much simpler, easier to understand, and
> >> easier to correct than CC.
> >
> > Well, sure, but do you really think Perl one-liners are the paragon of
> > bug-free code we ought to be aiming for? *wink*
>
> Hehehe... ;)
>
> Uli
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encoding conundrum

2012-11-21 Thread danielk

On Tuesday, November 20, 2012 6:03:47 PM UTC-5, Ian wrote:
> On Tue, Nov 20, 2012 at 2:49 PM, Daniel Klein  wrote:
> 
> > With the assistance of this group I am understanding unicode encoding issues
> 
> > much better; especially when handling special characters that are outside of
> 
> > the ASCII range. I've got my application working perfectly now :-)
> 
> >
> 
> > However, I am still confused as to why I can only use one specific encoding.
> 
> >
> 
> > I've done some research and it appears that I should be able to use any of
> 
> > the following codecs with codepoints '\xfc' (chr(252)) '\xfd' (chr(253)) and
> 
> > '\xfe' (chr(254)) :
> 
> 
> 
> These refer to the characters with *Unicode* codepoints 252, 253, and 254:
> 
> 
> 
> >>> unicodedata.name('\xfc')
> 
> 'LATIN SMALL LETTER U WITH DIAERESIS'
> 
> >>> unicodedata.name('\xfd')
> 
> 'LATIN SMALL LETTER Y WITH ACUTE'
> 
> >>> unicodedata.name('\xfe')
> 
> 'LATIN SMALL LETTER THORN'
> 
> 
> 
> > ISO-8859-1   [ note that I'm using this codec on my Linux box ]
> 
> 
> 
> For ISO 8859-1, these characters happen to exist and even correspond
> 
> to the same ordinals: 252, 253, and 254 (this is by design); so there
> 
> is no problem encoding them, and the resulting bytes even happen to
> 
> match the codepoints of the characters.
> 
> 
> 
> > cp1252
> 
> 
> 
> cp1252 is designed after ISO 8859-1 and also has those same three characters:
> 
> 
> 
> >>> for char in b'\xfc\xfd\xfe'.decode('cp1252'):
> 
> ... print(unicodedata.name(char))
> 
> ...
> 
> LATIN SMALL LETTER U WITH DIAERESIS
> 
> LATIN SMALL LETTER Y WITH ACUTE
> 
> LATIN SMALL LETTER THORN
> 
> 
> 
> > latin1
> 
> 
> 
> Latin-1 is just another name for ISO 8859-1.
> 
> 
> 
> > utf-8
> 
> 
> 
> UTF-8 is a *multi-byte* encoding.  It can encode any Unicode
> 
> characters, so you can represent those three characters in UTF-8, but
> 
> with a different (and longer) byte sequence:
> 
> 
> 
> >>> print('\xfc\xfd\xfd'.encode('utf8'))
> 
> b'\xc3\xbc\xc3\xbd\xc3\xbd'
> 
> 
> 
> > cp437
> 
> 
> 
> cp437 is another 8-bit encoding, but it maps entirely different
> 
> characters to those three bytes:
> 
> 
> 
> >>> for char in b'\xfc\xfd\xfe'.decode('cp437'):
> 
> ... print(unicodedata.name(char))
> 
> ...
> 
> SUPERSCRIPT LATIN SMALL LETTER N
> 
> SUPERSCRIPT TWO
> 
> BLACK SQUARE
> 
> 
> 
> As it happens, the character at codepoint 252 (that's LATIN SMALL
> 
> LETTER U WITH DIAERESIS) does exist in cp437.  It maps to the byte
> 
> 0x81:
> 
> 
> 
> >>> '\xfc'.encode('cp437')
> 
> b'\x81'
> 
> 
> 
> The other two Unicode characters, at codepoints 253 and 254, do not
> 
> exist at all in cp437 and cannot be encoded.
> 
> 
> 
> > If I'm not mistaken, all of these codecs can handle the complete 8bit
> 
> > character set.
> 
> 
> 
> There is no "complete 8bit character set".  cp1252, Latin1, and cp437
> 
> are all 8-bit character sets, but they're *different* 8-bit character
> 
> sets with only partial overlap.
> 
> 
> 
> > However, on Windows 7, I am only able to use 'cp437' to display (print) data
> 
> > with those characters in Python. If I use any other encoding, Windows laughs
> 
> > at me with this error message:
> 
> >
> 
> >   File "C:\Python33\lib\encodings\cp437.py", line 19, in encode
> 
> > return codecs.charmap_encode(input,self.errors,encoding_map)[0]
> 
> > UnicodeEncodeError: 'charmap' codec can't encode character '\xfd' in
> 
> > position 3: character maps to 
> 
> 
> 
> It would be helpful to see the code you're running that causes this error.

I'm using subprocess.Popen to run a process that sends a list of codepoints to 
the calling Python program. The list is sent to stdout as a string.  Here is a 
simple example that encodes the string "Dead^Parrot", where (for this example) 
I'm using '^' to represent chr(254) :

encoded_string = '[68,101,97,100,254,80,97,114,114,111,116]'

This in turn is handled in __repr__ with:

return bytes((eval(encoded_string))).decode('cp437')

I get the aforementioned 'error' if I use any other encoding.

> 
> 
> 
> > Furthermore I get this from IDLE:
> 
> >
> 
>  import locale
> 
>  locale.getdefaultlocale()
> 
> > ('en_US', 'cp1252')
> 
> >
> 
> > I also get 'cp1252' when running the same script from a Windows command
> 
> > prompt.
> 
> >
> 
> > So there is a contradiction between the error message and the default
> 
> > encoding.
> 
> 
> 
> If you're printing to stdout, it's going to use the encoding
> 
> associated with stdout, which does not necessarily have anything to do
> 
> with the default locale.  Use this to determine what character set you
> 
> need to be working in if you want your data to be printable:
> 
> 
> 
> >>> import sys
> 
> >>> sys.stdout.encoding
> 
> 'cp437'
> 

Hmmm. So THAT'S why I am only able to use 'cp437'. I had (mistakenly) thought 
that I could just indicate whatever encoding I wanted, as long as the codec 
supported it.

> 
> 
> > Why am I restricted from using just that one codec? Is this a Windows or
>

Re: Web Frameworks Excessive Complexity

2012-11-21 Thread Steven D'Aprano

On Wed, 21 Nov 2012 22:21:23 +1100, Chris Angelico wrote:

> Counting complexity by giving a score to every statement encourages code
> like this:
> 
> def bletch(x,y):
>   return x + {"foo":y*2,"bar":x*3+y,"quux":math.sin(y)}.get(mode,0)
> 
> instead of:
> 
> def bletch(x,y):
>   if mode=="foo": return x+y*2
>   if mode=="bar": return x*4+y
>   if mode=="quux": return x+math.sin(y) return x
> 
> Okay, this is a stupid contrived example, but tell me which of those
> you'd rather work with


Am I being paid by the hour or the line?




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

RE: Web Frameworks Excessive Complexity


Chris,

The focus of development team is controlled by setting a metric threshold or 
just excluding some. So you do not have an overhead for the development team 
from the point it set forward, assuming them team committed to adherence it.

Your strategy for perfection may vary. You can start with 8 for CC in new 
project, or with a higher level of 15 in an existing project. Where you end up 
/ the team agrees upon, depends on team commitment to the goal you set. There 
is no gold median, there is just recommendation, how you fluctuate from it and 
what reason you face with depends on team.

Thanks.

Andriy



> Date: Wed, 21 Nov 2012 22:21:23 +1100
> Subject: Re: Web Frameworks Excessive Complexity
> From: ros...@gmail.com
> To: python-list@python.org
>
> On Wed, Nov 21, 2012 at 10:09 PM, Andriy Kornatskyy
>  wrote:
> > We choose Python for its readability. This is essential principal of 
> > language and thousands around reading the open source code. Things like 
> > PEP8, CC, LoC are all to serve you one purpose: bring your attention, teach 
> > you make your code better.
>
> But too much focus on metrics results in those metrics improving
> without any material benefit to the code. If there's a number that you
> can watch going up or down, nobody's going to want to be the one that
> pushes that number the wrong direction. So what happens when the right
> thing to do happens to conflict with the given metric? And yes, it
> WILL happen, guaranteed. No metric is perfect.
>
> Counting lines of code teaches you to make dense code. That's not a
> good thing nor a bad thing; you'll end up with list comprehensions
> rather than short loops, regardless of which is easier to actually
> read.
>
> Counting complexity by giving a score to every statement encourages
> code like this:
>
> def bletch(x,y):
> return x + {"foo":y*2,"bar":x*3+y,"quux":math.sin(y)}.get(mode,0)
>
> instead of:
>
> def bletch(x,y):
> if mode=="foo": return x+y*2
> if mode=="bar": return x*4+y
> if mode=="quux": return x+math.sin(y)
> return x
>
> Okay, this is a stupid contrived example, but tell me which of those
> you'd rather work with, and then tell me a plausible metric that would
> agree with you.
>
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Frameworks Excessive Complexity


On 21/11/2012 01:43, Steven D'Aprano wrote:

On Tue, 20 Nov 2012 20:07:54 +, Robert Kern wrote:


The source of bugs is not excessive complexity in a method, just
excessive lines of code.


Taken literally, that cannot possibly the case.

def method(self, a, b, c):
 do_this(a)
 do_that(b)
 do_something_else(c)


def method(self, a, b, c):
 do_this(a); do_that(b); do_something_else(c)


It *simply isn't credible* that version 1 is statistically likely to have
twice as many bugs as version 2. Over-reliance on LOC is easily gamed,
especially in semicolon languages.


Logical LoC (executable LoC, number of statements, etc.) is a better measure 
than Physical LoC, I agree. That's not the same thing as cyclomatic complexity, 
though. Also, the relationship between LoC (of either type) and bugs is not 
linear (at least not in the small-LoC regime), so you are certainly correct that 
it isn't credible that version 1 is likely to have twice as many bugs as version 
2. No one is saying that it is.



Besides, I think you have the cause and effect backwards. I would rather
say:

The source of bugs is not lines of code in a method, but excessive
complexity. It merely happens that counting complexity is hard, counting
lines of code is easy, and the two are strongly correlated, so why count
complexity when you can just count lines of code?


No, that is not the takeaway of the research. More code correlates with more 
bugs. More cyclomatic complexity also correlates with more bugs. You want to 
find out what causes bugs. What the research shows is that cyclomatic complexity 
is so correlated with LoC that it is going to be very difficult, or impossible, 
to establish a causal relationship between cyclomatic complexity and bugs. The 
previous research that just correlated cyclomatic complexity to bugs without 
controlling for LoC does not establish the causal relationship.



Keep in mind that something like 70-80% of published scientific papers
are never replicated, or cannot be replicated. Just because one paper
concludes that LOC alone is a better metric than CC doesn't necessary
make it so. But even if we assume that the paper is valid, it is
important to understand just what it says, and not extrapolate too far.


This paper is actually a replication. It is notable for how comprehensive it is.


The paper makes various assumptions, takes statistical samples, and uses
models. (Which of course *any* such study must.) I'm not able to comment
on whether those models and assumptions are valid, but assuming that they
are, the conclusion of the paper is no stronger than the models and
assumptions. We should not really conclude that "CC has no more
predictive power than LOC". The right conclusion is that one specific
model of cyclic complexity, McCabe's CC, has no more predictive power
than LOC for projects written in C, C++ and Java.

How does that apply to Python code? Well, it's certainly suggestive, but
it isn't definitive.


More so than the evidence that CC is a worthwhile measure, for Python or any 
language.



It's also important to note that the authors point out that in their
samples of code, they found very high variance and large numbers of
outliers:

[quote]
Modules where LOC does not predict CC (or vice-versa) may indicate an
overly-complex module with a high density of decision points or an overly-
simple module that may need to be refactored.
[end quote]

So *even by the terms of this paper*, it isn't true that CC has no
predictive value over LOC -- if the CC is radically high or low for the
LOC, that is valuable to know.


Is it? What is the evidence that excess, unpredicted-by-LoC CC causes (or even 
correlates with) bugs? The paper points that out as a target for future research 
because no one has studied it yet. It may turn out to be a valid metric, but one 
that has a very specific utility: identifying a particular hotspot. Running CC 
over whole projects to compare their "quality", as the OP has done, is not a 
valid use of even that.



LoC is much simpler, easier to understand, and
easier to correct than CC.


Well, sure, but do you really think Perl one-liners are the paragon of
bug-free code we ought to be aiming for? *wink*


No, but introducing more statements and method calls to avoid if statements 
isn't either.


--
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: Web Frameworks Excessive Complexity


I believe for the quality of code you produce.

Thanks.

Andriy



> From: steve+comp.lang.pyt...@pearwood.info
> Subject: Re: Web Frameworks Excessive Complexity
> Date: Wed, 21 Nov 2012 11:43:10 +
> To: python-list@python.org
>
> On Wed, 21 Nov 2012 22:21:23 +1100, Chris Angelico wrote:
>
> > Counting complexity by giving a score to every statement encourages code
> > like this:
> >
> > def bletch(x,y):
> > return x + {"foo":y*2,"bar":x*3+y,"quux":math.sin(y)}.get(mode,0)
> >
> > instead of:
> >
> > def bletch(x,y):
> > if mode=="foo": return x+y*2
> > if mode=="bar": return x*4+y
> > if mode=="quux": return x+math.sin(y) return x
> >
> > Okay, this is a stupid contrived example, but tell me which of those
> > you'd rather work with
>
>
> Am I being paid by the hour or the line?
>
>
>
>
> --
> Steven
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Frameworks Excessive Complexity


On 21/11/2012 11:02, Andriy Kornatskyy wrote:


Robert,

You would never get a better product by accident.

The meaning of better product might differ from team to team but you can not 
ignore excessive complexity. Earlier or later you get back to that code and 
refactor it, thus existence of such fact was driven by your intention to make 
it a bit better (easier to understand, to support, to cover with unit tests, 
etc), with a team of 20 heads you can get even further: the whole team 
adherence. So those drops make the overall picture better. This is what you, as 
a software developer, donate to what the final better product become.


I think you may be misinterpreting the English idiom. I don't mean that your 
finger slips and randomly types out better code. I mean that by focusing on CC 
as a metric for improvement, you may very well end up improving the code, but 
it's not because you reduced the CC of the code. It's because of all of those 
*other* things that you talk about. Those are the things that should drive your 
refactoring, not CC, because they actually do cause improved code.


--
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: Web Frameworks Excessive Complexity


Agreed. I think we have pretty much the same point of view on this.

All these metrics advise you... this is again depends how you look at this. If 
you are a new comer to a project, you usually spend some time on code review, 
talk to people, read docs if any. The qa tools for static code analysis give 
you an initial picture, how it fits with your own vision, etc. Convince or 
accept?

Andriy Kornatskyy



> To: python-list@python.org
> From: robert.k...@gmail.com
> Subject: Re: Web Frameworks Excessive Complexity
> Date: Wed, 21 Nov 2012 11:54:06 +
>
> On 21/11/2012 11:02, Andriy Kornatskyy wrote:
> >
> > Robert,
> >
> > You would never get a better product by accident.
> >
> > The meaning of better product might differ from team to team but you can 
> > not ignore excessive complexity. Earlier or later you get back to that code 
> > and refactor it, thus existence of such fact was driven by your intention 
> > to make it a bit better (easier to understand, to support, to cover with 
> > unit tests, etc), with a team of 20 heads you can get even further: the 
> > whole team adherence. So those drops make the overall picture better. This 
> > is what you, as a software developer, donate to what the final better 
> > product become.
>
> I think you may be misinterpreting the English idiom. I don't mean that your
> finger slips and randomly types out better code. I mean that by focusing on CC
> as a metric for improvement, you may very well end up improving the code, but
> it's not because you reduced the CC of the code. It's because of all of those
> *other* things that you talk about. Those are the things that should drive 
> your
> refactoring, not CC, because they actually do cause improved code.
>
> --
> 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
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encoding conundrum

2012-11-21 Thread Nobody

On Wed, 21 Nov 2012 03:24:01 -0800, danielk wrote:

>> >>> import sys
>> >>> sys.stdout.encoding
>> 'cp437'
>
> Hmmm. So THAT'S why I am only able to use 'cp437'. I had (mistakenly)
> thought that I could just indicate whatever encoding I wanted, as long as
> the codec supported it.

sys.stdout.encoding determines how Python converts unicode characters
written to sys.stdout to bytes.

If you want the correct characters to be shown, this has to match the
encoding which the console window uses to convert those bytes back to
unicode characters.

You can tell Python to use whichever encoding you want, but often you only
get to control one side of the equation, in which case there's only one
"right" answer.

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

Re: Web Frameworks Excessive Complexity


On 21/11/2012 12:17, Andriy Kornatskyy wrote:


Agreed. I think we have pretty much the same point of view on this.

All these metrics advise you... this is again depends how you look at this. If 
you are a new comer to a project, you usually spend some time on code review, 
talk to people, read docs if any. The qa tools for static code analysis give 
you an initial picture, how it fits with your own vision, etc. Convince or 
accept?


No, we don't have the same point of view on this. I think that using metrics 
that have no evidence for their utility is a misleading distraction.


--
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: 10 sec poll - please reply!

2012-11-21 Thread Hans Mulder

On 21/11/12 02:17:26, Steven D'Aprano wrote:
> On Tue, 20 Nov 2012 18:00:59 -0600, Tim Chase wrote:
> 
>> On 11/20/12 06:18, Michael Herrmann wrote:
>>> am having difficulty picking a name for the function that simulates key
>>> strokes. I currently have it as 'type' but that clashes with the
>>> built-in function.
>>
>> Just to add one more to the pot, Vim uses "feedkeys()" for a similar
>> purpose.
> 
> What does it feed to the keys?

Spam, spam, spam, eggs, and spam.

-- HansM


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

Inconsistent behaviour os str.find/str.index when providing optional parameters

2012-11-21 Thread Giacomo Alzetta

I just came across this:

>>> 'spam'.find('', 5)
-1


Now, reading find's documentation:

>>> print(str.find.__doc__)
S.find(sub [,start [,end]]) -> int

Return the lowest index in S where substring sub is found,
such that sub is contained within S[start:end].  Optional
arguments start and end are interpreted as in slice notation.

Return -1 on failure.

Now, the empty string is a substring of every string so how can find fail?
find, from the doc, should be generally be equivalent to 
S[start:end].find(substring) + start, except if the substring is not found but 
since the empty string is a substring of the empty string it should never fail.

Looking at the source code for find(in stringlib/find.h):

Py_LOCAL_INLINE(Py_ssize_t)
stringlib_find(const STRINGLIB_CHAR* str, Py_ssize_t str_len,
   const STRINGLIB_CHAR* sub, Py_ssize_t sub_len,
   Py_ssize_t offset)
{
Py_ssize_t pos;

if (str_len < 0)
return -1;

I believe it should be:

if (str_len < 0)
return (sub_len == 0 ? 0 : -1);

Is there any reason of having this unexpected behaviour or was this simply 
overlooked?
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Web Frameworks Excessive Complexity


Hm... what serves an evidence purpose for you?

See functions at line 2619 and 2974 as an example for CC 20+:
https://github.com/defnull/bottle/blob/master/bottle.py

Andriy



> To: python-list@python.org
> From: robert.k...@gmail.com
> Subject: Re: Web Frameworks Excessive Complexity
> Date: Wed, 21 Nov 2012 12:26:26 +
>
> On 21/11/2012 12:17, Andriy Kornatskyy wrote:
> >
> > Agreed. I think we have pretty much the same point of view on this.
> >
> > All these metrics advise you... this is again depends how you look at this. 
> > If you are a new comer to a project, you usually spend some time on code 
> > review, talk to people, read docs if any. The qa tools for static code 
> > analysis give you an initial picture, how it fits with your own vision, 
> > etc. Convince or accept?
>
> No, we don't have the same point of view on this. I think that using metrics
> that have no evidence for their utility is a misleading distraction.
>
> --
> 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
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encoding conundrum

On 11/21/2012 06:24 AM, danielk wrote:
> On Tuesday, November 20, 2012 6:03:47 PM UTC-5, Ian wrote:
>>> 
>>
>> In Linux, your terminal encoding is probably either UTF-8 or Latin-1,
>>
>> and either way it has no problems encoding that data for output.  In a
>>
>> Windows cmd terminal, the default terminal encoding is cp437, which
>>
>> can't support two of the three characters you mentioned above.
> It may not be able to encode those two characters but it is able to decode 
> them.That seems rather inconsistent (and contradictory) to me.

You encode characters (code points), but you never decode them.  You
decode bytes.  In some cases and in some encodings, the number(ord) of
the two happens to be the same, eg. for ASCII characters.  Or to pick
latin1, where the first 256 map exactly.

But to pick utf8 for example, which I use almost exclusively on Linux,
the character chr(255) is a lowercase y with a diaeresis accent.

>>> chr(255)
'ÿ'
>>> unicodedata.name(chr(255))
'LATIN SMALL LETTER Y WITH DIAERESIS'

>>> chr(255).encode()
b'\xc3\xbf'
>>> len(chr(255).encode())
2

It takes 2 bytes to encode that character.  (Since there are 1112064
possible characters, most of them take more than one byte to encode in
utf-8.  I believe the size can range up to 4 bytes.)  But naturally, the
first byte of those 2 cannot be one that's valid by itself as an encoded
character, or it'd be impossible to pick apart (decode) a byte string
starting with that one.

So, there is no character which can be encoded to a single byte 0xc3. 
In other words:

>>> bytes([253])
b'\xfd'
>>> bytes([253]).decode()
Traceback (most recent call last):
  File "", line 1, in 
UnicodeDecodeError: 'utf8' codec can't decode byte 0xfd in position 0:
invalid start byte

http://encyclopedia.thefreedictionary.com/UTF-8

has a description of the encoding rules.  Note they're really just
arithmetic, rather than arbitrary.  Ranges of characters encode to
various numbers of bytes.  The main rules are that characters below 0x80
are unchanged, and no valid character encoding is a prefix to any other
valid character encoding.

Contrast that with cp437, where the particular 256 valid characters were
chosen based only on their usefulness, and many of them are above 255. 
Consequently, there must be many characters below 255 which cannot be
encoded.

-- 

DaveA

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

Re: Web Frameworks Excessive Complexity


On 21/11/2012 12:47, Andriy Kornatskyy wrote:


Hm... what serves an evidence purpose for you?


Well-done empirical studies, like the one I gave you.

--
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: Index Error

On 11/21/2012 05:11 AM, inshu chauhan wrote:
>>
>>>

>> I must confess I have no idea what data represents.  When you're doing
>> rings, you use deltas on the cx and cy values.  But when you're
>> computing radius, you use the 3d coordinates returned by  data[cx, cy].
>>  So is data some kind of transformation, like a projection from a 3d
>> object into a plane ?
>>
> 
> If I say data is a yml image file.. does it makes sense ? Nyways I am
> treating it as matrix with values.
> Yes you can say that it is a projection of 3D objects onto a 2D plane..
> which I am finding hard to work with !
> 

http://www.fileinfo.com/extension/yml
   indicates that .yml files are human readable files, but doesn't
specify much else.

from other references, I gather it's used for javascript and for
database.  So far, I've only found one reference to image,
http://stackoverflow.com/questions/10017298/read-yml-files-in-matlab

but that doesn't really give me any intuitive meaning for the data.  So
i cannot guess what the meaning of circle radius is.

At 8:43 yesterday, you had the following output and trace:

"""
data loaded
[(296, 403), (298, 403), (298, 405), (296, 405), (297, 403), (298, 404),
(297, 405), (296, 404)] ... I am printing Indices to know what index it
dies out..

Traceback (most recent call last):
  File "Z:/modules/Classify.py", line 73, in 
ComputeClasses(data)
  File "Z:/modules/Classify.py", line 49, in ComputeClasses
point = data[idx[0], idx[1]]
error: index is out of range
"""

If you meant to just show us the last new_indices list printed out, then
presumably somewhere in that list is the one that fails.

Could it be that the internally linked jpeg file has the size 300 x
3000, and that the yml data only goes to 300 x 400 ?

-- 

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

Re: Index Error


> 
> 
> 
>>
>> Back to an earlier comment.  I asked if N was ever bigger than x or
>> bigger than y, and you said never.  But your ComputeClasses will have
>> such a case the very first time around, when cx==0, cy==0, and
>> ring_number == 1.
>>
> 
> I doubt this , M confused..
> 

I'll paste an excerpt of the last source I've seen from you:

"""

def GenerateRing(x,y, N): Generates square rings around a point in data
which has 300 columns(x) and 3000 rows(y)
indices = []
for i in xrange(-N, N):
indices.append((x+i, y-N))
indices.append((x+N, y+i))
indices.append((x-i, y+N))
indices.append((x-N, y-i))
return indices


def ComputeClasses(data):
radius = .5
points = []
for cy in xrange(0, data.height):
for cx in xrange(0, data.width):

if data[cy,cx] == (0.0,0.0,0.0):
continue
else :
centre = data[cy, cx]
points.append(centre)


change = True

while change:

for ring_number in xrange(1, 100):
change = False
new_indices = GenerateRing(cx, cy, ring_number)
"""

When that GenerateRing() is first called, cy will be zero, cx the same,
and ring_number will be 1.

So some of the tuples in the returned list will have negative ints.  You
don't check for that either.

I still think that data.height and data.width aren't the right limits to
be using.

-- 

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

Re: Inconsistent behaviour os str.find/str.index when providing optional parameters


On 2012-11-21 12:43, Giacomo Alzetta wrote:

I just came across this:


'spam'.find('', 5)

-1


Now, reading find's documentation:


print(str.find.__doc__)

S.find(sub [,start [,end]]) -> int

Return the lowest index in S where substring sub is found,
such that sub is contained within S[start:end].  Optional
arguments start and end are interpreted as in slice notation.

Return -1 on failure.

Now, the empty string is a substring of every string so how can find fail?
find, from the doc, should be generally be equivalent to 
S[start:end].find(substring) + start, except if the substring is not found but 
since the empty string is a substring of the empty string it should never fail.


[snip]
I think that returning -1 is correct (as far as returning -1 instead of
raising an exception like .index could be considered correct!) because
otherwise it whould be returning a non-existent index. For the string
"spam", the range is 0..4.

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

Update slider widget range

2012-11-21 Thread moadeep

I am trying to write a small bit of code that interactively deletes selected 
slices in an image series using matplotlib. I have created a button 'delete' 
which stores a number of indices to be deleted when the button 'update' is 
selected. However, I am currently unable to reset the range of my slider 
widget, i.e. removing the number of deleted slices from valmax. What is the 
pythonic solution to this problem?

Here is my code:

import dicom
import numpy as np
import matplotlib.pyplot as plt
from matplotlib.widgets import Slider, Button

frame = 0
#store indices of slices to be deleted
delete_list = []


def main():

data = np.random.rand(16,256,256)
nframes = data.shape[0]

raw_dicom_stack = []
for x in range (nframes):
raw_dicom_stack.append(data[x,:,:])

#yframe = 0

# Visualize it
viewer = VolumeViewer(raw_dicom_stack, nframes)
viewer.show()

class VolumeViewer(object):
def __init__(self, raw_dicom_stack, nframes):

global delete_list

self.raw_dicom_stack = raw_dicom_stack
self.nframes = nframes
self.delete_list = delete_list

# Setup the axes.
self.fig, self.ax = plt.subplots()
self.slider_ax = self.fig.add_axes([0.2, 0.03, 0.65, 0.03])
self.delete_ax = self.fig.add_axes([0.85,0.84,0.1,0.04])
self.update_ax = self.fig.add_axes([0.85,0.78,0.1,0.04])
self.register_ax = self.fig.add_axes([0.85,0.72,0.1,0.04])
self.add_ax = self.fig.add_axes([0.85,0.66,0.1,0.04])

# Make the slider
self.slider = Slider(self.slider_ax, 'Frame', 1, self.nframes, 
valinit=1, valfmt='%1d/{}'.format(self.nframes))
self.slider.on_changed(self.update)

#Make the buttons
self.del_button = Button(self.delete_ax, 'Delete')
self.del_button.on_clicked(self.delete)

self.upd_button = Button(self.update_ax, 'Update')
self.upd_button.on_clicked(self.img_update)

self.reg_button = Button(self.register_ax, 'Register')

self.add_button = Button(self.add_ax, "Add")

# Plot the first slice of the image
self.im = self.ax.imshow(np.array(raw_dicom_stack[0]))

def update(self, value):
global frame
frame = int(np.round(value - 1))

# Update the image data
dat = np.array(self.raw_dicom_stack[frame])
self.im.set_data(dat)

# Reset the image scaling bounds (this may not be necessary for you)
self.im.set_clim([dat.min(), dat.max()])

# Redraw the plot
self.fig.canvas.draw()

def delete(self,event):
global frame
global delete_list

delete_list.append(frame)
print 'Frame %s has been added to list of slices to be deleted' 
%str(frame+1)
print 'Please click update to delete these slices and show updated 
image series \n'

#Remove duplicates from delete list

def img_update(self,event):
#function deletes image stacks and updates viewer
global delete_list

#Remove duplicates from list and sort into numerical order
delete_list = list(set(delete_list))
delete_list.sort()

#Make sure delete_list is not empty
if not delete_list:
print "Delete list is empty, no slices to delete"
#Loop through delete list in reverse numerical order and remove slices 
from series
else:
for i in reversed(delete_list):
self.raw_dicom_stack.pop(i)
print 'Slice %i removed from dicom series \n' %(i+1)

#Can now remove contents from delete_list
del delete_list[:]
#Update slider range
self.nframes =  len(self.raw_dicom_stack)


def show(self):
plt.show()

if __name__ == '__main__':
main()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Index Error

2012-11-21 Thread inshu chauhan

I guess I have to use try and except as Chris suggested, this isn't working.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Yet another Python textbook

2012-11-21 Thread wxjmfauth

Le mardi 20 novembre 2012 22:00:49 UTC+1, Chris Angelico a écrit :
> On Wed, Nov 21, 2012 at 1:57 AM,   wrote:
> 
-

> To the OP: jmf has an unnatural hatred of Python 3.3 and PEP 393
> 
> strings.


No. Not at all. I'm mainly and deeply disappointed.

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

Constructing JSON data structures from non-string key python dictionaries

2012-11-21 Thread saikari78

Hi,

I'm using the json module to  create a JSON string, then inserting that string 
into a html template containing a javascript function (from the highcharts 
library: http://www.highcharts.com/)
The json string I'm trying to create is to initialize a data variable in the 
javascript function, that has the following example format.



data = [{
y: 55.11,
color: colors[0],
drilldown: {
name: 'MSIE versions',
categories: ['MSIE 6.0', 'MSIE 7.0', 'MSIE 8.0', 'MSIE 
9.0'],
data: [10.85, 7.35, 33.06, 2.81],
color: colors[0]
}
}]

However, I don't know how to do that because dictionary keys in python need to 
be strings. If I try to do the following, Python,of course, complains that 
y,color,drilldown, etc are not defined.


import json

data = [ { y:55.11, color:colors[0], drilldown:{name: 'MSIE 
versions',categories: ['MSIE 6.0', 'MSIE 7.0', 'MSIE 8.0', 'MSIE 9.0'],data: 
[10.85, 7.35, 33.06, 2.81],color: colors[0] }} ]   

data_string = json.dumps(data)


Many thanks for any suggestions on how to do this.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Constructing JSON data structures from non-string key python dictionaries


On 2012-11-21 14:59, saikari78 wrote:

Hi,

I'm using the json module to  create a JSON string, then inserting that string 
into a html template containing a javascript function (from the highcharts 
library: http://www.highcharts.com/)
The json string I'm trying to create is to initialize a data variable in the 
javascript function, that has the following example format.



 data = [{
 y: 55.11,
 color: colors[0],
 drilldown: {
 name: 'MSIE versions',
 categories: ['MSIE 6.0', 'MSIE 7.0', 'MSIE 8.0', 'MSIE 
9.0'],
 data: [10.85, 7.35, 33.06, 2.81],
 color: colors[0]
 }
 }]

However, I don't know how to do that because dictionary keys in python need to 
be strings. If I try to do the following, Python,of course, complains that 
y,color,drilldown, etc are not defined.


import json

data = [ { y:55.11, color:colors[0], drilldown:{name: 'MSIE 
versions',categories: ['MSIE 6.0', 'MSIE 7.0', 'MSIE 8.0', 'MSIE 9.0'],data: 
[10.85, 7.35, 33.06, 2.81],color: colors[0] }} ]

data_string = json.dumps(data)


Many thanks for any suggestions on how to do this.


Just quote them:

data = [ { 'y':55.11, 'color':colors[0], 'drilldown':{'name': 'MSIE 
versions','categories': ['MSIE 6.0', 'MSIE 7.0', 'MSIE 8.0', 'MSIE 
9.0'],'data': [10.85, 7.35, 33.06, 2.81],'color': colors[0] }} ]


Incidentally, dictionary keys in Python don't have to be strings, but
merely 'hashable', which includes integers, floats and tuples amongst
others.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Constructing JSON data structures from non-string key python dictionaries

2012-11-21 Thread hfolch

Thanks for your reply, but the javascript function expects option names to be 
unquoted, otherwise it won't work.
 


On Wednesday, November 21, 2012 3:48:07 PM UTC, MRAB wrote:
> On 2012-11-21 14:59, saikari78 wrote:
> 
> > Hi,
> 
> >
> 
> > I'm using the json module to  create a JSON string, then inserting that 
> > string into a html template containing a javascript function (from the 
> > highcharts library: http://www.highcharts.com/)
> 
> > The json string I'm trying to create is to initialize a data variable in 
> > the javascript function, that has the following example format.
> 
> >
> 
> >
> 
> >
> 
> >  data = [{
> 
> >  y: 55.11,
> 
> >  color: colors[0],
> 
> >  drilldown: {
> 
> >  name: 'MSIE versions',
> 
> >  categories: ['MSIE 6.0', 'MSIE 7.0', 'MSIE 8.0', 
> > 'MSIE 9.0'],
> 
> >  data: [10.85, 7.35, 33.06, 2.81],
> 
> >  color: colors[0]
> 
> >  }
> 
> >  }]
> 
> >
> 
> > However, I don't know how to do that because dictionary keys in python need 
> > to be strings. If I try to do the following, Python,of course, complains 
> > that y,color,drilldown, etc are not defined.
> 
> >
> 
> >
> 
> > import json
> 
> >
> 
> > data = [ { y:55.11, color:colors[0], drilldown:{name: 'MSIE 
> > versions',categories: ['MSIE 6.0', 'MSIE 7.0', 'MSIE 8.0', 'MSIE 
> > 9.0'],data: [10.85, 7.35, 33.06, 2.81],color: colors[0] }} ]
> 
> >
> 
> > data_string = json.dumps(data)
> 
> >
> 
> >
> 
> > Many thanks for any suggestions on how to do this.
> 
> >
> 
> Just quote them:
> 
> 
> 
> data = [ { 'y':55.11, 'color':colors[0], 'drilldown':{'name': 'MSIE 
> 
> versions','categories': ['MSIE 6.0', 'MSIE 7.0', 'MSIE 8.0', 'MSIE 
> 
> 9.0'],'data': [10.85, 7.35, 33.06, 2.81],'color': colors[0] }} ]
> 
> 
> 
> Incidentally, dictionary keys in Python don't have to be strings, but
> 
> merely 'hashable', which includes integers, floats and tuples amongst
> 
> others.

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

Re: Constructing JSON data structures from non-string key python dictionaries

2012-11-21 Thread Grant Edwards

On 2012-11-21, MRAB  wrote:

>> However, I don't know how to do that because dictionary keys in
>> python need to be strings. If I try to do the following, Python,of
>> course, complains that y,color,drilldown, etc are not defined.
>
> Just quote them:
>
> data = [ { 'y':55.11, 'color':colors[0], 'drilldown':{'name': 'MSIE 
> versions','categories': ['MSIE 6.0', 'MSIE 7.0', 'MSIE 8.0', 'MSIE 
> 9.0'],'data': [10.85, 7.35, 33.06, 2.81],'color': colors[0] }} ]
>
> Incidentally, dictionary keys in Python don't have to be strings, but
> merely 'hashable', which includes integers, floats and tuples amongst
> others.

I think he meant that in his use case, the Python dictionary keys must
be strings, since that's what JSON requires.

-- 
Grant Edwards   grant.b.edwardsYow! I have a TINY BOWL in
  at   my HEAD
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suitable software stacks for simple python web service

2012-11-21 Thread Steve Petrie

On Wednesday, November 21, 2012 2:32:40 AM UTC-5, Kev Dwyer wrote:
> Hello List,
> 
> 
> 
> I have to build a simple web service which will:
> 
> 
> 
>  - receive queries from our other servers
> 
>  - forward the requests to a third party SOAP service
> 
>  - process the response from the third party
> 
>  - send the result back to the original requester
> 
> 
> 
> >From the point of view of the requester, this will happen within the scope 
> 
> of a single request.  
> 
> 
> 
> The data exchanged with the original requester will likely be encoded as 
> 
> JSON; the SOAP service will be handled by SUDS.
> 
> 
> 
> The load is likely to be quite light, say a few requests per hour, though 
> 
> this may increase in the future.
> 
> 
> 
> Given these requirements, what do you think might be a suitable software 
> 
> stack, i.e. webserver and web framework (if a web framework is even 
> 
> necessary)?  
> 
> 
> 
> Candidates should be compatible with Python2.7, though I'd be happy to 
> 
> consider Python 3 if anyone knows of a Python3 SOAP library that has good 
> 
> WSDL support.
> 
> 
> 
> Cheers,
> 
> 
> 
> Kev

I'm using the Bottle web framework (http://bottlepy.org) to integrate requests 
and replies originating in a Drupal site, a Beanstream (payment processor) 
account, and a Salesforce instance.

Communication with Salesforce is done through the Salesforce Python Toolkit 
(http://code.google.com/p/salesforce-python-toolkit/), which uses Suds.

Communication with the Drupal site uses Python's (and PHP's on the Drupal side) 
native JSON support.

This is under Python 2.6.8 and Apache 2.2.23 running on an AWS EC2 instance.

No (major) problems so far, though still in the early stages of this project.

Steve



I chose Bottle after trying a few other frameworks because, well, I can't 
remember exactly why, though thinking back it's probably because of the clarity 
of Bottle's approach and the simplicity of the documentation.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Constructing JSON data structures from non-string key python dictionaries

On 2012-11-21 16:04, hfo...@gmail.com wrote:

On Wednesday, November 21, 2012 3:48:07 PM UTC, MRAB wrote:

On 2012-11-21 14:59, saikari78 wrote:

Hi,

I'm using the json module to  create a JSON string, then
inserting  that string into a html template containing a javascript

>>> function (from the highcharts library: http://www.highcharts.com/)

The json string I'm trying to create is to initialize a data

>>> variable in the javascript function, that has the following example
>>> format.

data = [{ y: 55.11, color: colors[0], drilldown: { name: 'MSIE
versions', categories: ['MSIE 6.0', 'MSIE 7.0', 'MSIE

8.0', 'MSIE 9.0'],

data: [10.85, 7.35, 33.06, 2.81], color: colors[0] } }]

However, I don't know how to do that because dictionary keys in

>>> python need to be strings. If I try to do the following, Python,of
>>> course, complains that y,color,drilldown, etc are not defined.

import json

data = [ { y:55.11, color:colors[0], drilldown:{name: 'MSIE

versions',categories: ['MSIE 6.0', 'MSIE 7.0', 'MSIE 8.0', 'MSIE
9.0'],data: [10.85, 7.35, 33.06, 2.81],color: colors[0] }} ]

data_string = json.dumps(data)

Many thanks for any suggestions on how to do this.

Just quote them: data = [ { 'y':55.11, 'color':colors[0],
'drilldown':{'name': 'MSIE versions','categories': ['MSIE 6.0',
'MSIE 7.0', 'MSIE 8.0', 'MSIE 9.0'],'data': [10.85, 7.35, 33.06,
2.81],'color': colors[0] }} ] Incidentally, dictionary keys in
Python don't have to be strings, but merely 'hashable', which
includes integers, floats and tuples amongst others.

Thanks for your reply, but the javascript function expects option

> names to be unquoted, otherwise it won't work.

Both Python source code and JSON require the dictionary keys to be
quoted, so using the json module to generate JavaScript code isn't
going to give you what you want.

It shouldn't be too difficult to write a simple function to do it,
considering the limited range of types.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Constructing JSON data structures from non-string key python dictionaries

On 2012-11-21 16:27, MRAB wrote:> On 2012-11-21 16:04, hfo...@gmail.com 
wrote:

>> On Wednesday, November 21, 2012 3:48:07 PM UTC, MRAB wrote:
>>> On 2012-11-21 14:59, saikari78 wrote:
 Hi,

 I'm using the json module to  create a JSON string, then
 inserting  that string into a html template containing a javascript
 function (from the highcharts library: http://www.highcharts.com/)

 The json string I'm trying to create is to initialize a data
 variable in the javascript function, that has the following example
 format.

 data = [{ y: 55.11, color: colors[0], drilldown: { name: 'MSIE
 versions', categories: ['MSIE 6.0', 'MSIE 7.0', 'MSIE 8.0', 'MSIE
 9.0'], data: [10.85, 7.35, 33.06, 2.81], color: colors[0] } }]

 However, I don't know how to do that because dictionary keys in
 python need to be strings. If I try to do the following, Python,of
 course, complains that y,color,drilldown, etc are not defined.


 import json

 data = [ { y:55.11, color:colors[0], drilldown:{name: 'MSIE
 versions',categories: ['MSIE 6.0', 'MSIE 7.0', 'MSIE 8.0', 'MSIE
 9.0'],data: [10.85, 7.35, 33.06, 2.81],color: colors[0] }} ]

 data_string = json.dumps(data)


 Many thanks for any suggestions on how to do this.

>>> Just quote them:
>>> data = [ { 'y':55.11, 'color':colors[0], 'drilldown':{'name': 'MSIE
>>> versions', 'categories': ['MSIE 6.0', 'MSIE 7.0', 'MSIE 8.0', 'MSIE
>>> 9.0'],'data': [10.85, 7.35, 33.06, 2.81],'color': colors[0] }} ]
>>>
>>> Incidentally, dictionary keys in Python don't have to be strings,
>>> but merely  'hashable', which includes integers, floats and tuples
>>> amongst others.
>>
>> Thanks for your reply, but the javascript function expects option
>> names to be unquoted, otherwise it won't work.
>
> Both Python source code and JSON require the dictionary keys to be
> quoted, so using the json module to generate JavaScript code isn't
> going to give you what you want.
>
> It shouldn't be too difficult to write a simple function to do it,
> considering the limited range of types.
>
Here's such a function:

def dump_javascript(data):
if isinstance(data, dict):
items = []

for key, value in data.items():
items.append(key + ": " + dump_javascript(value))

return "{" + ", ".join(items) + "}"
elif isinstance(data, list):
items = []

for value in data:
items.append(dump_javascript(value))

return "[" + ", ".join(items) + "]"
else:
return json.dumps(data)
--
http://mail.python.org/mailman/listinfo/python-list

Re: re.search when used within an if/else fails

2012-11-21 Thread Kevin T

On Nov 20, 1:37 pm, Ian Kelly  wrote:
> On Tue, Nov 20, 2012 at 12:09 PM, Kevin T  wrote:
> > #if re.search( "rsrvd", sigName ) :   #version a
> > #if re.search( "rsrvd", sigName ) == None :   #version b
> > if re.search( "rsrvd", sigName ) is None :   #version bb
> >    print sigName
> >    newVal = "%s%s" % ('1'*signal['bits'] , newVal )
> > #else:                                 #version c
> > if re.search( "rsrvd", sigName ) != None :   #version d
> >    print sigName
> >    newVal = "%s%s" % ( '0'*signal['bits'],> newVal )
>
> > i can use either version a/b the else clause (version c) will not execute.
> > fortunately,  with version bb, the else clause will execute!!
>
> There must be some other difference in your testing.  I don't have
> Python 2.4 available, but I tried your version a in both Python 2.3
> and 2.5 using made-up values for sigName, and the else clause is
> executed in both.

I went back and tried version a again, blam it is/does work now ?!?!?
I am not sure what changed but version a was the original code that
wouldn't work.  All the examples i had read, showed version a as a
working version.  I spent significant time trying version a with
parens, spacing changes, different regex values to no avail.  hence
the creation of all the other versions.

thanks for your help.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Inconsistent behaviour os str.find/str.index when providing optional parameters

2012-11-21 Thread Alister

On Wed, 21 Nov 2012 04:43:57 -0800, Giacomo Alzetta wrote:

> I just came across this:
> 
 'spam'.find('', 5)
> -1
> 
> 
> Now, reading find's documentation:
> 
 print(str.find.__doc__)
> S.find(sub [,start [,end]]) -> int
> 
> Return the lowest index in S where substring sub is found,
> such that sub is contained within S[start:end].  Optional arguments
> start and end are interpreted as in slice notation.
> 
> Return -1 on failure.
> 
> Now, the empty string is a substring of every string so how can find
> fail?
> find, from the doc, should be generally be equivalent to
> S[start:end].find(substring) + start, except if the substring is not
> found but since the empty string is a substring of the empty string it
> should never fail.
> 
> Looking at the source code for find(in stringlib/find.h):
> 
> Py_LOCAL_INLINE(Py_ssize_t)
> stringlib_find(const STRINGLIB_CHAR* str, Py_ssize_t str_len,
>const STRINGLIB_CHAR* sub, Py_ssize_t sub_len,
>Py_ssize_t offset)
> {
> Py_ssize_t pos;
> 
> if (str_len < 0)
> return -1;
> 
> I believe it should be:
> 
> if (str_len < 0)
> return (sub_len == 0 ? 0 : -1);
> 
> Is there any reason of having this unexpected behaviour or was this
> simply overlooked?

why would you be searching for an empty string?
what result would you expect to get from such a search?



-- 
Turn your Pentium into an XT -- just add Windows! 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Yet another Python textbook

2012-11-21 Thread Colin J. Williams


On 20/11/2012 4:00 PM, Chris Angelico wrote:

On Wed, Nov 21, 2012 at 1:57 AM,   wrote:

Le mardi 20 novembre 2012 09:09:50 UTC+1, Chris Angelico a écrit :

On Tue, Nov 20, 2012 at 7:02 PM, Pavel Solin  wrote:


Perhaps you are right. Is there any statistics of how many Python



programmers are using 2.7 vs. 3? Most of people I know use 2.7.




If you're teaching Python, the stats are probably about zero for zero.

Start them off on Py3 and help move the world forward.



ChrisA




Do not count with me.

The absurd flexible string representation has practically
borrowed the idea to propose once Python has a teaching tool.


To the OP: jmf has an unnatural hatred of Python 3.3 and PEP 393
strings. Take no notice; the rest of the world sees this as a huge
advantage. Python is now in a VERY small group of languages (I'm aware
of just one other) that have absolutely proper Unicode handling *and*
efficient string handling.

ChrisA

It's interesting to see that someone else finds the format function to 
be a pain.  Perhaps the problem lies with the documentation.


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

Re: 10 sec poll - please reply!

2012-11-21 Thread Michael Herrmann

Dear all,

thanks so much for your replies. Based on your inputs, we have started to 
experiment with changes to our API. I hope to be able to present the results to 
you tomorrow.

Thanks again,
Michael

On Tuesday, November 20, 2012 1:18:38 PM UTC+1, Michael Herrmann wrote:
> Hi, 
> 
> 
> 
> I'm developing a GUI Automation library (http://www.getautoma.com) and am 
> having difficulty picking a name for the function that simulates key strokes. 
> I currently have it as 'type' but that clashes with the built-in function. 
> Example uses of 'type': 
> 
> 
> 
> type(ENTER)
> 
> 
> 
> type("Hello World!")
> 
> 
> 
> type(CTRL + 'a')
> 
> 
> 
> What, in your view, would be the most intuitive alternative name?
> 
> 
> 
> Here are my thoughts so far: I could call it 'press' but then our GUI 
> automation tool also allows you to click things and then "press" might be 
> mistaken for "pressing a button". A less ambiguous alternative is "type_keys" 
> but that is rather long and doesn't read as well, for instance in 
> type_keys(ENTER).
> 
> 
> 
> Thank you very much!

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

mysql insert with tuple

2012-11-21 Thread Christian

Hi ,

my purpose is a generic insert via  tuple , because the number of fields and 
can differ. But  I'm stucking .

ilist=['hello',None,7,None,None]

#This version works, but all varchar fields are in extra '' enclosed.
con.execute(""" INSERT INTO {} VALUES %r; """.format(table) , (tuple(ilist),))

#This produce (1054, "Unknown column 'None' in 'field list'"),
#but without None values it works.
con.execute(""" INSERT INTO {} VALUES %r; """.format(table) % (tuple(ilist),))


Many thanks,
Christian


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

Re: Web Frameworks Excessive Complexity

On Wed, Nov 21, 2012 at 9:49 AM, rh  wrote:
> On Tue, 20 Nov 2012 20:41:42 +0300
> Andriy Kornatskyy  wrote:
>> Cyclomatic (or conditional) complexity is a metric used to indicate
>> the complexity of a source code. Excessive complexity is something
>> that is beyond recommended level of 10 (threshold that points to the
>> fact the source code is too complex and refactoring is suggested).
>> Here is a list of web frameworks examined: bottle, cherrypy,
>> circuits, django, flask, pyramid, pysi, tornado, turbogears, web.py,
>> web2py and wheezy.web.
>>
>> You can read more here:
>>
>> http://mindref.blogspot.com/2012/11/python-web-excessive-complexity.html
>
> You are the author of wheezy.web right? Can't blame you for trying to
> market your product. The conclusions, or lack of, are meaningless to me.
> I have to get in and drive the car before I go all in and buy it.
>
> I'm looking at different technology right now on which to base a site.
> I tried pyramid and after install it consumed 92MB of disk. It seemed
> large and it turns out that it installed its own version of python.
> Seems more complex to me, yet another python on disk.

That's how virtualenvs (http://www.virtualenv.org/ ) normally work.
Not really Pyramid's fault, it's more a deficiency of the current
Python package management tools.

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

RE: Web Frameworks Excessive Complexity


Richard,

Thank you for the comment.

I have examined web frameworks for PEP8 and CC metrics already. Results are 
here:
http://mindref.blogspot.com/2012/10/python-web-pep8-consistency.html
http://mindref.blogspot.com/2012/11/python-web-excessive-complexity.html

Same applies to performance benchmarks:
http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html
http://mindref.blogspot.com/2012/10/python-web-reverse-urls-benchmark.html
http://mindref.blogspot.com/2012/10/python-web-caching-benchmark.html

and template engine related:
http://mindref.blogspot.com/2012/10/python-templates-benchmark.html
http://mindref.blogspot.com/2012/07/python-fastest-template.html

If there are any other metrics we can gather automatically I will be happy to 
run them.

Thank you for your interest of wheezy.web. Before you buy:

Demo application source:
https://bitbucket.org/akorn/wheezy.web/src/tip/demos/template
Demo application live:
http://wheezy.pythonanywhere.com/

Tutorial:
http://packages.python.org/wheezy.web/tutorial.html
Finished:
https://bitbucket.org/akorn/wheezy.web/src/tip/demos/guestbook

Try understand what is cache dependency and how you benefit of using it with 
content caching. Try relate it with web caching benchmark from above and 
imagine 99% of your web application content is served out from cache, even it 
is dynamic (you control content cache with cache dependency).

Thanks.

Andriy Kornatskyy


> To: python-list@python.org
> From: richard_hubb...@lavabit.com
> Subject: Re: Web Frameworks Excessive Complexity
> Date: Wed, 21 Nov 2012 09:49:39 -0800
>
> On Tue, 20 Nov 2012 20:41:42 +0300
> Andriy Kornatskyy  wrote:
>
> >
> > Cyclomatic (or conditional) complexity is a metric used to indicate
> > the complexity of a source code. Excessive complexity is something
> > that is beyond recommended level of 10 (threshold that points to the
> > fact the source code is too complex and refactoring is suggested).
> > Here is a list of web frameworks examined: bottle, cherrypy,
> > circuits, django, flask, pyramid, pysi, tornado, turbogears, web.py,
> > web2py and wheezy.web.
> >
> > You can read more here:
> >
> > http://mindref.blogspot.com/2012/11/python-web-excessive-complexity.html
>
> You are the author of wheezy.web right? Can't blame you for trying to
> market your product. The conclusions, or lack of, are meaningless to me.
> I have to get in and drive the car before I go all in and buy it.
>
> I'm looking at different technology right now on which to base a site.
> I tried pyramid and after install it consumed 92MB of disk. It seemed
> large and it turns out that it installed its own version of python.
> Seems more complex to me, yet another python on disk.
>
> Anyway if you're really serious about making a point that complexity
> matters you'll have to measure many more things than loc or cc.
>
> Did you look at the number of commits to the same file over time?
> Etc. Number of authors for same file? Etc., etc. Number of security
> fixes? There must be a correlation between complexity and insecurity.
> Maybe check for randomness of the code. Not sure how, maybe
> look for strange, non-idiomatic uses of the language.
>
> I'm no computer scientist and I'm sure there are volumes on all this.
>
> Then there's also the social side, how much discussion takes place
> about the software? Does more discussion mean more problems?
> More project vibrancy? You could check for vocab, etc.
>
> I'm gonna take a look at wheezy.web.
> >
> > Thanks.
> >
> > Comments or suggestions are welcome.
> >
> > Andriy Kornatskyy
> >
>
>
> --
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Constructing JSON data structures from non-string key python dictionaries

On Wed, Nov 21, 2012 at 7:48 AM, MRAB  wrote:
> On 2012-11-21 14:59, saikari78 wrote:
>>
>> Hi,
>>
>> I'm using the json module to  create a JSON string, then inserting that
>> string into a html template containing a javascript function (from the
>> highcharts library: http://www.highcharts.com/)

Nontrivial templating of JavaScript is generally a bad/inelegant
approach. I would instead suggest generating the JSON separately and
loading it from JavaScript via $.getJSON or similar. Or sticking the
JSON into a hidden part of the webpage and then using JSON.parse().

>> The json string I'm trying to create is to initialize a data variable in
>> the javascript function, that has the following example format.
>>
>>  data = [{
>>  y: 55.11,
>>  color: colors[0],
>>  drilldown: {
>>  name: 'MSIE versions',
>>  categories: ['MSIE 6.0', 'MSIE 7.0', 'MSIE 8.0',
>> 'MSIE 9.0'],
>>  data: [10.85, 7.35, 33.06, 2.81],
>>  color: colors[0]
>>  }
>>  }]
>>
>> However, I don't know how to do that because dictionary keys in python
>> need to be strings. If I try to do the following, Python,of course,
>> complains that y,color,drilldown, etc are not defined.
>>
>>
>> import json
>>
>> data = [ { y:55.11, color:colors[0], drilldown:{name: 'MSIE
>> versions',categories: ['MSIE 6.0', 'MSIE 7.0', 'MSIE 8.0', 'MSIE 9.0'],data:
>> [10.85, 7.35, 33.06, 2.81],color: colors[0] }} ]
>>
>> data_string = json.dumps(data)
>>
>>
>> Many thanks for any suggestions on how to do this.
>>
> Just quote them:
>
>
> data = [ { 'y':55.11, 'color':colors[0], 'drilldown':{'name': 'MSIE
> versions','categories': ['MSIE 6.0', 'MSIE 7.0', 'MSIE 8.0', 'MSIE
> 9.0'],'data': [10.85, 7.35, 33.06, 2.81],'color': colors[0] }} ]
>
> Incidentally, dictionary keys in Python don't have to be strings, but
> merely 'hashable', which includes integers, floats and tuples amongst
> others.

On Wed, Nov 21, 2012 at 8:04 AM,   wrote:
> Thanks for your reply, but the javascript function expects option names to be 
> unquoted, otherwise it won't work.

As a user of HighCharts (and thus, unfortunately, JavaScript), I can
tell you that that's absolutely incorrect.
In JavaScript, {x : y}, {"x" : y}, and {'x' : y} are all equivalent
(at least when x is a valid JavaScript identifier; consult some
non-w3schools JavaScript docs).
Plus, you say you're using JSON; JSON *explicitly mandates that the
keys be quoted* (see RFC 4627).

You are experiencing Python NameErrors because {"x" : y} and {x : y}
aren't equivalent in Python. Python doesn't limit dicts keys to
strings, so `x` is a variable in the latter snippet; x's value is used
as the key.
You cannot expect to take arbitrary, unmodified JavaScript
code/literals, copy-paste them into Python, and expect them to work.

TL;DR:
# foo.py
from json import dumps

colors = SOME_LIST

data = [dict( # use dict() to avoid tedious quoting
y=55.11,
color=colors[0],
drilldown=dict(
name='MSIE versions',
categories=['MSIE 6.0', 'MSIE 7.0', 'MSIE 8.0', 'MSIE 9.0'],
data=[10.85, 7.35, 33.06, 2.81],
color=colors[0],
)
)]

your_json = dumps(data)
# ...serve the JSON somehow...

// bar.js
// Not industrial-strength. Assumes the use of jQuery.
// ...
$.getJSON(SOME_URL, function (data) {
// use 'data', which will be a JavaScript object by this point
});
// ...

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

Re: Web Frameworks Excessive Complexity

On Wed, Nov 21, 2012 at 10:57 AM, rh  wrote:
> On Wed, 21 Nov 2012 10:12:26 -0800
> Chris Rebert  wrote:
>> On Wed, Nov 21, 2012 at 9:49 AM, rh 
>> wrote:
>> > On Tue, 20 Nov 2012 20:41:42 +0300
>> > Andriy Kornatskyy  wrote:

>> > I'm looking at different technology right now on which to base a
>> > site. I tried pyramid and after install it consumed 92MB of disk.
>> > It seemed large and it turns out that it installed its own version
>> > of python. Seems more complex to me, yet another python on disk.
>>
>> That's how virtualenvs (http://www.virtualenv.org/ ) normally work.
>> Not really Pyramid's fault, it's more a deficiency of the current
>> Python package management tools.
>
> There's still 92MB under pyramid, I just installed a new virtualenv and
> installed wheezy.web, grand total 3.3MB.
>
> What deficiency?

"install[ing] its own version of python"

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

Re: Inconsistent behaviour os str.find/str.index when providing optional parameters

2012-11-21 Thread Hans Mulder

On 21/11/12 17:59:05, Alister wrote:
> On Wed, 21 Nov 2012 04:43:57 -0800, Giacomo Alzetta wrote:
> 
>> I just came across this:
>>
> 'spam'.find('', 5)
>> -1
>>
>>
>> Now, reading find's documentation:
>>
> print(str.find.__doc__)
>> S.find(sub [,start [,end]]) -> int
>>
>> Return the lowest index in S where substring sub is found,
>> such that sub is contained within S[start:end].  Optional arguments
>> start and end are interpreted as in slice notation.
>>
>> Return -1 on failure.
>>
>> Now, the empty string is a substring of every string so how can find
>> fail?
>> find, from the doc, should be generally be equivalent to
>> S[start:end].find(substring) + start, except if the substring is not
>> found but since the empty string is a substring of the empty string it
>> should never fail.
>>
>> Looking at the source code for find(in stringlib/find.h):
>>
>> Py_LOCAL_INLINE(Py_ssize_t)
>> stringlib_find(const STRINGLIB_CHAR* str, Py_ssize_t str_len,
>>const STRINGLIB_CHAR* sub, Py_ssize_t sub_len,
>>Py_ssize_t offset)
>> {
>> Py_ssize_t pos;
>>
>> if (str_len < 0)
>> return -1;
>>
>> I believe it should be:
>>
>> if (str_len < 0)
>> return (sub_len == 0 ? 0 : -1);
>>
>> Is there any reason of having this unexpected behaviour or was this
>> simply overlooked?
> 
> why would you be searching for an empty string?
> what result would you expect to get from such a search?


In general, if

needle in haystack[ start: ]

return True, then you' expect

haystack.find(needle, start)

to return the smallest i >= start such that

haystack[i:i+len(needle)] == needle

also returns True.

>>> "" in "spam"[5:]
True
>>> "spam"[5:5+len("")] == ""
True
>>>

So, you'd expect that spam.find("", 5) would return 5.

The only other consistent position would be that "spam"[5:]
should raise an IndexError, because 5 is an invalid index.

For that matter, I wouldn;t mind if "spam".find(s, 5) were
to raise an IndexError.  But if slicing at position 5
proudces an empry string, then .find should be able to
find that empty string.

-- HansM

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

Re: windows question: default click action points to wrong python version

2012-11-21 Thread Gelonida N

Hi Tim,

Thanks a lot for your answer.

On 11/21/2012 10:34 AM, Tim Golden wrote:

On 21/11/2012 08:23, Gelonida N wrote:

Hi,

I installed python 2.6 and python 2.7 on a windows 7 machine.

At the moment Python 2.7 is the interpreter being used if I 'start' a
python script without explicit interpreter.

I always thought, that 'repairing' Python 2.6 (reinstalling it) would
set the default settings back to Python 2.6.

I also see with assoc / ftypes, that python 2.6. has now been configured
as default.

However when I click on a script it is still started with 2.7.
(even after a full restart of the machine)

This is really surprising to me.
I thought ftype is the command to change file associations.

This area is a bit messy. There is a difference between: going to the
command line and typing "myscript.py"; and double-clicking on a file in
Explorer.

The former uses the result of merging the assoc/ftype registry keys:

HKEY_CURRENT_USER\Software\Classes\Python.File\shell\open\command

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Python.File\shell\open\command

while the latter uses the Explorer registry keys at:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py\UserChoice

Initially, I suppose, the two are in sync. But presumably they can get
out of sync, especially if you move backwards and forwards between
associations. I haven't bothered fishing around in the Shell API but I
presume that you can reconcile the two -- or just edit the registry,
obviously.

Hmm I don't mind changing the registry, now that I know the culprit.
Will try it tomorrow when being back to my Win PC.

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

logger doesn't roll over

2012-11-21 Thread cerr

Hi,

I'm using Python's logger for logging but it doesn't seem to roll over, my file 
is now 2.2MB and should've rolled over after ever 1MB.
My code:
logger = logging.getLogger("")
logger.setLevel(logging.DEBUG)
handler = logging.handlers.RotatingFileHandler(
LOGFILE, maxBytes=(1048576*10), backupCount=5
)

What am I doing wrong here, I don't get it.
Thank you!
Ron
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: mysql insert with tuple

On Wed, Nov 21, 2012 at 9:19 AM, Christian  wrote:
> Hi ,
>
> my purpose is a generic insert via  tuple , because the number of fields and 
> can differ. But  I'm stucking .
>
> ilist=['hello',None,7,None,None]
>
> #This version works, but all varchar fields are in extra '' enclosed.
> con.execute(""" INSERT INTO {} VALUES %r; """.format(table) , (tuple(ilist),))

A. "%r" is not a valid SQL/MySQLdb parameter specification (nor part
of Python's format() mini-language).
B. You don't need to enclose `ilist` in a singleton tuple. (Or convert
it to a tuple, for that matter.)

This should work:
# assuming `table` isn't obtained from untrusted input...
paramspec = ",".join(["%s"] * len(ilist))
con.execute("""INSERT INTO {} VALUES {};""".format(table, paramspec) , ilist)

But really, I would recommend instead using a more abstract database
library (e.g. SQLAlchemy, SQLObject, etc.), which safely and
conveniently constructs the SQL strings for you.

> #This produce (1054, "Unknown column 'None' in 'field list'"),
> #but without None values it works.
> con.execute(""" INSERT INTO {} VALUES %r; """.format(table) % (tuple(ilist),))

This is an SQL injection (http://en.wikipedia.org/wiki/SQL_injection )
waiting to happen!

Regards,
Chris

P.S. Where's my mining fact? ;-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: mysql insert with tuple

2012-11-21 Thread Hans Mulder

On 21/11/12 18:19:15, Christian wrote:
> Hi ,
> 
> my purpose is a generic insert via  tuple , because the number of fields and 
> can differ. But  I'm stucking .
> 
> ilist=['hello',None,7,None,None]
> 
> #This version works, but all varchar fields are in extra '' enclosed.
> con.execute(""" INSERT INTO {} VALUES %r; """.format(table) , (tuple(ilist),))
> 
> #This produce (1054, "Unknown column 'None' in 'field list'"),
> #but without None values it works.
> con.execute(""" INSERT INTO {} VALUES %r; """.format(table) % (tuple(ilist),))

How about:

con.execute("""INSERT INTO {} VALUES ({})"""
.format(table, ",".join("%s" for _ in ilist)), ilist)

Or perhaps break it down into smaller steps:

bind_variables = ",".join("%s" for _ in ilist))
query = "INSERT INTO {} VALUES ({})".format(table, bind_variables)
con.execute(query, ilist)


Hope this helps,

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

Re: logger doesn't roll over

2012-11-21 Thread Gary Chambers


Ron,


LOGFILE, maxBytes=(1048576*10), backupCount=5
What am I doing wrong here, I don't get it.


10 * 1048576 = 10MB

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

Re: logger doesn't roll over

2012-11-21 Thread Ron Eggler


Hooops sh*t! I outsmarted myself I guess... :o

However, Thanks for the kick GC!

Ron Eggler
1804 - 1122 Gilford St.
Vancouver, BC
V6G 2P5
(778) 230-9442

On 12-11-21 11:41 AM, Gary Chambers wrote:

Ron,


LOGFILE, maxBytes=(1048576*10), backupCount=5
What am I doing wrong here, I don't get it.


10 * 1048576 = 10MB

--
GC


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

Building python, bz2 coming up missing

2012-11-21 Thread Dan Stromberg

I'm attempting to build cpython 2.{5,6,7} and cpython 3.[0,1,2,3}.  I find
that having them all around facilitates interversion testing and
discovering what works in which versions.

Anyway, in 3.3, I'm getting a bz2 module, but in 3.2, I'm not - but only
when compiling on Linux Mint 14.  On Linux Mint 13, I got a bz2 module in
all my builds.

In 3.2 on Linux Mint 14, I get the familiar:
Python build finished, but the necessary bits to build these modules were
not found:
_curses_curses_panel  _dbm
_gdbm  _sqlite3   _ssl
_tkinter   bz2ossaudiodev
readline   zlib
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.

Except I definitely installed a bz2 "dev" package.  Actually, I also
installed gdbm and Berkeley DB dev packages.

Any suggestions?

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

Re: Inconsistent behaviour os str.find/str.index when providing optional parameters

2012-11-21 Thread Giacomo Alzetta

Il giorno mercoledì 21 novembre 2012 20:25:10 UTC+1, Hans Mulder ha scritto:
> On 21/11/12 17:59:05, Alister wrote:
> 
> > On Wed, 21 Nov 2012 04:43:57 -0800, Giacomo Alzetta wrote:
> 
> > 
> 
> >> I just came across this:
> 
> >>
> 
> > 'spam'.find('', 5)
> 
> >> -1
> 
> >>
> 
> >>
> 
> >> Now, reading find's documentation:
> 
> >>
> 
> > print(str.find.__doc__)
> 
> >> S.find(sub [,start [,end]]) -> int
> 
> >>
> 
> >> Return the lowest index in S where substring sub is found,
> 
> >> such that sub is contained within S[start:end].  Optional arguments
> 
> >> start and end are interpreted as in slice notation.
> 
> >>
> 
> >> Return -1 on failure.
> 
> >>
> 
> >> Now, the empty string is a substring of every string so how can find
> 
> >> fail?
> 
> >> find, from the doc, should be generally be equivalent to
> 
> >> S[start:end].find(substring) + start, except if the substring is not
> 
> >> found but since the empty string is a substring of the empty string it
> 
> >> should never fail.
> 
> >>
> 
> >> Looking at the source code for find(in stringlib/find.h):
> 
> >>
> 
> >> Py_LOCAL_INLINE(Py_ssize_t)
> 
> >> stringlib_find(const STRINGLIB_CHAR* str, Py_ssize_t str_len,
> 
> >>const STRINGLIB_CHAR* sub, Py_ssize_t sub_len,
> 
> >>Py_ssize_t offset)
> 
> >> {
> 
> >> Py_ssize_t pos;
> 
> >>
> 
> >> if (str_len < 0)
> 
> >> return -1;
> 
> >>
> 
> >> I believe it should be:
> 
> >>
> 
> >> if (str_len < 0)
> 
> >> return (sub_len == 0 ? 0 : -1);
> 
> >>
> 
> >> Is there any reason of having this unexpected behaviour or was this
> 
> >> simply overlooked?
> 
> > 
> 
> > why would you be searching for an empty string?
> 
> > what result would you expect to get from such a search?
> 
> 
> 
> 
> 
> In general, if
> 
> 
> 
> needle in haystack[ start: ]
> 
> 
> 
> return True, then you' expect
> 
> 
> 
> haystack.find(needle, start)
> 
> 
> 
> to return the smallest i >= start such that
> 
> 
> 
> haystack[i:i+len(needle)] == needle
> 
> 
> 
> also returns True.
> 
> 
> 
> >>> "" in "spam"[5:]
> 
> True
> 
> >>> "spam"[5:5+len("")] == ""
> 
> True
> 
> >>>
> 
> 
> 
> So, you'd expect that spam.find("", 5) would return 5.
> 
> 
> 
> The only other consistent position would be that "spam"[5:]
> 
> should raise an IndexError, because 5 is an invalid index.
> 
> 
> 
> For that matter, I wouldn;t mind if "spam".find(s, 5) were
> 
> to raise an IndexError.  But if slicing at position 5
> 
> proudces an empry string, then .find should be able to
> 
> find that empty string.
> 
> 
> 
> -- HansM

Exactly! Either string[i:] with i >= len(string) should raise an IndexError or 
find(string, i) should return i.

Anyway, thinking about this inconsistency can be solved in a simpler way and 
without adding comparson. You simply check the substring length first. If it is 
0 you already know that the string is a substring of the given string and you 
return the "offset", so the two ifs at the beginning of the function ought to 
be swapped.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Inconsistent behaviour os str.find/str.index when providing optional parameters


On 2012-11-21 19:25, Hans Mulder wrote:

On 21/11/12 17:59:05, Alister wrote:

On Wed, 21 Nov 2012 04:43:57 -0800, Giacomo Alzetta wrote:


I just came across this:


'spam'.find('', 5)

-1


Now, reading find's documentation:


print(str.find.__doc__)

S.find(sub [,start [,end]]) -> int

Return the lowest index in S where substring sub is found,
such that sub is contained within S[start:end].  Optional arguments
start and end are interpreted as in slice notation.

Return -1 on failure.

Now, the empty string is a substring of every string so how can find
fail?
find, from the doc, should be generally be equivalent to
S[start:end].find(substring) + start, except if the substring is not
found but since the empty string is a substring of the empty string it
should never fail.

Looking at the source code for find(in stringlib/find.h):

Py_LOCAL_INLINE(Py_ssize_t)
stringlib_find(const STRINGLIB_CHAR* str, Py_ssize_t str_len,
   const STRINGLIB_CHAR* sub, Py_ssize_t sub_len,
   Py_ssize_t offset)
{
Py_ssize_t pos;

if (str_len < 0)
return -1;

I believe it should be:

if (str_len < 0)
return (sub_len == 0 ? 0 : -1);

Is there any reason of having this unexpected behaviour or was this
simply overlooked?


why would you be searching for an empty string?
what result would you expect to get from such a search?



In general, if

 needle in haystack[ start: ]

return True, then you' expect

 haystack.find(needle, start)

to return the smallest i >= start such that

 haystack[i:i+len(needle)] == needle

also returns True.


"" in "spam"[5:]

True

"spam"[5:5+len("")] == ""

True




So, you'd expect that spam.find("", 5) would return 5.

The only other consistent position would be that "spam"[5:]
should raise an IndexError, because 5 is an invalid index.

For that matter, I wouldn;t mind if "spam".find(s, 5) were
to raise an IndexError.  But if slicing at position 5
proudces an empry string, then .find should be able to
find that empty string.


You'd expect that given:

found = string.find(something, start, end)

if 'something' present then the following are true:

0 <= found <= len(string)

start <= found <= end

(I'm assuming here that 'start' and 'end' have already been adjusted
for counting from the end, ie originally they might have been negative
values.)

The only time that you can have found == len(string) and found == end
is when something == "" and start == len(string).

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

Re: logger doesn't roll over

2012-11-21 Thread Paul Rubin

cerr  writes:
> 2.2MB and should've rolled over after ever 1MB.
>   LOGFILE, maxBytes=(1048576*10), backupCount=5

1048576*10 is 10MB, not 1MB.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: windows question: default click action points to wrong python version

2012-11-21 Thread Tim Golden


On 21/11/2012 20:53, Tony the Tiger wrote:

On Wed, 21 Nov 2012 09:23:00 +0100, Gelonida N wrote:


What am I missing?


The PATH environment variable?


Nope. PATH doesn't affect either double-clicking or running a .py file 
on the command line (unless, obviously, you run it by typing "python 
myscript.py").


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

Re: Inconsistent behaviour os str.find/str.index when providing optional parameters

2012-11-21 Thread Joshua Landau



On 21 November 2012 20:58, MRAB  wrote:

> On 2012-11-21 19:25, Hans Mulder wrote:
>
>> On 21/11/12 17:59:05, Alister wrote:
>>
>>> On Wed, 21 Nov 2012 04:43:57 -0800, Giacomo Alzetta wrote:

  'spam'.find('', 5)
>>>
>> -1

 Now, reading find's documentation:

  print(str.find.__doc__)
>>>
>> S.find(sub [,start [,end]]) -> int

 Return the lowest index in S where substring sub is found,
 such that sub is contained within S[start:end].  Optional arguments
 start and end are interpreted as in slice notation.

 Return -1 on failure.
>>>
>>>
>>>
>>>  why would you be searching for an empty string?
>>> what result would you expect to get from such a search?
>>>
>>
>> In general, if
>>
>>  needle in haystack[ start: ]
>>
>> return True, then you' expect
>>
>>  haystack.find(needle, start)
>>
>> to return the smallest i >= start such that
>>
>>  haystack[i:i+len(needle)] == needle
>>
>> also returns True.
>>
>> The only other consistent position would be that "spam"[5:]
>> should raise an IndexError, because 5 is an invalid index.
>
>
>
>  You'd expect that given:
>
> found = string.find(something, start, end)
>
> if 'something' present then the following are true:
>
> 0 <= found <= len(string)
>
> start <= found <= end
>

I don't think I agree.

I think *only* the second holds, but start "defaults" to 0 and end to
len(string), which is consistent with Han's method and thus conclusion.

Of course this is merely opinion and practicality beats purity, but it
seems logical, considering the slicing synonym.

Even if functionally this remains unchanged, the docstring should be edited
to reflect this oddity.

(I'm assuming here that 'start' and 'end' have already been adjusted
> for counting from the end, ie originally they might have been negative
> values.)
>
> The only time that you can have found == len(string) and found == end
> is when something == "" and start == len(string).
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problem with subprocess.call and windows schtasks

2012-11-21 Thread Tom Borkin

On Wed, Nov 21, 2012 at 6:01 AM, Tim Golden  wrote:

> subprocess.call([
>   'SchTasks', '/Create',
>   '/SC', 'ONCE',
>   '/TN', 'test',
>   '/TR', path,
>   '/ST', '23:50'
> ])
>
Thank you. Yes, it was the quoting of "test". Oops :-}
Thanks again,
Tom
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Frameworks Excessive Complexity

2012-11-21 Thread Chris Angelico

On Wed, Nov 21, 2012 at 10:43 PM, Steven D'Aprano
 wrote:
> On Wed, 21 Nov 2012 22:21:23 +1100, Chris Angelico wrote:
>
>> Counting complexity by giving a score to every statement encourages code
>> like this:
>>
>> def bletch(x,y):
>>   return x + {"foo":y*2,"bar":x*3+y,"quux":math.sin(y)}.get(mode,0)
>>
>> instead of:
>>
>> def bletch(x,y):
>>   if mode=="foo": return x+y*2
>>   if mode=="bar": return x*4+y
>>   if mode=="quux": return x+math.sin(y) return x
>>
>> Okay, this is a stupid contrived example, but tell me which of those
>> you'd rather work with
>
>
> Am I being paid by the hour or the line?

You're on a salary, but management specified some kind of code metrics
as a means of recognizing which of their programmers are more
productive, and thus who gets promoted.

Oh, I'm *so* glad I work in a small company. We've only had one
programmer that we "let go" (and actually, it was literally letting
him go - he said he was no good, hoping that we'd beg him to stay, and
we simply didn't beg him to stay), and the metric of code quality was
simply that both my boss and I looked at his code and said that it
wasn't good enough. Much simpler. (Though my boss and I have differing
views on how many lines of code some things should be. We end up
having some rather amusing debates about trivial things like line
breaks.)

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

Re: Yet another Python textbook

2012-11-21 Thread Chris Angelico

On Thu, Nov 22, 2012 at 4:03 AM, Colin J. Williams  wrote:
> On 20/11/2012 4:00 PM, Chris Angelico wrote:
>> To the OP: jmf has an unnatural hatred of Python 3.3 and PEP 393
>> strings. Take no notice; the rest of the world sees this as a huge
>> advantage. Python is now in a VERY small group of languages (I'm aware
>> of just one other) that have absolutely proper Unicode handling *and*
>> efficient string handling.
>>
>> ChrisA
>>
> It's interesting to see that someone else finds the format function to be a
> pain.  Perhaps the problem lies with the documentation.

Hang on, what? I'm not sure where the format function comes in. I was
referring to the underlying representation.

That said, though, I'm just glad that %-formatting is staying. It's an
extremely expressive string formatting method, and exists in many
languages (thanks to C's heritage). Pike's version is insanely
powerful, Python's is more like C's, but all three are compact and
convenient.

str.format(), on the other hand, is flexible. It strikes me as rather
more complicated than a string formatting function needs to be, but
that may be a cost of its flexibility.

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

Re: 10 sec poll - please reply!

2012-11-21 Thread Andrew Cooper

On 21/11/2012 07:01, Steven D'Aprano wrote:
> On Wed, 21 Nov 2012 17:35:27 +1100, Chris Angelico wrote:
> 
>> And yet, trivial though it may seem, function naming in a permanent API
>> is pretty important. Threads like this can be the difference between
>> coherent and useful APIs and veritable piles of excrement.
> 
> 
> "There are only two hard problems in Computer Science: cache invalidation 
> and naming things." -- Phil Karlton
> 

"counting" is missing from that list of two hard problems.

~Andrew

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

Re: Yet another Python textbook

On 11/21/2012 05:17 PM, Chris Angelico wrote:
> 
>
>
> That said, though, I'm just glad that %-formatting is staying. It's an
> extremely expressive string formatting method, and exists in many
> languages (thanks to C's heritage). Pike's version is insanely
> powerful, Python's is more like C's, but all three are compact and
> convenient.
>
> str.format(), on the other hand, is flexible. It strikes me as rather
> more complicated than a string formatting function needs to be, but
> that may be a cost of its flexibility.
>
>

Some don't realize that one very powerful use for the .format style of
working is that it makes localization much more straightforward.  With
the curly brace approach, one can translate the format string into
another language, and if the parameters have to be substituted in
another order, it's all in one place.

Twenty years ago, I implemented such a thing for our product (C++), for
just that reason.   I'm sure that by now, the libraries exist somewhere
in the C++ stdlibs, or at least in  Boost.

-- 

DaveA

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

Re: Yet another Python textbook

2012-11-21 Thread Ian Kelly

On Wed, Nov 21, 2012 at 3:58 PM, Dave Angel  wrote:
> Some don't realize that one very powerful use for the .format style of
> working is that it makes localization much more straightforward.  With
> the curly brace approach, one can translate the format string into
> another language, and if the parameters have to be substituted in
> another order, it's all in one place.

It only matters with positional placeholders, though.  You can achieve
the same thing using named placeholders, which both major formatting
styles support.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Yet another Python textbook

2012-11-21 Thread Joshua Landau

On 21 November 2012 22:17, Chris Angelico  wrote:

> On Thu, Nov 22, 2012 at 4:03 AM, Colin J. Williams  wrote:
> > On 20/11/2012 4:00 PM, Chris Angelico wrote:
> >> To the OP: jmf has an unnatural hatred of Python 3.3 and PEP 393
> >> strings. Take no notice; the rest of the world sees this as a huge
> >> advantage. Python is now in a VERY small group of languages (I'm aware
> >> of just one other) that have absolutely proper Unicode handling *and*
> >> efficient string handling.
> >>
> >> ChrisA
> >>
> > It's interesting to see that someone else finds the format function to
> be a
> > pain.  Perhaps the problem lies with the documentation.
>
> Hang on, what? I'm not sure where the format function comes in. I was
> referring to the underlying representation.
>
> That said, though, I'm just glad that %-formatting is staying. It's an
> extremely expressive string formatting method, and exists in many
> languages (thanks to C's heritage). Pike's version is insanely
> powerful, Python's is more like C's, but all three are compact and
> convenient.
>
> str.format(), on the other hand, is flexible. It strikes me as rather
> more complicated than a string formatting function needs to be, but
> that may be a cost of its flexibility.
>

Since we've decided to derail the conversation...

"{}".format() is a blessing an "" % () should go. "%" has no relevance to
strings, is hard to "get" and has an appalling* syntax. Having two syntaxes
just makes things less obvious, and the right choice rarer.

str.format is also really easy. I don't understand what makes you disagree.

Easy vs easier:

>>> "%s %s %s" % (1, 2, 3)
'1 2 3'

>>> "{} {} {}".format(1, 2, 3)
'1 2 3'

Easy vs easier:

>>> "You have %(spam)s spam and %(eggs)s eggs!" % {"spam": 43, "eggs": 120}
'You have 43 spam and 120 eggs!'

>>> "You have {spam} spam and {eggs} eggs!".format(spam=43, eggs=120)

>>> "You have {spam} spam and {eggs} eggs!".format(**{"spam": 43, "eggs":
120})
'You have 43 spam and 120 eggs!'

Eh...? vs easy:

>>> "Thing %s has state %+o!" % ("#432", 14)
'Thing #432 has state +16!

>>> "Thing {} has state {:+o}!".format("#432", 14)
'Thing #432 has state +16!'

*Additionally*, a = str.format is much *better* than a = str.__mod__.

I have a piece of code like this:
"{fuscia}{{category__name}}/{reset}{{name}} {green}{{version}}{reset}:\n
 {{description}}"

Which *would* have looked like this:
"%(fuscia)s%%(category__name)s/%(reset)s%%(name)s
%(green)s%%(version)s%(reset)s:\n%%(description)s"

Which would have parsed to something like:
'FUSCIA{category__name}/RESET{name} GREEN{version}RESET:\n{description}'
and
'FUSCIA%(category__name)s/RESET%(name)s GREEN%(version)sRESET:\n
 %(description)s'

Can you seriously say you don't mind the "%(name)s"s in this?

* "A {} is in the {}" vs "A %s is in the %s"?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Yet another Python textbook

2012-11-21 Thread Steven D'Aprano

On Wed, 21 Nov 2012 12:03:30 -0500, Colin J. Williams wrote:

> On 20/11/2012 4:00 PM, Chris Angelico wrote:

>> To the OP: jmf has an unnatural hatred of Python 3.3 and PEP 393
>> strings. Take no notice; the rest of the world sees this as a huge
>> advantage. Python is now in a VERY small group of languages (I'm aware
>> of just one other) that have absolutely proper Unicode handling *and*
>> efficient string handling.
>>
>> ChrisA
>>
> It's interesting to see that someone else finds the format function to
> be a pain.  Perhaps the problem lies with the documentation.

This is nothing to do with the format function. Chris, and JMF, is 
talking about the internal representation of strings in Python.

Python 3.3 fixes a long-running design flaw that causes Unicode strings 
to be buggy (the use of so-called "surrogate pairs" for characters 
outside of the Basic Multilingual Plane), *and* saves up to 75% of the 
memory used by strings (reducing it from up to 4 bytes per character to 
as little as 1 byte per character), but at the cost of a trivially small 
slowdown under some circumstances.

JMF is obsessed with the idea that Python is destroying Unicode for the 
benefit of the Americans. It's quite sad really.

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

Re: Yet another Python textbook

2012-11-21 Thread Mark Lawrence


On 21/11/2012 23:21, Joshua Landau wrote:

On 21 November 2012 22:17, Chris Angelico  wrote:


On Thu, Nov 22, 2012 at 4:03 AM, Colin J. Williams  wrote:

On 20/11/2012 4:00 PM, Chris Angelico wrote:

To the OP: jmf has an unnatural hatred of Python 3.3 and PEP 393
strings. Take no notice; the rest of the world sees this as a huge
advantage. Python is now in a VERY small group of languages (I'm aware
of just one other) that have absolutely proper Unicode handling *and*
efficient string handling.

ChrisA


It's interesting to see that someone else finds the format function to

be a

pain.  Perhaps the problem lies with the documentation.


Hang on, what? I'm not sure where the format function comes in. I was
referring to the underlying representation.

That said, though, I'm just glad that %-formatting is staying. It's an
extremely expressive string formatting method, and exists in many
languages (thanks to C's heritage). Pike's version is insanely
powerful, Python's is more like C's, but all three are compact and
convenient.

str.format(), on the other hand, is flexible. It strikes me as rather
more complicated than a string formatting function needs to be, but
that may be a cost of its flexibility.



Since we've decided to derail the conversation...

"{}".format() is a blessing an "" % () should go. "%" has no relevance to
strings, is hard to "get" and has an appalling* syntax. Having two syntaxes
just makes things less obvious, and the right choice rarer.

str.format is also really easy. I don't understand what makes you disagree.

Easy vs easier:


"%s %s %s" % (1, 2, 3)

'1 2 3'


"{} {} {}".format(1, 2, 3)

'1 2 3'

Easy vs easier:


"You have %(spam)s spam and %(eggs)s eggs!" % {"spam": 43, "eggs": 120}

'You have 43 spam and 120 eggs!'


"You have {spam} spam and {eggs} eggs!".format(spam=43, eggs=120)



"You have {spam} spam and {eggs} eggs!".format(**{"spam": 43, "eggs":

120})
'You have 43 spam and 120 eggs!'

Eh...? vs easy:


"Thing %s has state %+o!" % ("#432", 14)

'Thing #432 has state +16!


"Thing {} has state {:+o}!".format("#432", 14)

'Thing #432 has state +16!'

*Additionally*, a = str.format is much *better* than a = str.__mod__.

I have a piece of code like this:
"{fuscia}{{category__name}}/{reset}{{name}} {green}{{version}}{reset}:\n
  {{description}}"

Which *would* have looked like this:
"%(fuscia)s%%(category__name)s/%(reset)s%%(name)s
%(green)s%%(version)s%(reset)s:\n%%(description)s"

Which would have parsed to something like:
'FUSCIA{category__name}/RESET{name} GREEN{version}RESET:\n{description}'
and
'FUSCIA%(category__name)s/RESET%(name)s GREEN%(version)sRESET:\n
  %(description)s'

Can you seriously say you don't mind the "%(name)s"s in this?

* "A {} is in the {}" vs "A %s is in the %s"?





C %f style formatting is never going to go so live with it.  I know as I 
asked maybe two years ago.  On Python-dev.  I think.


--
Cheers.

Mark Lawrence.

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

Re: Yet another Python textbook

2012-11-21 Thread Ian Kelly

On Wed, Nov 21, 2012 at 4:21 PM, Joshua Landau
 wrote:
> "{}".format() is a blessing an "" % () should go. "%" has no relevance to
> strings, is hard to "get" and has an appalling* syntax. Having two syntaxes
> just makes things less obvious, and the right choice rarer.
>
> str.format is also really easy. I don't understand what makes you disagree.

I think it mostly depends on where you come from as a programmer.  As
you say, having two syntaxes muddles things up.  If you come from C or
C++, then the %s syntax feels natural and intuitive, and trying to
learn the sort-of-similar-but-not-really {} syntax on top of it is
just confusing.  Conversely, if you come from Java or C#, then the {}
syntax comes naturally, and having to learn %s in addition will give
one a headache.  And then there are those who come from Lisp and want
to know why they can't just use the familiarly easy ~a syntax.

None of these are really any easier than the others.  But they are
sort of similar at a superficial level, which just makes it that much
more painful to learn one when you're already accustomed to another.

I think my favorite example from the str.format documentation is this
one.  Apart from demonstrating the flexibility of the format system,
it also manages to mix the two systems in a most unholy way:

>>> import datetime
>>> d = datetime.datetime(2010, 7, 4, 12, 15, 58)
>>> '{:%Y-%m-%d %H:%M:%S}'.format(d)
'2010-07-04 12:15:58'
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Building python, bz2 coming up missing

2012-11-21 Thread Dan Stromberg

On Wed, Nov 21, 2012 at 12:18 PM, Dan Stromberg  wrote:

>
> I'm attempting to build cpython 2.{5,6,7} and cpython 3.[0,1,2,3}.  I find
> that having them all around facilitates interversion testing and
> discovering what works in which versions.
>
> Anyway, in 3.3, I'm getting a bz2 module, but in 3.2, I'm not - but only
> when compiling on Linux Mint 14.  On Linux Mint 13, I got a bz2 module in
> all my builds.
>
> In 3.2 on Linux Mint 14, I get the familiar:
> Python build finished, but the necessary bits to build these modules were
> not found:
> _curses_curses_panel  _dbm
> _gdbm  _sqlite3   _ssl
> _tkinter   bz2ossaudiodev
> readline   zlib
> To find the necessary bits, look in setup.py in detect_modules() for the
> module's name.
>
> Except I definitely installed a bz2 "dev" package.  Actually, I also
> installed gdbm and Berkeley DB dev packages.
>

I've worked around the issue with:

export LDFLAGS="-L/usr/lib/i386-linux-gnu"

...prior to ./configure, but it'd still be nice to know a way of building
things without requiring this.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Yet another Python textbook

2012-11-21 Thread Pavel Solin

Hi Alec,

> Can you put your website—http://femhub.com/textbook-python/—on your
> github—https://github.com/femhub/nclab-textbook-python?

Done, thank you so much.

I edited the textbook based on responses that I received. Based
on several inquiries we also decided to add Python 3.2 to NCLab.
New release is coming in one or two weeks.

Cheers,

Pavel


On Wed, Nov 21, 2012 at 4:34 PM, Alec Taylor  wrote:

> Dear Prof. Solin,
>
> Can you put your website—http://femhub.com/textbook-python/—on your
> github—https://github.com/femhub/nclab-textbook-python?
>
> I will then send you a pull request with a bootstrapped homepage with good
> UX.
>
> All the best,
>
> Alec Taylor
>



-- 
Pavel Solin
Associate Professor
Applied and Computational Mathematics
University of Nevada, Reno
http://hpfem.org/~pavel
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Inconsistent behaviour os str.find/str.index when providing optional parameters

2012-11-21 Thread Terry Reedy

On 11/21/2012 8:32 AM, MRAB wrote:

On 2012-11-21 12:43, Giacomo Alzetta wrote:

I just came across this:

>>> 'spam'.find('')
0
>>> 'spam'.find('', 1)
1
>>> 'spam'.find('', 4)
4

'spam'.find('', 5)

-1

Now, reading find's documentation:

print(str.find.__doc__)

S.find(sub [,start [,end]]) -> int

Return the lowest index in S where substring sub is found,
such that sub is contained within S[start:end].  Optional
arguments start and end are interpreted as in slice notation.

This seems not to be true, as 'spam'[4:] == 'spam'[5:] == ''

Return -1 on failure.

Now, the empty string is a substring of every string so how can find
fail?
find, from the doc, should be generally be equivalent to
S[start:end].find(substring) + start, except if the substring is not
found but since the empty string is a substring of the empty string it
should never fail.

[snip]
I think that returning -1 is correct (as far as returning -1 instead of
raising an exception like .index could be considered correct!) because
otherwise it whould be returning a non-existent index. For the string
"spam", the range is 0..4.

I tend to agree, but perhaps the doc should be changed. In edge cases 
like this, there sometimes is no 'right' answer. I suspect that the 
current behavior is intentional. You might find a discussion on the tracker.

--
Terry Jan Reedy

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

Re: Inconsistent behaviour os str.find/str.index when providing optional parameters