TkinterTreectrl-2.0 released
Today after more than two years finally an updated version of the TkinterTreectrl wrapper module has been released. The TkinterTreectrl package wraps the treectrl tk extension (http://tktreectrl.sourceforge.net) for use with Python/Tkinter. The treectrl widget allows to create fancy things like sortable multi column listboxes and hierarchical tree views. The TkinterTreectrl package also contains a ready to use multi-column listbox widget and scrolled Treectrl and multi-column listboxes plus a generic scrolled widget class that makes it easy to add one or two static or automatic scrollbars to any Listbox-alike Tkinter widget. This new release brings a couple of major improvements: * Python-3 compatibility! The same module code now works with Python2 and Python3 (tested on debian squeeze with Python-2.6.6 and Python-3.1.3). * Themed scrolled widgets The ScrolledWidget class now automagically uses themed widgets if ttk is present. In order to keep backwards compatibility intact, ttk-incompatible configuration options that are passed to the scrolled widget's subwidgets, as bd or troughcolor will be silently ignored if ttk widgets are in use. * New methods and options The Treectrl widget now includes the new methods up to treectrl version 2.3.2 . For more details please look at the project page: http://tkintertreectrl.sourceforge.net/ The download is available at: https://sourceforge.net/projects/tkintertreectrl/files/ Regards Michael -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
windows question: default click action points to wrong python version
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. What am I missing? -- http://mail.python.org/mailman/listinfo/python-list
Re: Web Frameworks Excessive Complexity
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
Re: 10 sec poll - please reply!
Am Dienstag, 20. November 2012 13:18:38 UTC+1 schrieb Michael Herrmann: 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! I would expect 'type' or 'press'. 'type' is maybe not the best solution because of overloading. I like 'press'. Good luck, Mr. Michael ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: windows question: default click action points to wrong python version
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. TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with subprocess.call and windows schtasks
On 20/11/2012 23:41, Tom Borkin wrote: Using shlex, I now have this: #!\Python27\python import os, subprocess path = os.path.join(C:\\, Program Files, Apache Group, Apache2, htdocs, ccc, run_alert.py) #subprocess.call(['SchTasks', '/Create', '/SC', 'ONCE', '/TN', 'test', '/TR', path, '/ST', '23:50']) subprocess.call(['SchTasks', '/Create', '/SC', 'ONCE', '/TN', 'test', '/TR', 'run_alert.py', '/ST', '23:50']) Both of the above commands throw the same error: ERROR: The filename, directory name or volume label syntax is incorrect. The following works for me: import subprocess path = rC:\Program Files\Apache Group\Apache2\htdocs\ccc\run_alert.py subprocess.call([ 'SchTasks', '/Create', '/SC', 'ONCE', '/TN', 'test', '/TR', path, '/ST', '23:50' ]) Things to note: * I haven't added extra quoting to any of the items in the command list which is subprocess.call's first parameter. The point about using the list (as opposed to passing an entire string which you can also do) is that the subprocess module can quote things as needed. If you've already added quotes, you'll get double-quoting which you almost certainly don't want. * (Obviously) I've formatted the subprocess.call as I have for clarity, especially via email. It's just a list. TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Index Error
Yes i tried or also but no use . Explain no use. If you mean you still fail, then what else did you try? For example, did you try interchanging the two subscripts? I've suspected all along that the meanings of row and column, x and y, [0] and [1], height and width are possibly confused. Perhaps it'd be better if you used a similar terminology everywhere. I tried using or instead of and interchanging also, still the index error is coming. x is no of column(300) and y is no of rows(3000), [0] corresponds to x i.e. column and [1] corresponds to y i.e. row and lastly height is y i.e row and width is column i.e. x Or perhaps you should simply make a class called Point, with attributes x and y. And use instances of that class rather than tuples. And start the function by defining xmax and ymax, from data.height and data.width (in whatever order matches the docs of that library you're using) Ok should be added only when this condition is satisfied print point points.append(point) change = True print change break Why do you want to terminate the loop after only iteration? snip The idea here is if no more point is added to the list of points i.e. all points surrounding the centre is zero.. I want to break the loop and go to the next point.. That's not at all what the break does. But it's probably not what you meant to say anyway. I think what you're saying is that you want to append at most one of the points from the ring. In that case, the break is appropriate, but it'd be much clearer if it were inside the clause that triggers it, the place where you say points.append(point). (naturally, it'd be at the end of that clause, following print change.) In other words indent it to line up with print change. Yes done that.. I totally agree.. 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.. Have you actually tested a trivial nested loop: for cy in xrange(0, data.height): for cx in xrange(0, data.width): point = data[cy, cx] to see whether it blows up. And if it does, whether reversing cy and cx will change it? Yes , I tested this. Its working fine, reversing cy and cx is not correct Your comment in the line: if dist radius :and rings should be added only when this condition is satisfied is confusing to me. How can you make the call to GenerateRing() after this test, when this test is measuring something about one of the values returned by GenerateRing ? Actually , this is one of my condition.. but i think It means that when dist is greater than radius more points will not be added to the list , So the loop should stop here, and next centre should be taken, creating second list and so on.. 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://mail.python.org/mailman/listinfo/python-list
Re: Index Error
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
No, this creates a one dimensional list with 2N elements of where each
element is a two item tuple.
Yes, in programme it returns a list of tuples but pysically it is creating
a ring .
I need help in this part as I am
unable to device a method in which if the points are out of index,it
should stop and
if idx[0] = 300 and idx[1] = 3000:
go to next centre and start generating
rings from there.. and again if the index is out of range .. this should
repeat
continue
else :
point = data[idx[0], idx[1]]
You can use a few different methods. This is just one example.
for idx, temp_point in enumerate(new_indices):
try:
temp_point[0]
temp_point[1]
except Exception: #Should be IndexError I think.
print 'idx: {0}\ntemp_point:{1}'.format(idx, temp_point)
# Possibly add a break or exit so you do not have to
# keep going once you hit a failure.
point = data[temp_point[0], temp_point[1]]
Thank you for the suggestion.
What is `data`? I have not seen any built-in structure that takes
a tuple in this manner...unless it is a dictionary. Or from numpy.
Given my lack of knowledge of what `data`, it could be the
problem is there. That is one reason I accessed `temp_point[0]` and
`temp_point[1]` separately.
Data is an image.
Traceback (most recent call last):
File Z:/modules/Classify.py, line 73, in module
ComputeClasses(data)
File Z:/modules/Classify.py, line 49, in ComputeClasses
point = data[idx[0], idx[1]]
error: index is out of range
Is that the actual error? If so, then the problem is not `idx` or
`temp_point` but instead `data`. If it is not the exact error, please
copy and paste the error message *exactly* as given.
Sorry but this is the actual error .
--
http://mail.python.org/mailman/listinfo/python-list
RE: Web Frameworks Excessive Complexity
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
On Tuesday, November 20, 2012 6:03:47 PM UTC-5, Ian wrote:
On Tue, Nov 20, 2012 at 2:49 PM, Daniel Klein danielklei...@gmail.com 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 undefined
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
Python restriction? Please enlighten me.
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
Re: Web Frameworks Excessive Complexity
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
andriy.kornats...@live.com 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
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!
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
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: snip 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 stdin, line 1, in module 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: snip 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 module 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
snip 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
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
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
Le mardi 20 novembre 2012 22:00:49 UTC+1, Chris Angelico a écrit : On Wed, Nov 21, 2012 at 1:57 AM, wxjmfa...@gmail.com 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
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
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
On 2012-11-21, MRAB pyt...@mrabarnett.plus.com 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
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
On Nov 20, 1:37 pm, Ian Kelly ian.g.ke...@gmail.com wrote:
On Tue, Nov 20, 2012 at 12:09 PM, Kevin T kevini...@gmail.com 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
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
On 20/11/2012 4:00 PM, Chris Angelico wrote: On Wed, Nov 21, 2012 at 1:57 AM, wxjmfa...@gmail.com 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 solin.pa...@gmail.com 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!
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
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 richard_hubb...@lavabit.com wrote: On Tue, 20 Nov 2012 20:41:42 +0300 Andriy Kornatskyy andriy.kornats...@live.com 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 andriy.kornats...@live.com 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 pyt...@mrabarnett.plus.com 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, hfo...@gmail.com 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 richard_hubb...@lavabit.com wrote: On Wed, 21 Nov 2012 10:12:26 -0800 Chris Rebert c...@rebertia.com wrote: On Wed, Nov 21, 2012 at 9:49 AM, rh richard_hubb...@lavabit.com wrote: On Tue, 20 Nov 2012 20:41:42 +0300 Andriy Kornatskyy andriy.kornats...@live.com wrote: snip 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
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
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
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 mining.fa...@gmail.com 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
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
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
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
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
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
cerr ron.egg...@gmail.com 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
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
snipping occurs
On 21 November 2012 20:58, MRAB pyt...@mrabarnett.plus.com 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
On Wed, Nov 21, 2012 at 6:01 AM, Tim Golden m...@timgolden.me.uk 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
On Wed, Nov 21, 2012 at 10:43 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
On Thu, Nov 22, 2012 at 4:03 AM, Colin J. Williams c...@ncf.ca 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!
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: snip 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
On Wed, Nov 21, 2012 at 3:58 PM, Dave Angel d...@davea.name 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
On 21 November 2012 22:17, Chris Angelico ros...@gmail.com wrote:
On Thu, Nov 22, 2012 at 4:03 AM, Colin J. Williams c...@ncf.ca 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)
OR
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)ss 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
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
On 21/11/2012 23:21, Joshua Landau wrote:
On 21 November 2012 22:17, Chris Angelico ros...@gmail.com wrote:
On Thu, Nov 22, 2012 at 4:03 AM, Colin J. Williams c...@ncf.ca 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)
OR
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)ss 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
On Wed, Nov 21, 2012 at 4:21 PM, Joshua Landau
joshua.landau...@gmail.com 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
On Wed, Nov 21, 2012 at 12:18 PM, Dan Stromberg drsali...@gmail.com 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
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 alec.tayl...@gmail.com 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
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
On 2012-11-22 03:41, Terry Reedy wrote:
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:] == ''
It can't return 5 because 5 isn't an index in 'spam'.
It can't return 4 because 4 is below the start index.
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.
It's a special case, but the Zen has something to say about that! :-)
(The empty string is also the only substring which can start at len(S).)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On 11/21/2012 6:21 PM, Joshua Landau wrote:
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'
You forgot the cases where % formatting has to be special cased.
The answer is {}..format(1)
'The answer is 1.'
The answer is {}..format((1,))
'The answer is (1,).'
The answer is %s % 1
'The answer is 1'
The anwser is %s % (1,)
'The answer is 1'
The answer is %s % ((1,),)
'The answer is (1,)'
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: re.search when used within an if/else fails
On Thu, Nov 22, 2012 at 3:41 AM, Kevin T kevini...@gmail.com wrote: 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. This is why the Short, Self-Contained, Correct Example is so important. See http://sscce.org/ for some info on that. I often find myself stuck, begin typing up a post to some appropriate mailing list, and while coalescing the problem into its smallest possible form, end up finding the cause directly. More often than not, I end up discarding the message unsent (though sometimes, I end up submitting a patch to the language/library maintainers, eg improving the docs so it's more visible next time). In any case, if you can copy and paste the exact code and error, it's a lot easier for us to replicate your problem. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Web Frameworks Excessive Complexity
On Wed, Nov 21, 2012 at 10:43 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
Oh, I'm *so* glad I work in a small company.
Agreed. Do we rate a contractor's quality of workmanship and efficiency by the
number of nails he drives?
Of course not. That would be ridiculous.
A better metric of code quality and complexity would be to borrow from science
and mathematics. i.e. a peer review or audit by others working on the project
or in the same field of study. Unfortunately this isn't cheap or easily
computed and doesn't translate nicely to a bar graph.
Such is reality.
-Modulok-
--
http://mail.python.org/mailman/listinfo/python-list
Re: Suitable software stacks for simple python web service
Kev Dwyer kevin.p.dw...@gmail.com writes: 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)? From your description (so far), you would not need a web framework but could use any way to integrate Python scripts into a web server, e.g. mod_python, cgi, WSGI, Check what ways your web server will suport. -- http://mail.python.org/mailman/listinfo/python-list
Re: Suitable software stacks for simple python web service
Steve Petrie wrote: 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. Hello Steve, Thanks for your comment. I'm curious, did you consider any web servers other than Apache? Kev -- http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistent behaviour os str.find/str.index when providing optional parameters
Il giorno giovedì 22 novembre 2012 05:00:39 UTC+1, MRAB ha scritto:
On 2012-11-22 03:41, Terry Reedy wrote:
It can't return 5 because 5 isn't an index in 'spam'.
It can't return 4 because 4 is below the start index.
Uhm. Maybe you are right, because returning a greater value would cause an
IndexError, but then, *why* is 4 returned???
'spam'.find('', 4)
4
'spam'[4]
Traceback (most recent call last):
File stdin, line 1, in module
IndexError: string index out of range
4 is not a valid index either. I do not think the behaviour was completely
intentional. If find should return indexes than 'spam'.find('', 4) must be -1,
because 4 is not a valid index. If find should behave as if creating the slice
and checking if the substring is in the slice than 'spam'.find('', i) should
return i for every integer = 4.
The docstring does not describe this edge case, so I think it could be improved.
If the first sentence(being an index in S) is kept, than it shouldn't say that
start and end are treated as in slice notation, because that's actually not
true. It should be added if start is greater or equal to len(S) then -1 is
always returned(and in this case 'spam'.find('', 4) - -1).
If find should not guarantee that the value returned is a valid index(when
start isn't a valid index), then the first sentence should be rephrased to
avoid giving this idea(and the comparisons in stringlib/find.h should be
swapped to have the correct behaviour).
For example, maybe, it could be Return the lowest index where substring sub is
found (in S?), such that sub is contained in S[start:end]. ...
--
http://mail.python.org/mailman/listinfo/python-list
[issue16515] TypeError message incorrect for max() with one keyword arg
Mark Dickinson added the comment: It would be nice to change 'arguments' to 'argument' in this case, too. :-) -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16512] imghdr doesn't support jpegs with an ICC profile
Joril added the comment: It looks like the test just walks a directory recursively while trying to identify its files, there's no classic test of the this is a JPEG, is it detected correctly-type -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16512 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16480] pyvenv 3.3 fails to create symlinks for virtualenv/local/{bin, lib} to virtualenv/{bin, lib}
Marco Amadori added the comment:
2012/11/21 Carl Meyer rep...@bugs.python.org
Carl Meyer added the comment:
Here is the bug filed against virtualenv that led to the addition of the
local/ directory: https://github.com/pypa/virtualenv/issues/118
As Vinay pointed out, the original fix was later modified to be friendlier
to tools that dislike recursive symlinks.
I didn't used virtualenv but pyvenv-3.3, so if this is not a bug, my
question become:
how to proper install distribute and pip in python 3.3 venv since they
installs in VENV/local/bin and that VENV/bin/activate does not
include VENV/local/bin in $PATH ?
--
title: pyvenv 3.3 fails to create symlinks for virtualenv/local/{bin,lib} to
virtualenv/{bin,lib} - pyvenv 3.3 fails to create symlinks for
virtualenv/local/{bin, lib} to virtualenv/{bin, lib}
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16480
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16520] subprocess.Popen() TypeError message incorrect without args argument
New submission from Chris Jerdonek: The TypeError message when a call to subprocess.Popen() lacks the args argument is incorrect. For 3.3 and 3.4, the message incorrectly says that a positional argument is required when a keyword argument will do: import subprocess subprocess.Popen() Traceback (most recent call last): File stdin, line 1, in module TypeError: __init__() missing 1 required positional argument: 'args' subprocess.Popen(args=['test']) subprocess.Popen object at 0x10bed4840 For 3.2 and 2.7, the problem is slightly different. It says that two arguments are needed and that two have been given: subprocess.Popen() Traceback (most recent call last): File stdin, line 1, in module TypeError: __init__() takes at least 2 arguments (1 given) subprocess.Popen(shell=True) Traceback (most recent call last): File stdin, line 1, in module TypeError: __init__() takes at least 2 arguments (2 given) I don't know if this issue affects other functions in the standard library, but I suspect it might. -- components: Library (Lib) messages: 176047 nosy: chris.jerdonek priority: normal severity: normal status: open title: subprocess.Popen() TypeError message incorrect without args argument type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16520 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16520] subprocess.Popen() TypeError message incorrect without args argument
Mark Dickinson added the comment: I don't think the first part of the report has anything to do with subprocess.Popen: def f(x): ... return ... f() Traceback (most recent call last): File stdin, line 1, in module TypeError: f() missing 1 required positional argument: 'x' See the related discussion starting at: http://mail.python.org/pipermail/python-dev/2012-September/121760.html -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16520 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16520] subprocess.Popen() TypeError message incorrect without args argument
Chris Jerdonek added the comment: Also see the terminology-related issue 15990 created from that thread. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16520 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16511] IDLE configuration file: blank height and width fields trip up IDLE
Trung Doan added the comment: Suggestion: When Python is installed, it starts its configurations files afresh. Trung Doan === On Wed, Nov 21, 2012 at 8:54 AM, Serhiy Storchaka rep...@bugs.python.orgwrote: Serhiy Storchaka added the comment: Patch updated. Added warning for case when user config broken. Thanks Roger for suggestion. -- Added file: http://bugs.python.org/file28058/idle_safe_getoption_3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16511 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16517] address merge conflicts in devguide null-merge instructions
Ezio Melotti added the comment: + hg resolve -am # needed only if the merge created conflicts IIUC it's necessary, but only if you had a conflict and hg didn't invoke a 3-way merge tool. Here I use kdiff3, and I rarely have to use hg resolve. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16517 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16521] logging.basicConfig creates empty file when using handlers
New submission from Jovik: Using logging.basicConfig() with Python 3.2.3 accepts handlers options without any errors. It creates an empty file. I don't think this should be default behaviour, sice it's very missleading (no exception thrown; no warning on standard output or in the file) -- components: Library (Lib) files: logginghandler.py messages: 176052 nosy: Jovik priority: normal severity: normal status: open title: logging.basicConfig creates empty file when using handlers type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file28060/logginghandler.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16521 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16517] address merge conflicts in devguide null-merge instructions
R. David Murray added the comment: Yes, so I suppose you could add a footnote that says using a three way merge tool generally makes this step unnecessary. Is there a bug report for this on the mercurial tracker? If so we could link to the bug report :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16517 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16517] address merge conflicts in devguide null-merge instructions
Chris Jerdonek added the comment: Is there a bug report for this on the mercurial tracker? Indeed there is -- by one of our own in fact :) http://bz.selenic.com/show_bug.cgi?id=2706 -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16517 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15990] solidify argument/parameter terminology
Chris Jerdonek added the comment: Here is a proposed patch just to get the ball rolling on this. Note that I'm proposing that we let ourselves use the word standard in place of positional-or-keyword when talking about parameters. This is partly inspired by PEP 362, which says, Parameter.POSITIONAL_OR_KEYWORD ... this is the standard binding behaviour for functions implemented in Python. This patch only takes an initial crack at the glossary entries. Once these are fleshed out, we can add additional :term: links and index directives. -- keywords: +patch stage: - patch review versions: +Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28061/issue-15990-1-default.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15990 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16517] address merge conflicts in devguide null-merge instructions
Chris Jerdonek added the comment: Attaching new patch incorporating David's suggestions. -- Added file: http://bugs.python.org/file28062/issue-16517-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16517 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16475] Support object instancing and recursion in marshal
Kristján Valur Jónsson added the comment: Code objects can indeed be shared. One thing that the recode module does, or allows you to do, is to strip file and line number information from code objects. This will theoretically allow them to be collapsed. Martin, I agree the .pyc size matters. You are right, priorities vary. I am mainly focused on memory use, while others may be looking at disk use. Disk use can of course be reduced by using tools like zip. And code objects can be re-optimized at load time too using special importers. But it is nice to be able to achieve both objectives by enabling the marshal format to preserve those optimizations that are performed on it prior to saving it. I'm currently working on the recode module. When its done, I'll report back and share it with you so that you can toy around with it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16475 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13538] Improve doc for str(bytesobject)
Roundup Robot added the comment: New changeset 5c39e3906ce9 by Chris Jerdonek in branch '3.2': Fix label in docs (from issue #13538). http://hg.python.org/cpython/rev/5c39e3906ce9 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16522] Add 'FAIL_FAST' flag to doctest
New submission from R. David Murray: When debugging using tests or doing test driven development, I find it very useful to have the test run exit immediately on the first failure. Doctest currently has a feature to suppress all output after the first failure, but not to exit on the first failure. Exiting on the first failure in doctest is even more important than in unit test for me, since a typical way to debug using doctest is to add prints to sys.stderr to the code. If the doctest run continues, other tests that follow the same code path may also dump debugging output, making it harder to find the output related specifically to the test failure. The attached patch does the easy part: adds a FAIL_FAST flag. I don't have time right at the moment to finish the patch with docs and tests. If someone wants to work on this before I get back to it they should feel free (just post a note here that you are working on it). -- assignee: r.david.murray files: doctest_fail_fast.patch keywords: easy, patch messages: 176059 nosy: r.david.murray priority: normal severity: normal stage: needs patch status: open title: Add 'FAIL_FAST' flag to doctest type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file28063/doctest_fail_fast.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16522 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16523] attrgetter and itemgetter signatures in docs need cleanup
New submission from R. David Murray: It looks like the use of the 'args' formal parameter was cut and pasted from the methodcaller docs, when it is not appropriate for itemgetter and attrgetter. http://docs.python.org/3/library/operator.html#operator.attrgetter -- assignee: docs@python components: Documentation messages: 176060 nosy: docs@python, r.david.murray priority: normal severity: normal stage: needs patch status: open title: attrgetter and itemgetter signatures in docs need cleanup type: behavior versions: Python 2.7, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16523 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15990] solidify argument/parameter terminology
Ezio Melotti added the comment: On one hand it's good to have individual entries that can be referenced. On the other hand I think it's important that people get the full picture, and having these definitions sparse in 4 or more distinct glossary entries doesn't help IMHO -- even if the reader follows all the cross-links. I think it would be better to have a single entry somewhere (e.g. in the FAQs -- maybe it's too advanced for the tutorial), that: * explains the difference between arguments (what you pass) and parameters (what the function accepts); * lists the 5 kinds of parameters, providing an example for each; * lists the 2 kinds of arguments, providing an example for each; I see 3 options here: 1) we make this section and keep stub entries that link to it; 2) we repeat the informations in both places (section and entries); 3) we just keep the glossary entries; If we pick 1 people might have to follow one more link. Having a single parameters and arguments entry in the glossary might make this better by avoiding a redirect. If we pick 2 there's duplication, and that's bad. If we pick 3 I think we could at least explain the kinds of arguments in the argument entry and having stubs for keyword args and positional args. This will leave us with only two entries (argument and parameter), and with the initial problem that we don't know where to put the explanation of the difference between the two (in both? in a new entry? somewhere else? no parallel?). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15990 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16523] attrgetter and itemgetter signatures in docs need cleanup
Changes by Éric Araujo mer...@netwok.org: -- keywords: +easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16523 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16515] TypeError message incorrect for max() with one keyword arg
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch
Almar Klein added the comment:
Just checking in to point out a possible problem with the code that strips the
MSVCR dependency from the embedded manifest. The used regexpr is too greedy:
the first bit can trigger on an earlier assemblyIdentity tag, so that after
the removal the manifest is no longer valid XML.
The key problem is that the assemblyIdentity and the name attribute are
allowed to be on a separate lines. To fix this I removed the re.DOTALL flag and
replaced the second occurrence of .*? to also allow newlines:
pattern = re.compile(
- rassemblyIdentity.*?name=(|')Microsoft\.\
- rVC\d{2}\.CRT(|').*?(/|/assemblyIdentity),
- re.DOTALL)
+ rassemblyIdentity.*?name=(|')Microsoft\.\
+ rVC\d{2}\.CRT(|')(.|\r|\r)*?(/|/assemblyIdentity))
It is well possible that the problem does not causes any problems for the
intended usage of the code. I'm using the code to strip other DLL's and ran
into this issue (with tk85.dll to be precise).
- Almar
--
nosy: +almar
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7833
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
