Re: unsupported operand type(s) for pow(): 'unicode', 'long', 'long': Pycrypto
On Sat, Oct 8, 2011 at 12:50 AM, Terry Reedy tjre...@udel.edu wrote: That latter function probably want integers code in range(256). Yes! Non-unicode. The source reads: def _encrypt(self, m): # compute m**d (mod n) return pow(m, self.e, self.n) From the source, it is provided as is. The arguments must have numeric types How come it accepts str type? -- Odeyemi 'Kayode O. http://www.sinati.com. t: @charyorde -- http://mail.python.org/mailman/listinfo/python-list
Re: unsupported operand type(s) for pow(): 'unicode', 'long', 'long': Pycrypto
Kayode Odeyemi wrote: On Sat, Oct 8, 2011 at 12:50 AM, Terry Reedy tjre...@udel.edu wrote: That latter function probably want integers code in range(256). Yes! Non-unicode. The source reads: def _encrypt(self, m): # compute m**d (mod n) return pow(m, self.e, self.n) From the source, it is provided as is. The arguments must have numeric types How come it accepts str type? pow() does not accept a str. Most likely there is conversion code similar to if isinstance(m, str): m = convert_to_int(m) that precedes the _encrypt() method call and lets unicode slip through. Grepping through the PyCrypto source for isinstance indeed finds a few candidates. Example: $ find . -name \*.py | xargs grep isinstance -A5 [...] ./PublicKey/pubkey.py:if isinstance(plaintext, types.StringType): ./PublicKey/pubkey.py-plaintext=bytes_to_long(plaintext) ; wasString=1 ./PublicKey/pubkey.py:if isinstance(K, types.StringType): ./PublicKey/pubkey.py-K=bytes_to_long(K) ./PublicKey/pubkey.py-ciphertext=self._encrypt(plaintext, K) ./PublicKey/pubkey.py-if wasString: return tuple(map(long_to_bytes, ciphertext)) ./PublicKey/pubkey.py-else: return ciphertext ./PublicKey/pubkey.py- [...] -- http://mail.python.org/mailman/listinfo/python-list
Re: unsupported operand type(s) for pow(): 'unicode', 'long', 'long': Pycrypto
On Sat, Oct 8, 2011 at 10:37 AM, Peter Otten __pete...@web.de wrote: Kayode Odeyemi wrote: On Sat, Oct 8, 2011 at 12:50 AM, Terry Reedy tjre...@udel.edu wrote: That latter function probably want integers code in range(256). Yes! Non-unicode. The source reads: def _encrypt(self, m): # compute m**d (mod n) return pow(m, self.e, self.n) From the source, it is provided as is. The arguments must have numeric types How come it accepts str type? pow() does not accept a str. Most likely there is conversion code similar to if isinstance(m, str): m = convert_to_int(m) Ah! I see the reason for the unsupported operand type error. It wants a str, so it can do a conversion to int. But since unicode, long etc is not allowed, shouldn't that been taken care of in _encrypt? Or is this by design? that precedes the _encrypt() method call and lets unicode slip through. Grepping through the PyCrypto source for isinstance indeed finds a few candidates. Example: $ find . -name \*.py | xargs grep isinstance -A5 [...] ./PublicKey/pubkey.py:if isinstance(plaintext, types.StringType): ./PublicKey/pubkey.py-plaintext=bytes_to_long(plaintext) ; wasString=1 ./PublicKey/pubkey.py:if isinstance(K, types.StringType): ./PublicKey/pubkey.py-K=bytes_to_long(K) ./PublicKey/pubkey.py-ciphertext=self._encrypt(plaintext, K) ./PublicKey/pubkey.py-if wasString: return tuple(map(long_to_bytes, ciphertext)) ./PublicKey/pubkey.py-else: return ciphertext ./PublicKey/pubkey.py- [...] Thanks. This make things clearer -- http://mail.python.org/mailman/listinfo/python-list -- Odeyemi 'Kayode O. http://www.sinati.com. t: @charyorde -- http://mail.python.org/mailman/listinfo/python-list
Re: Thread handling issue
Basically there can be quite a big job to do based on the user selection and I've pipelined it so after the user selects the output location the next job can get started so long as the first job (preparing the data) has been running for 5 or so seconds roughly. Its just a lot nicer to have this done by the time the user has selected an output folder so the main job can start instantly. Of course the user can kill the main job too and go back to the user input so I need to be able to kill the threads anyway. -- http://mail.python.org/mailman/listinfo/python-list
Usefulness of the not in operator
Python provides
-- the not operator, meaning logical negation
-- the in operator, meaning membership
On the other hand, Python provides the not in operator meaning
non-membership. However, it seems we can reformulate any not in
expression using only not and in operation. For instance
'th' not in python
False
not ('th' in python)
False
So what is the usefulness of the not in operator ? Recall what Zen of
Python tells
There should be one-- and preferably only one --obvious way to do it.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Thread handling issue
Tim Golden mail at timgolden.me.uk writes: On 07/10/2011 11:15, Paul wrote: My first thought was to use a flag but wouldn't the new thread see the cancel flag and stop as well? I could set it back but then any other threads might have been busy and not seen it while the flag was on. The thread goes through the selection and does a few quick server calls for each one building up a data file. I guess as the server calls are quite fast the thread would be able to check flags quite often unless it's getting time- outs or something. The threads don't pass anything back they're passed a reference to a data object which is constructed before the thread starts. The thread makes updates to the data object and sets a complete attribute flag in the object before finishing. Well a lot depends on how you're doing things. (ie It Depends). You could generate an event for each thread so a second thread started while the first was running down wouldn't cause confusion. It's not clear whether the data object is common to all threads -- in which case you need to make sure you're locking etc. -- or is a new instance for each thread. I did try a couple of passes at a code-sketch, but there are too many unknowns to do justice to it. Basically, have the thread poll an event as it moves through. Have the UI set the event and join to the existing thread (ie wait for it to finish) and then fire off a new one. Or -- if the data items are independent -- fire off the new one regardless and let the old one die when it sees its event, assuming that the data object it's populating is disposable. TJG Yea currently I create a new data object for each thread. I could make it a bit smarter and if the user goes back makes a change I could re-use the old data object and modify it but currently I'm not going to worry about that. I think I'll wait for the user to actually make a change after cancelling the output selection, in case they go straight back without making changes. If they make a change I think I'll try what you suggested and send off a new thread, and send an event to the previous thread. Would this mean I'd need to use wx.lib.newevent.NewCommandEvent() to get a new event for each thread I create? and I'd have to pass the second return value from that, the event binder to the thread to bind to a clean up and exit method? -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
On Oct 8, 11:42 am, candide cand...@free.invalid wrote:
Python provides
-- the not operator, meaning logical negation
-- the in operator, meaning membership
On the other hand, Python provides the not in operator meaning
non-membership. However, it seems we can reformulate any not in
expression using only not and in operation. For instance
'th' not in python
False
not ('th' in python)
False
So what is the usefulness of the not in operator ? Recall what Zen of
Python tells
There should be one-- and preferably only one --obvious way to do it.
You would seriously prefer the later?
Guess I'll have to start writing stuff like:
10 - 5 as 10 + -5 (as obviously the - is redundant as an operation),
and 10 / 2 as int(10 * .5) or something, who needs a divide!?
Jokely yours,
Jon.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
So what is the usefulness of the not in operator ? Recall what Zen of Python tells There should be one-- and preferably only one --obvious way to do it. the zen of python also says (amongst other things): ... Readability counts. ... Although practicality beats purity ... Best regards, Stefaan. -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
candide wrote: So what is the usefulness of the not in operator ? Recall what Zen of Python tells There should be one-- and preferably only one --obvious way to do it. And not in is the obvious way to do it. If the key is not in the ignition, you won't be able to start the car. If not the key is in the ignition, you won't be able to start the car. Who like that second one speaks? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
PDB command - variable clashes
I am currently debugging the django test cases, and there are a lot of variables names like w, q, where, condition and so on. Especially variables like w, q, c, r are really annoying. It would be cool if pdb would detect a clash and in that case ask you what to do. Nothing more annoying than stepping through the code, finally finding the problematic place and then trying to find out what c.somevar contains... I am using Python 2.6. Is there some way to do this? My googling didn't turn out anything. Or is it recommended to use something else instead of pdb? Thank you for your time, - Anssi Kääriäinen -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
candide candide@free.invalid writes: Python provides -- the not operator, meaning logical negation -- the in operator, meaning membership On the other hand, Python provides the not in operator meaning non-membership. However, it seems we can reformulate any not in expression using only not and in operation. Sure, but note that you can also reformulate != using not and ==, using not and =, etc. Operators like not in and is not should really be considered single tokens, even though they seem to use not. And I think they are really convenient. -- Alain. -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
Steven D'Aprano wrote: candide wrote: So what is the usefulness of the not in operator ? Recall what Zen of Python tells There should be one-- and preferably only one --obvious way to do it. And not in is the obvious way to do it. If the key is not in the ignition, you won't be able to start the car. If not the key is in the ignition, you won't be able to start the car. Who like that second one speaks? :) If the key is not in the ignition, you will be able to start the car, not. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
Mel writes: Steven D'Aprano wrote: candide wrote: So what is the usefulness of the not in operator ? Recall what Zen of Python tells There should be one-- and preferably only one --obvious way to do it. And not in is the obvious way to do it. If the key is not in the ignition, you won't be able to start the car. If not the key is in the ignition, you won't be able to start the car. Who like that second one speaks? :) If the key is not in the ignition, you will be able to start the car, not. Oh, be consistent. If not the key is in the ignition, not you will be able to start the car. But both negations can be avoided by modus tollens. If you are able to start the car, the key is in the ignition. And one could express x not in s as (x in s) implies False without making the not explicit if implies was in the language. (I know about = but I also witnessed an unpleasant thread in another newsgroup where people insisted that = should not be defined for truth values at all, and I also happen to like Python's not in.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
In article 87ehyn8xlp@dpt-info.u-strasbg.fr, Alain Ketterlin al...@dpt-info.u-strasbg.fr wrote: Sure, but note that you can also reformulate != using not and ==, using not and =, etc. Operators like not in and is not should really be considered single tokens, even though they seem to use not. And I think they are really convenient. If you want to take it one step further, all the boolean operators can be derived from nand (the dualists would insist on using nor). -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
Le 08/10/2011 14:41, Alain Ketterlin a écrit : Operators like not in and is not should really be considered single tokens, even though they seem to use not. And I think they are really convenient. I realize that I was confused by the lexical form of the not in operator : it is made by juxtaposing two other operators. Operators composed from two other operators exist, for instance != but the two cannot be separated, for instance 2 ! = 3 is not a valid expression. Said in another way, in Python syntax, usually a lexically juxtaposed operator is seen as a whole. This is not the case for an operator such as is not or not in because for example 2 is not 3 is a valid statement. A notin operator or isnot operator would be less confusing (at least in my case ;) ). -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
Le 08/10/2011 14:01, Steven D'Aprano a écrit :
And not in is the obvious way to do it.
Obvious ? Not so. I performed some code mining and it appears that even
good sources make use of not (foo in bar) expressions.
begin examples ***
from drpython/drPluginDialog.py
-
if not (plugin in self.parent.pluginstoremove):
from numpy/f2py/crackfortran.py
---
if not (l[0] in spacedigits):
from crunchy1.0alpha1/crunchy/src/plugins/vlam_editor.py
--
if ((no_copy in vlam) and not (no_pre in vlam)) or (not python_code):
from Cpython/Python-3.1a1/Lib/logging/__init__.py
--
if not (hdlr in self.handlers):
from Cpython/Python-2.6.2/Lib/idlelib/configHandler.py
---
if not (configType in ('main','extensions','highlight','keys')):
raise InvalidConfigType, 'Invalid configType specified'
from
pygtk-2.22.0/gtk/webkitgtk/WebKit-r93015/Source/JavaScriptCore/KeywordLookupGenerator.py
-
if not (key[0] in self.keys):
from pypy/pypy-pypy-release-1.6/lib-python/2.7/logging/__init__.py
--
if not (hdlr in self.handlers):
end examples ***
_Many_ more examples of this type are avalaible.
The obviousness of an is not operator is very debatable. Do you have
standard functions or method such as
isnotinstance, isnotsubset, isnotdir, isnotfile, isnotalpha, etc ?
In my case, It took a long time to realize the existence of a true
not in operator as I explain in my response to Alain.
Imagine, /Dive Into Python/ book doesn't describe this operator per se
and provides only one source file using it. Official Python tutorial at
python.org didn't provide even one.
If the key is not in the ignition, you won't be able to start the car.
If not the key is in the ignition, you won't be able to start the car.
Who like that second one speaks?
Depends if you are aware of negative form conjugation.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
Le 08/10/2011 12:42, candide a écrit :
not ('th' in python)
False
After browsing source code, I realize that parenthesis are not necessary
(not has higher precedence than in).
--
http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
On Sun, Oct 9, 2011 at 1:40 AM, candide candide@free.invalid wrote: A notin operator or isnot operator would be less confusing (at least in my case ;) ). Let's replace both of them. in -- foo extant bar not in -- foo extinct bar That would solve the problem, wouldn't it? *ducking for cover* ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
Le 08/10/2011 12:50, Jon Clements a écrit : 10 - 5 as 10 + -5 (as obviously the - is redundant as an operation), and 10 / 2 as int(10 * .5) or something, who needs a divide!? OK, I see your point but I was supposing non-membershipness seldom needed and in fact one can suppose that test membership is heavily more used than test non-membership. In fact, it seems that most Python operators have an antonym operator, for instance : == vs != vs = is vs is not + vs - etc -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
* candide (Sat, 08 Oct 2011 16:41:11 +0200) After browsing source code, I realize that parenthesis are not necessary (not has higher precedence than in). Lower precedence. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
On 01/-10/-28163 02:59 PM, candide wrote:
Le 08/10/2011 12:42, candide a écrit :
not ('th' in python)
False
After browsing source code, I realize that parenthesis are not
necessary (not has higher precedence than in).
You should say
... parenthesis are not necessary (not has LOWER precedence than
in).
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
Le 08/10/2011 17:13, Thorsten Kampe a écrit : * candide (Sat, 08 Oct 2011 16:41:11 +0200) After browsing source code, I realize that parenthesis are not necessary (not has higher precedence than in). Lower precedence. Ooops, thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
On Sun, Oct 9, 2011 at 2:16 AM, Dave Angel d...@davea.name wrote: You should say ... parenthesis are not necessary (not has LOWER precedence than in). Is are not an operator in English, or should this be not parentheses are necessary? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
On 2011-10-08, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: candide wrote: So what is the usefulness of the not in operator ? Recall what Zen of Python tells There should be one-- and preferably only one --obvious way to do it. And not in is the obvious way to do it. If the key is not in the ignition, you won't be able to start the car. If not the key is in the ignition, you won't be able to start the car. Who like that second one speaks? Yoda. -- Grant Edwards grant.b.edwardsYow! ... I don't like FRANK at SINATRA or his CHILDREN. gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: encoding problem with BeautifulSoup - problem when writing parsed text to file
On Wed, 05 Oct 2011 21:39:17 -0700, Greg wrote: Here is the final code for those who are struggling with similar problems: ## open and decode file # In this case, the encoding comes from the charset argument in a meta tag # e.g. meta charset=iso-8859-2 fileObj = open(filePath,r).read() fileContent = fileObj.decode(iso-8859-2) fileSoup = BeautifulSoup(fileContent) The fileObj.decode() step should be unnecessary, and is usually undesirable; Beautiful Soup should be doing the decoding itself. If you actually know the encoding (e.g. from a Content-Type header), you can specify it via the fromEncoding parameter to the BeautifulSoup constructor, e.g.: fileSoup = BeautifulSoup(fileObj.read(), fromEncoding=iso-8859-2) If you don't specify the encoding, it will be deduced from a meta tag if one is present, or a Unicode BOM, or using the chardet library if available, or using built-in heuristics, before finally falling back to Windows-1252 (which seems to be the preferred encoding of people who don't understand what an encoding is or why it needs to be specified). -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
Roy Smith wrote: If you want to take it one step further, all the boolean operators can be derived from nand (the dualists would insist on using nor). Let's define the boolean values and operators using just two functions: def true(x, y): return x def false(x, y): return y That's all we need to define all of Boolean algebra. Unfortunately, it's a bit ugly in Python: true function true at 0xb7c3a36c So let's add a helper function to prettify the output: def pr(b): print(b(true, false).__name__) pr(true) true Much nicer! Now define NAND: def Nand(a, b): return (lambda c: lambda x, y: c(y, x))(a(b, a)) and we're done. All of boolean algebra can now be derived from Nand. def Not(b): ... return Nand(b, b) ... pr(Not(true)) false pr(Not(false)) true def And(a, b): ... return Nand(Nand(a, b), Nand(a, b)) ... pr(And(true, false)) false pr(And(true, true)) true def Or(a, b): ... return Nand(Nand(a, a), Nand(b, b)) ... pr(Or(true, false)) true pr(Or(false, false)) false def Xor(a, b): ... return And(Nand(a, b), Or(a, b)) ... pr(Xor(true, false)) true pr(Xor(true, true)) false and so forth. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
Le 08/10/2011 17:16, Dave Angel a écrit : You should say ... parenthesis are not necessary (not has LOWER precedence than in). I should, yes, I confess ;) In my defense, I must tell that Python document reference here : http://docs.python.org/reference/expressions.html#summary has an anti-iconic way to display the order precedence. If an operator OP1 has higher precedence than an operator OP2 , it means that, at evaluation time, you execute OP1 FIRST and operator OP2 later. So, its seems very natural to present FIRST operator with stronger precedence. So, if you iconically present this material in a tabular display, you present FIRST (ie at the top because usually we process tabular material starting on the upper part) what you need to calculate FIRST and, again, you present at the TOP the HIGHer precedence and at the BOTTOM the LOWer precedence. Documentations usually provide the table in this order (higher to lower), cf. the table in KR book for C programing language or here for the C++ PL : http://en.cppreference.com/w/cpp/language/operator_precedence or again there for the Java PL : http://download.oracle.com/javase/tutorial/java/nutsandbolts/operators.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
candide wrote: Le 08/10/2011 14:01, Steven D'Aprano a écrit : And not in is the obvious way to do it. Obvious ? Not so. I performed some code mining and it appears that even good sources make use of not (foo in bar) expressions. All that proves is that even expert Python developers can, on occasion, write non-idiomatic Python -- or that they accept code contributed by non-expert Python developers, and don't bother adjusting trivial stylistic flaws. When I learned Pascal 20+ years ago, it took me a long time to stop writing x not in y and learn the non-English-like not x in y. Then I learned Python, and it took me a while to stop writing Pascal code in Python. Bad habits take a while to disappear. (I never added superfluous semi-colons after each line though!) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: help
On Oct 8, 2:51 pm, X1 x...@x1.x1.x1.net wrote: easy_install does not exist on Fedora. http://lmgtfy.com/?q=easy_install+fedora -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
In article 4e906108$0$27980$426a3...@news.free.fr, candide candide@free.invalid wrote: After browsing source code, I realize that parenthesis are not necessary (not has higher precedence than in). Here's my take on parenthesis: If you need to look up whether they're necessary or not, they are :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
On Oct 8, 6:31 pm, Roy Smith r...@panix.com wrote: In article 87ehyn8xlp@dpt-info.u-strasbg.fr, Alain Ketterlin al...@dpt-info.u-strasbg.fr wrote: Sure, but note that you can also reformulate != using not and ==, using not and =, etc. Operators like not in and is not should really be considered single tokens, even though they seem to use not. And I think they are really convenient. If you want to take it one step further, all the boolean operators can be derived from nand (the dualists would insist on using nor). -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
On Sun, Oct 9, 2011 at 3:31 AM, rusi rustompm...@gmail.com wrote: If you want to take it one step further, all the boolean operators can be derived from nand (the dualists would insist on using nor). I'm not sure what you're questioning, but it's possible to derive all boolean operators from either nand or nor. Most hardware these days is built out of silicon NAND gates, but there's no reason not to do it as NOR gates. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
In article acd018ad-8428-4c3d-8aa0-15c4a410f...@x31g2000prd.googlegroups.com, rusi rustompm...@gmail.com wrote: On Oct 8, 6:31 pm, Roy Smith r...@panix.com wrote: In article 87ehyn8xlp@dpt-info.u-strasbg.fr, Alain Ketterlin al...@dpt-info.u-strasbg.fr wrote: Sure, but note that you can also reformulate != using not and ==, using not and =, etc. Operators like not in and is not should really be considered single tokens, even though they seem to use not. And I think they are really convenient. If you want to take it one step further, all the boolean operators can be derived from nand (the dualists would insist on using nor). Dualist (noun): a made up word referring to wrong-thinking people who have rejected the teachings of the Prophet Nand and believe the nor is the One True Operation on which all over operations can be constructed. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On the subject of the gui discussion mentioned here last year, which you get lead to if you read around in the pyjamas docs, I have to admit, since I know both development types (gwt, wx, qt) and (django, jquery), I have to state the fact, that pyjamas should also consider bonding with native javascript library developments. Excuse me if I accidentaly go a bit off track, but I guessed, I might bring in my thoughts (but I hope, not to get emotional responses which made this thread a bit hard to follow in the end) The interchange between fixed sized GUI applications and browsing technology as a whole could for example get very interesting for django development, if javascript operated functions would be taken over by native python. I was just looking at pyquery, a python implementation of jquery, which could easily backbone jquery itself on the python end. Now this is not pyjamas' task, but the pyjs compiler could be used, so that jquery code could be written for both languages. Since jquery DOM interfacing is way easier, and hot fixes can be made by javascript development teams, GUI elements of jquery libraries could be integrated into the application. While the functionality of the UI therefore still is GUI based in terms of fixed applications, like pyjamas desktop, concurrent efforts could take place from the so called web-development gui layouts. On that front, a lot of talented coders exist in younger generations, which would have the ability to develop the web frontend in closer relation to the web-designers, mainting the key issues for the world-wide-web: design, speed and small loading time. Long story short: if you could write jquery in python which actually compiles into jquery in javascript, and even runs on python itself, you could deploy widgets natively from python in django, and dont have to leave python to improve webapplications with its native strengths. You can free yourself up pretty soon from having too much problems with ui. the designer can do that. You focus on datasets, server-client-api, or you can expose one of your pyjamas widgets as jquery plugin integrating validation of data server and clientside. You can still develop a control application or other integrated software parts natively with pyjamas desktop, knowing the web uses correct code. Of course that depends on how much overhead pyjamas libraries have if you only take a piece of it out, like a richtext element or a fully bloated editor, but even then, internally you load the app anyway up front, externally the user transitions from being a human guest to being a system user only in certain occasions. Any thoughts? -- http://mail.python.org/mailman/listinfo/python-list
Re: PDB command - variable clashes
On Oct 8, 1:18 pm, Kääriäinen Anssi anssi.kaariai...@thl.fi wrote:
I am currently debugging the django test cases, and there are a lot of
variables names like w, q, where, condition and so on. Especially variables
like w, q, c, r are really annoying. It would be cool if pdb would detect a
clash and in that case ask you what to do. Nothing more annoying than
stepping through the code, finally finding the problematic place and then
trying to find out what c.somevar contains... I am using Python 2.6.
Is there some way to do this? My googling didn't turn out anything. Or is it
recommended to use something else instead of pdb?
Thank you for your time,
- Anssi Kääriäinen
Its not perfect but I use in sitecustomize
def precmd(self,l):
if '.' in l:
if l[:1]!='!':l='!'+l
return l
if l in self.curframe.f_locals:
return '!'+l
if l.startswith('@'): return l[1:]
return l
import pdb
pdb.Pdb.precmd = precmd
What this does is
q -variable q if it exists else quit command
@q -always quit
!q -always variable
HTH
Jon
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to create C-style main function in Python? (for teaching purposes)
Dennis Lee Bieber wlfr...@ix.netcom.com wrote: While I wouldn't want to write an FFT in COBOL, one can't deny that laying out fixed width reports and moving blocks of decimal data between record layouts is quite easy in COBOL. Absolutely. I've always thought the Data Section in COBOL was conceptually ahead of its time. It makes you THINK about your data structures more than, say struct in C. -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
Roy Smith r...@panix.com wrote: In article 4e906108$0$27980$426a3...@news.free.fr, candide candide@free.invalid wrote: After browsing source code, I realize that parenthesis are not necessary (not has higher precedence than in). Here's my take on parenthesis: If you need to look up whether they're necessary or not, they are :-) Amen. +1 -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
On 09.10.2011 01:35, Tim Roberts wrote: Roy Smithr...@panix.com wrote: In article4e906108$0$27980$426a3...@news.free.fr, candidecandide@free.invalid wrote: After browsing source code, I realize that parenthesis are not necessary (not has higher precedence than in). Here's my take on parenthesis: If you need to look up whether they're necessary or not, they are :-) Amen. +1 So LISP (Lots of Irritating Superfluous Parentheses) was right all the time and is now finally vindicated? ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
I sent this email twelve hours ago but to the wrong mailing list *blush*. Since nobody else has raised the point, I'll repost it. On Sun, Oct 9, 2011 at 12:07 AM, Jussi Piitulainen jpiit...@ling.helsinki.fi wrote: But both negations can be avoided by modus tollens. If you are able to start the car, the key is in the ignition. But this translation implies looking at the result and ascertaining the state, which is less appropriate to a programming language. It's more like: If you found that you were able to start the car, the key must have been in the ignition. and is thus quite inappropriate to the imperative style. A functional language MAY be able to use this style, but Python wants to have the condition and then the action. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Usefulness of the not in operator
In article mailman.1841.1318123788.27778.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: I sent this email twelve hours ago but to the wrong mailing list *blush*. Since nobody else has raised the point, I'll repost it. On Sun, Oct 9, 2011 at 12:07 AM, Jussi Piitulainen jpiit...@ling.helsinki.fi wrote: But both negations can be avoided by modus tollens. If you are able to start the car, the key is in the ignition. But this translation implies looking at the result and ascertaining the state, which is less appropriate to a programming language. It's more like: If you found that you were able to start the car, the key must have been in the ignition. and is thus quite inappropriate to the imperative style. A functional language MAY be able to use this style, but Python wants to have the condition and then the action. ChrisA The key is in the ignition if you are able to start the car else you hot-wired it. -- http://mail.python.org/mailman/listinfo/python-list
Re: PDB command - variable clashes
If you want to view the variable, use the p (print) command. Then there is no name clash. -- http://mail.python.org/mailman/listinfo/python-list
IX as shorthand for Interface
I'm writing a bunch of classes that have Interface in the name and find that the length of the subsequent names is starting to get in the way of readability (I don't really care about saving keystrokes). Is IX conventional enough to use in place of Interface in a class name? Thanks! -eric -- http://mail.python.org/mailman/listinfo/python-list
Re: IX as shorthand for Interface
On Sat, Oct 8, 2011 at 9:21 PM, Eric Snow ericsnowcurren...@gmail.com wrote: I'm writing a bunch of classes that have Interface in the name and find that the length of the subsequent names is starting to get in the way of readability (I don't really care about saving keystrokes). Is IX conventional enough to use in place of Interface in a class name? Thanks! But classes and interfaces are distinct concepts... - Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: IX as shorthand for Interface
On Sat, Oct 8, 2011 at 10:31 PM, Chris Rebert c...@rebertia.com wrote: On Sat, Oct 8, 2011 at 9:21 PM, Eric Snow ericsnowcurren...@gmail.com wrote: I'm writing a bunch of classes that have Interface in the name and find that the length of the subsequent names is starting to get in the way of readability (I don't really care about saving keystrokes). Is IX conventional enough to use in place of Interface in a class name? Thanks! But classes and interfaces are distinct concepts... - Chris I saw what you did right there! wink Be that as it may, is IX a common enough abbreviation? -eric -- http://mail.python.org/mailman/listinfo/python-list
Re: IX as shorthand for Interface
Eric Snow ericsnowcurren...@gmail.com writes: I'm writing a bunch of classes that have Interface in the name and find that the length of the subsequent names is starting to get in the way of readability (I don't really care about saving keystrokes). Is IX conventional enough to use in place of Interface in a class name? Thanks! Convention in which community? If you just mean in general programming community, I don't think “IX” would suggest interface at all. The only common convention I've seen is the “I” prefix: “IFoo” to suggest “the Foo interface”. But that's hopelessly ambiguous, and I don't recommend it. -- \“Sane people have an appropriate perspective on the relative | `\ importance of foodstuffs and human beings. Crazy people can't | _o__) tell the difference.” —Paul Z. Myers, 2010-04-18 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
[issue10517] test_concurrent_futures crashes with --with-pydebug on RHEL5 with Fatal Python error: Invalid thread state for this thread
Graham Dumpleton graham.dumple...@gmail.com added the comment: Did anyone test this fix for case of fork() being called from Python sub interpreter? Getting a report of fork() failing in sub interpreters under mod_wsgi that may be caused by this change. Still investigating. Specifically throwing up error: Couldn't create autoTLSkey mapping -- nosy: +grahamd ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10517 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13130] test_gdb: attempt to dereference a generic pointer
New submission from Stefan Krah stefan-use...@bytereef.org:
The Fedora bot fails since yesterday:
Breakpoint 1, builtin_id (self=module at remote 0x77f6fc90, v=Traceback
(most recent call last):
File /home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py, line
1329, in to_string
return pyop.get_truncated_repr(MAX_OUTPUT_LEN)
File /home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py, line
213, in get_truncated_repr
self.write_repr(out, set())
File /home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py, line
1199, in write_repr
proxy = self.proxyval(visited)
File /home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py, line
1166, in proxyval
Py_UNICODEs = [int(field_str[i]) for i in safe_range(field_length)]
RuntimeError: Attempt to dereference a generic pointer.
) at Python/bltinmodule.c:927
927 return PyLong_FromVoidPtr(v);
#0 builtin_id (self=module at remote 0x77f6fc90, v=Traceback (most
recent call last):
File /home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py, line
1329, in to_string
return pyop.get_truncated_repr(MAX_OUTPUT_LEN)
File /home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py, line
213, in get_truncated_repr
self.write_repr(out, set())
File /home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py, line
1199, in write_repr
proxy = self.proxyval(visited)
File /home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py, line
1166, in proxyval
Py_UNICODEs = [int(field_str[i]) for i in safe_range(field_length)]
RuntimeError: Attempt to dereference a generic pointer.
) at Python/bltinmodule.c:927
#1 0x004b667f in call_function (pp_stack=0x7fffd6e8, oparg=1) at
Python/ceval.c:3988
#2 0x004b0787 in PyEval_EvalFrameEx (f=Frame 0x77f409c0, for file
string, line 1, in module (), throwflag=0) at Python/ceval.c:2625
#3 0x004b44ca in PyEval_EvalCodeEx (_co=code at remote
0x77f3c880, globals={'__builtins__': module at remote 0x77f6fc90,
'__name__': '__main__', '__doc__': None, '__package__': None},
locals={'__builtins__': module at remote 0x77f6fc90, '__name__':
'__main__', '__doc__': None, '__package__': None}, args=0x0, argcount=0,
kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at
Python/ceval.c:3375
#4 0x004a4668 in PyEval_EvalCode (co=code at remote 0x77f3c880,
globals={'__builtins__': module at remote 0x77f6fc90, '__name__':
'__main__', '__doc__': None, '__package__': None}, locals={'__builtins__':
module at remote 0x77f6fc90, '__name__': '__main__', '__doc__': None,
'__package__': None}) at Python/ceval.c:770
#5 0x004edc20 in run_mod (mod=0x9b0560, filename=0x619622 string,
globals={'__builtins__': module at remote 0x77f6fc90, '__name__':
'__main__', '__doc__': None, '__package__': None}, locals={'__builtins__':
module at remote 0x77f6fc90, '__name__': '__main__', '__doc__': None,
'__package__': None}, flags=0x7fffe3c0, arena=0x92e070) at
Python/pythonrun.c:1795
#6 0x004ed91e in PyRun_StringFlags (str=0x710e1418
id('\\U0001d121')\n, start=257, globals={'__builtins__': module at remote
0x77f6fc90, '__name__': '__main__', '__doc__': None, '__package__': None},
locals={'__builtins__': module at remote 0x77f6fc90, '__name__':
'__main__', '__doc__': None, '__package__': None}, flags=0x7fffe3c0) at
Python/pythonrun.c:1729
#7 0x004ebfb6 in PyRun_SimpleStringFlags (command=0x710e1418
id('\\U0001d121')\n, flags=0x7fffe3c0) at Python/pythonrun.c:1302
#8 0x0050b41f in run_command (command=0x8e0500 Lid('\\U0001d121')\n,
cf=0x7fffe3c0) at Modules/main.c:260
#9 0x0050bf70 in Py_Main (argc=4, argv=0x77faf040) at
Modules/main.c:634
#10 0x00416e97 in main (argc=4, argv=0x7fffe5a8) at
./Modules/python.c:59
--
components: Tests
messages: 145161
nosy: haypo, loewis, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_gdb: attempt to dereference a generic pointer
type: behavior
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13130
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13122] Out of date links in the sidebar of the documentation index of versions 3.1 and 3.2
Georg Brandl ge...@python.org added the comment: Nobody said 3.2 was not stable... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13122 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13060] allow other rounding modes in round()
Mark Dickinson dicki...@gmail.com added the comment: I'm warming to this idea. We already have several round-to-integer functions (but not round-to-an-arbitrary-number-of-decimal-places) available in the math module (under the names floor, ceil and trunc). This *does* seem to be a common need, and it's easy to get roll-your-own implementations wrong (e.g., check what the implementation in msg145140 does for negative numbers). I suspect that once we get more people shifting to py3k we're going to get more complaints about round doing round-half-to-even. Rather than expanding the signature of round, it might be worth considering a new math-module function (with name to be determined) that does round-half-up for floats. We might later extend it to other types in the same way as is currently done for floor and ceil (with __floor__ and __ceil__ magic methods); introduction of such magic methods would probably require a PEP though. At issue: *which* round-half-up function do we want? The one that rounds halfway cases away from zero (what Wikipedia calls Round half away from zero), or the one that rounds halfway cases towards +infinity? I'm inclined towards the former. I don't think it's worth implementing both. I guess we should follow floor / ceil's lead of returning integer output for float input in the case where number of places to round to isn't given (though personally I would have been happier if floor / ceil had continued to return float output for float input, as in Python 2.x). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10517] test_concurrent_futures crashes with --with-pydebug on RHEL5 with Fatal Python error: Invalid thread state for this thread
Charles-François Natali neolo...@free.fr added the comment: Hello, Did anyone test this fix for case of fork() being called from Python sub interpreter? Not specifically, unless it's part of the test suite. Anyway, unless this problem is systematic - which I doubt - it probably wouldn't have helped. Getting a report of fork() failing in sub interpreters under mod_wsgi that may be caused by this change. Still investigating. Specifically throwing up error: Couldn't create autoTLSkey mapping Hmmm. If you can, try strace or instrument the code (perror() should be enough) to see why it's failing. pthread_setspecific() can fail with: - EINVAL, if the TLS key is invalid (which would be strange since we call pthread_key_delete()/pthread_key_create() just before) - or ENOMEM, if you run out of memory/address space The later seems much more likely (e.g. if many child processes and subinterpreters are created). BTW, if this is a bug report from someone else, tell him to post here, it'll be easier. And we don't byte :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10517 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10141] SocketCan support
Charles-François Natali neolo...@free.fr added the comment: Working fine on the buildbots and Vinay's box, closing! -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10141 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13131] FD leak in urllib2
New submission from Valery Khamenya khame...@gmail.com: Explanation from dablitz's comment at https://bugs.pypy.org/issue867 : quote urllib2 in the stdlib leaks fd's if an exception is raised while opening a connection. The issue occurs due to a socket being opened then an exception being raised before an object with the socket is returned, leaving no way to explicitly close the object. On cpython this would not be an issue as the object would lose all references almost immediately however it lingers around with a proper GC causing FD's to build up if the same condition happens repeatedly (eg a loop/web crawling) The file enclosed is a script to generate the leakage, to run invok it as follows python leak.py pypy should start leaking FD's and can be see in /proc/pid of leak.py/fd /quote Related issues: http://bugs.python.org/issue3066 http://bugs.python.org/issue1208304 http://bugs.python.org/issue1601399 -- components: IO, Library (Lib) files: leak.py messages: 145166 nosy: Valery.Khamenya priority: normal severity: normal status: open title: FD leak in urllib2 type: resource usage versions: Python 2.7 Added file: http://bugs.python.org/file23344/leak.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13131 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8087] Unupdated source file in traceback
Diego Mascialino dmascial...@gmail.com added the comment: On Fri, Oct 7, 2011 at 5:25 PM, Ezio Melotti rep...@bugs.python.org wrote: Ezio Melotti ezio.melo...@gmail.com added the comment: I'm not sure this is useful to have. If you changed your code you know that you have to reload, so why would you want a warning that tells you that you changed the code? The source line showed in the traceback could not be the same line executed. Take a look to this example: k.py: def f(): a,b,c = 1,2 Traceback (most recent call last): File stdin, line 1, in module File k.py, line 2, in f a,b,c = 1,2 ValueError: need more than 2 values to unpack k.py: def f(): # blah a,b = 1,2 Traceback (most recent call last): File stdin, line 1, in module File k.py, line 2, in f # blah ValueError: need more than 2 values to unpack For some reason I always had the opposite problem (i.e. after a reload the traceback was still showing the original code, and not the new one), while IIUC you are saying that it shows the new code even if the module is not reloaded. I tried your code and indeed it does what you say, so either I am mistaken and I've been misreading the tracebacks, or this changed from 2.6 to 2.7, or in some cases even the behavior (I think) I observed might happen. I'll have to verify this next time it happens. That is strange, I think Python does not save the original code in any place. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8087 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8087] Unupdated source file in traceback
Ezio Melotti ezio.melo...@gmail.com added the comment: The source line showed in the traceback could not be the same line executed. My point is that when I see an error and modify the source to fix it, then I know that I'll have to reload. If for some reason I forget to reload, I'll get the wrong line in the traceback and then reload, but I don't think that ever happened to me. So to me, your warning will only be useful in the case where I modified the source, forgot to reload and got the same error again with a wrong line displayed. Also note that reloading is not so common; usually you just restart your application and that will give you the right traceback. Also I'm not sure the warning you proposed is the best way to handle this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8087 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13131] FD leak in urllib2
Valery Khamenya khame...@gmail.com added the comment: by the way, timeout parameter should be set to 0.2 as for my 13Mbit ADSL line. With 0.002 it is not reproducible for my environment -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13131 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11812] transient socket failure to connect to 'localhost'
Charles-François Natali neolo...@free.fr added the comment: Attached patch reads the name of the server socket instead of using HOST or 'localhost'. By the way, why do we use 'localhost' instead of '127.0.0.1' for support.HOST? '127.0.0.1' doesn't depend on the DNS configuration of the host (especially its hosts file, even Windows has such file). This might be a good idea. Apparently, Windows 7 doesn't use its hosts file (yes, it does have one) to resolve 'localhost', but its DNS resolver, see http://serverfault.com/questions/4689/windows-7-localhost-name-resolution-is-handled-within-dns-itself-why Depending on the DNS setup, it could lead to a latency which might explain such failures. Seems a clear race condition. The code looks correct: a threading.Event is set by the server once it called listen(), point at which incoming connections should be queued (SYN/ACK is sent before accept()). So I'd bet either on resolution delay (on Unix /etc/nsswitch.conf), or an overloaded machine. -- nosy: +neologix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11812 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13132] distutils sends non-RFC compliant HTTP request
New submission from Mitchell Hashimoto xmit...@gmail.com:
In ``Lib/distutils/command/register.py`` as well as ``upload.py``, the
following code exists to build the HTTP request body to send to the cheese shop
server:
body.write('\nContent-Disposition: form-data; name=%s'%key)
body.write(\n\n)
RFC2616 page 31 (http://tools.ietf.org/html/rfc2616#page-31) states that
headers must be separated by CRLF. Specifically, the above \n\n for the
header separator is causing issues with some minimal RFC-compliant web servers.
--
assignee: tarek
components: Distutils
messages: 145171
nosy: eric.araujo, mitchellh, tarek
priority: normal
severity: normal
status: open
title: distutils sends non-RFC compliant HTTP request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13132
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13132] distutils sends non-RFC compliant HTTP request
Mitchell Hashimoto xmit...@gmail.com added the comment: Patch attached. -- keywords: +patch Added file: http://bugs.python.org/file23345/issue13132.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13132 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8087] Unupdated source file in traceback
Diego Mascialino dmascial...@gmail.com added the comment: So to me, your warning will only be useful in the case where I modified the source, forgot to reload and got the same error again with a wrong line displayed. Also note that reloading is not so common; usually you just restart your application and that will give you the right traceback. I know the case when this happens is really unsusual, but the interperter could be able to alert you than that line of the traceback is wrong. Also I'm not sure the warning you proposed is the best way to handle this. I agree that, another approach is to save a copy of the source file associated to the compiled code (like a .pys). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8087 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12192] Doc that collection mutation methods return item or None
Mike Hoy mho...@gmail.com added the comment: Created a patch based on suggestions here. -- keywords: +patch Added file: http://bugs.python.org/file23346/return-none.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12192 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13130] test_gdb: attempt to dereference a generic pointer
Antoine Pitrou pit...@free.fr added the comment: Following patch seems to fix it: diff --git a/Tools/gdb/libpython.py b/Tools/gdb/libpython.py --- a/Tools/gdb/libpython.py +++ b/Tools/gdb/libpython.py @@ -1152,7 +1152,7 @@ class PyUnicodeObjectPtr(PyObjectPtr): field_str = field_str.cast(_type_unsigned_char_ptr) elif repr_kind == 2: field_str = field_str.cast(_type_unsigned_short_ptr) -elif repr_kind == 3: +elif repr_kind == 4: field_str = field_str.cast(_type_unsigned_int_ptr) else: # Python 3.2 and earlier -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12192] Doc that collection mutation methods return item or None
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 352d075839f7 by Georg Brandl in branch 'default': Closes #12192: Document that mutating list methods do not return the instance (original patch by Mike Hoy). http://hg.python.org/cpython/rev/352d075839f7 -- nosy: +python-dev resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12192 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13130] test_gdb: attempt to dereference a generic pointer
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset ef1f0434c79c by Antoine Pitrou in branch 'default': Fix test_gdb following the small unicode struct change in c25262e97304 (issue #13130) http://hg.python.org/cpython/rev/ef1f0434c79c -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13130] test_gdb: attempt to dereference a generic pointer
Antoine Pitrou pit...@free.fr added the comment: Let's wait for the buildbots. -- resolution: - fixed stage: needs patch - committed/rejected status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13112] backreferences in comprehensions
yoch yoch.me...@gmail.com added the comment: Okay, thanks ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13130] test_gdb: attempt to dereference a generic pointer
Antoine Pitrou pit...@free.fr added the comment: Seems to have cleared the buildbot failures. -- status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13125] test_all_project_files() expected failure
Antoine Pitrou pit...@free.fr added the comment:
Could you arrange to silence stdout/stderr in non-verbose mode?
$ ./python -m test -uall test_lib2to3
[1/1] test_lib2to3
ParseError on file /home/antoine/cpython/default/Lib/lib2to3/main.py bad input:
type=22, value='=', context=('', (81, 38))
ParseError on file
/home/antoine/cpython/default/Lib/lib2to3/tests/pytree_idempotency.py bad
input: type=22, value='=', context=('', (47, 33))
--- /home/antoine/cpython/default/Lib/lib2to3/tests/data/bom.py 2011-08-01
15:24:54.045209157 +0200
+++ @ 2011-10-08 20:31:41.981242859 +0200
@@ -1,2 +1,2 @@
-# coding: utf-8
+# coding: utf-8
print BOM BOOM!
1 test OK.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13125
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13133] FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close()
New submission from Valery Khamenya khame...@gmail.com: The attached file reproduces 3 types of FD leaks and leads to the error like: IOError: [Errno 24] Too many open files: '/tmp/1019' For example if executed with pypy. -- components: IO, Library (Lib) files: zipfiletest.py messages: 145182 nosy: Valery.Khamenya priority: normal severity: normal status: open title: FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close() type: resource usage versions: Python 2.7 Added file: http://bugs.python.org/file23347/zipfiletest.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13131] FD leak in urllib2
Valery Khamenya khame...@gmail.com added the comment: the problem seems to be fixed with the patch attached. Thanks go to fijal@freenode -- keywords: +patch Added file: http://bugs.python.org/file23348/urllib2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13131 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13131] FD leak in urllib2
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13131 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13131] FD leak in urllib2
Ezio Melotti ezio.melo...@gmail.com added the comment: Pay attention not to introduce regressions like the one in #12576 while fixing this. I'm not sure there are similar tests for urllib2 -- if not they should be added. -- nosy: +ezio.melotti stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13131 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13133] FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close()
Meador Inge mead...@gmail.com added the comment: I can't reproduce this problem in either 2.7.2 or 3.3.0a0. For example if executed with pypy. Do you mean that this problem is only reproducible when the attached script is run with pypy? -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13134] speed up finding of one-character strings
New submission from Antoine Pitrou pit...@free.fr:
In stringlib/fastsearch, instead of using our own loops, we can use memchr()
(and, if available, memrchr()) when looking for one-character strings. memchr()
is generally quite optimized; on this Linux/glibc machine, I get speedups of
5x-10x:
./python -m timeit -s large='a'*1+'b' large.find('b')
- before: 10.5 usec per loop
- after: 0.889 usec per loop
./python -m timeit -s large='b'+'a'*1 large.rfind('b')
- before: 7.06 usec per loop
- after: 1.94 usec per loop
--
components: Interpreter Core
messages: 145186
nosy: haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: speed up finding of one-character strings
type: performance
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13134
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13134] speed up finding of one-character strings
Changes by Antoine Pitrou pit...@free.fr: -- keywords: +patch Added file: http://bugs.python.org/file23349/memchr.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13134 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13134] speed up finding of one-character strings
Antoine Pitrou pit...@free.fr added the comment: With MSVC there seems to be no difference, meaning Windows probably has a naïve memchr() implementation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13134 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13133] FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close()
Valery Khamenya khame...@gmail.com added the comment: I can't reproduce this problem in either 2.7.2 or 3.3.0a0. You probably mean CPython implementation of Python. No, I didn't mean this implementation. Do you mean that this problem is only reproducible when the attached script is run with pypy? I can't say only. I just could say yes, it is reproducible with pypy. Perhaps, there are others Python implementations that will suffer from the bug in current implementation of ZipFile -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13134] speed up finding of one-character strings
Antoine Pitrou pit...@free.fr added the comment: New patch with a couple of tests. -- Added file: http://bugs.python.org/file23350/memchr2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13134 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13135] Using type() as a constructor doesn't support new class keyword arguments
New submission from Marty Alchin ma...@martyalchin.com: PEP 3115 introduced keyword arguments to class definitions and changed metaclasses to use them instead. Unfortunately, `type()` doesn't seem to have been updated to accept those keyword arguments as well. What this amounts to is that using `type()` as a constructor can no longer fully replicate the behavior of a class definition. Therefore, classes that use keyword arguments can't be created dynamically. I would attempt a patch, but I don't have a development environment capable of compiling Python, so I wouldn't have any chance to test it. -- messages: 145190 nosy: gulopine priority: normal severity: normal status: open title: Using type() as a constructor doesn't support new class keyword arguments type: feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13135 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13133] FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close()
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Yes, in 2.7 many parts of the stdlib relies on reference counting to close files. But 3.2 introduced a ResourceWarning which is emitted (in debug mode) each time a __del__ closes a valuable resource like a file or a socket. This was done exactly for this reason - help other implementations with a different garbage collector. Now Lib/zipfile.py is probably much more gc-friendly: see how it uses a new member close_fileobj, and the with statement in ZipFile.read(). PyPy will benefit of this when it migrates to 3.2; meanwhile, you could apply the same changes in pypy's own copy of zipfile.py. -- nosy: +amaury.forgeotdarc resolution: - out of date status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13136] speed-up conversion between unicode widths
New submission from Antoine Pitrou pit...@free.fr: This patch speeds up _PyUnicode_CONVERT_BYTES by unrolling its loop. Example micro-benchmark: ./python -m timeit -s a='x'*1;b='\u0102'*1000;c='\U0010' a+b+c - before: 10 loops, best of 3: 14.9 usec per loop - after: 10 loops, best of 3: 9.19 usec per loop -- components: Interpreter Core files: unroll_convert_bytes.patch keywords: patch messages: 145192 nosy: pitrou priority: normal severity: normal stage: patch review status: open title: speed-up conversion between unicode widths type: performance versions: Python 3.3 Added file: http://bugs.python.org/file23351/unroll_convert_bytes.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13136] speed-up conversion between unicode widths
Marc-Andre Lemburg m...@egenix.com added the comment: Antoine Pitrou wrote: New submission from Antoine Pitrou pit...@free.fr: This patch speeds up _PyUnicode_CONVERT_BYTES by unrolling its loop. Example micro-benchmark: ./python -m timeit -s a='x'*1;b='\u0102'*1000;c='\U0010' a+b+c - before: 10 loops, best of 3: 14.9 usec per loop - after: 10 loops, best of 3: 9.19 usec per loop Before going further with this, I'd suggest you have a look at your compiler settings. Such optimizations are normally performed by the compiler and don't need to be implemented in C, making maintenance harder. The fact that Windows doesn't exhibit the same performance difference suggests that the optimizer is not using the same level or feature set as on Linux. MSVC is at least as good at optimizing code as gcc, often better. I tested using memchr() when writing those naive loops. It turned out that using memchr() was slower than using the direct loops. memchr() is inlined by the compiler just like the direct loop and the generated code for the direct version is often easier to optimize for the compiler than the memchr() one, since it receives more knowledge about the used data types. -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13136] speed-up conversion between unicode widths
Antoine Pitrou pit...@free.fr added the comment: Before going further with this, I'd suggest you have a look at your compiler settings. They are set by the configure script: gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. -I./Include-DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c Such optimizations are normally performed by the compiler and don't need to be implemented in C, making maintenance harder. The fact that the glibc includes such optimization (in much more sophisticated form) suggests to me that many compilers don't perform these optimizations automically. I tested using memchr() when writing those naive loops. memchr() is mentioned in another issue, #13134. memchr() is inlined by the compiler just like the direct loop I don't think so. If you look at the glibc's memchr() implementation, it's a sophisticated routine, not a trivial loop. Perhaps you're thinking about memcpy(). and the generated code for the direct version is often easier to optimize for the compiler than the memchr() one, since it receives more knowledge about the used data types. ?? Data types are fixed in the memchr() definition, there's no knowledge to be gained by inlining. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13137] from __future__ import division breaks ad hoc numeric types
New submission from Blair bidih...@gmail.com: I believe that the use of __future__.division may have unintended consequences with user types that define division. The following fails: from __future__ import division class NumericType(object): def __init__(self,x): self.x = x def __div__(self,rhs): return self.x/rhs print NumericType(3.0) / 2.0 with the error message File C:\proj_py\learning\future_bug\future.py, line 10, in module print NumericType(3.0) / 2.0 TypeError: unsupported operand type(s) for /: 'NumericType' and 'float' Remove the line `from __future__ import division` and everything works fine. I am using Python 2.7.2 -- components: None messages: 145195 nosy: gumtree priority: normal severity: normal status: open title: from __future__ import division breaks ad hoc numeric types type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13137 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13137] from __future__ import division breaks ad hoc numeric types
Benjamin Peterson benja...@python.org added the comment: You have to implement __truediv__. -- nosy: +benjamin.peterson resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13137 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13135] Using type() as a constructor doesn't support new class keyword arguments
Benjamin Peterson benja...@python.org added the comment: That's not true. You simply call the metaclass itself. -- nosy: +benjamin.peterson resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13135 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13135] Using type() as a constructor doesn't support new class keyword arguments
Marty Alchin ma...@martyalchin.com added the comment: Hrm, that does seem to satisfy the case I was immediately concerned with, but I was thinking there was another issue with it, but now I'm having trouble pinning down an example. I'll just assume I was getting ahead of myself. Thanks for the sanity lesson. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13135 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13138] ElementTree's Element.iter() lacks versionadded
New submission from Andreas Stührk andy-pyt...@hammerhartes.de: See http://docs.python.org/whatsnew/2.7.html#updated-module-elementtree-1-3 -- assignee: docs@python components: Documentation files: Element_iter_versionadded.patch keywords: patch messages: 145199 nosy: Trundle, docs@python priority: normal severity: normal status: open title: ElementTree's Element.iter() lacks versionadded versions: Python 2.7 Added file: http://bugs.python.org/file23352/Element_iter_versionadded.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13138 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13136] speed-up conversion between unicode widths
Meador Inge mead...@gmail.com added the comment: On Sat, Oct 8, 2011 at 5:34 PM, Antoine Pitrou rep...@bugs.python.org wrote: Antoine Pitrou pit...@free.fr added the comment: Before going further with this, I'd suggest you have a look at your compiler settings. They are set by the configure script: gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c Such optimizations are normally performed by the compiler and don't need to be implemented in C, making maintenance harder. The fact that the glibc includes such optimization (in much more sophisticated form) suggests to me that many compilers don't perform these optimizations automically. I agree. This is more of an optimized runtime library problem than code optimization problem. I tested using memchr() when writing those naive loops. memchr() is mentioned in another issue, #13134. Yeah, this conversation is really more relevant to issue13134, but I will reply to these here anyway memchr() is inlined by the compiler just like the direct loop I don't think so. If you look at the glibc's memchr() implementation, it's a sophisticated routine, not a trivial loop. Perhaps you're thinking about memcpy(). Without link-time optimization enabled, I doubt the toolchain can inline 'memchr' in the traditional sense (i.e. inserting the body of the routine inline). Even if it could, the inline heuristics would most likely choose not to. I don't think we use LTO with GCC, but I think we might with VC++. GCC does something else called builtin folding that is more likely. For example, 'memchr (bca, 'c', 3)' gets replace with instructions to compute a pointer index into bca. This won't happen in this case because all of the 'memchr' arguments are all variable. and the generated code for the direct version is often easier to optimize for the compiler than the memchr() one, since it receives more knowledge about the used data types. ?? Data types are fixed in the memchr() definition, there's no knowledge to be gained by inlining. I think what Marc-Andre is alluding to is that the first parameter of 'memchr' is 'void *' which could (in theory) limit optimization opportunities. Where as if it knew that the data being searched is a 'char *' or something it could take advantage of that. -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10399] AST Optimization: inlining of function calls
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10399 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13139] multiprocessing.map skips finally blocks
New submission from Daniel Wagner-Hall dawag...@gmail.com:
import random
from multiprocessing import Pool
from time import sleep
def Process(x):
try:
print x
sleep(random.random())
raise Exception('Exception: ' + x)
finally:
print 'Finally: ' + x
Pool(3).map(Process, ['1','2','3'])
Expect all three Finally blocks to be called (or at least, one Finally per x
printed by line 8)
Actually, only one (occasionally two) are printed.
Same behaviour exhibited on dual-core Mac running OSX 10.6 with Python 2.7, and
single core Ubuntu running Python 2.6.
--
components: None
messages: 145201
nosy: illicitonion
priority: normal
severity: normal
status: open
title: multiprocessing.map skips finally blocks
type: behavior
versions: Python 2.6, Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13139
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13132] distutils sends non-RFC compliant HTTP request
Éric Araujo mer...@netwok.org added the comment: Hi Mitchell, thanks for your interest in Python. Using CLRF was requested before (#10510) and rejected on the ground that the RFC (at least for HTTP 1.0) allows LF. CRLF is preferred but not required. Hence, we deem it is not a bug. The register, upload and upload_docs commands in distutils2 do use CRLF. BTW, I think your patch was incomplete: You stripped one newline, replaced one LF with CRLF, and left many other LFs. -- assignee: tarek - eric.araujo nosy: +orsenthil versions: -Python 2.6, Python 3.1, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13132 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12533] python-celementtree prevents me from running python develop.py to compile Imprudence Viewer
Éric Araujo mer...@netwok.org added the comment: Closing, please reopen if there is more info. -- resolution: - invalid stage: - committed/rejected status: pending - closed versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12533 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12967] AttributeError distutils\log.py
Éric Araujo mer...@netwok.org added the comment: I stand by my opinion that running setup.py from IDLE is not supported. -- resolution: - wont fix stage: - committed/rejected status: open - closed type: compile error - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12967 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13136] speed-up conversion between unicode widths
Martin v. Löwis mar...@v.loewis.de added the comment: Marc-Andre: gcc will normally not unroll loops, unless -funroll-loops is given on the command line. Then, it will unroll many loops, and do so with 8 iterations per outer loop. This typically causes significant code bloat, which is why unrolling is normally disabled and left to the programmer. For those who want to experiment with this, I attach a C file with just the code in question. Compile this with your favorite compiler settings, and see what the compile generates. clang, on an x64 system, compiles the original loop into LBB0_2: ## =This Inner Loop Header: Depth=1 movzbl (%rdi), %eax movw%ax, (%rdx) incq%rdi addq$2, %rdx decq%rsi jne LBB0_2 and the unrolled loop into LBB1_2: ## %.lr.ph6 ## =This Inner Loop Header: Depth=1 movzbl (%rdi,%rcx), %r8d movw%r8w, (%rdx) movzbl 1(%rdi,%rcx), %r8d movw%r8w, 2(%rdx) movzbl 2(%rdi,%rcx), %r8d movw%r8w, 4(%rdx) movzbl 3(%rdi,%rcx), %r8d movw%r8w, 6(%rdx) addq$8, %rdx addq$4, %rcx cmpq%rax, %rcx jl LBB1_2 -- nosy: +loewis Added file: http://bugs.python.org/file23353/unroll.c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13136 ___ ___ 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
Éric Araujo mer...@netwok.org added the comment: Note the existing test doesn't actually perform a build so the new test also doesn't, but it does check the core logic Sounds good to me. +def manifest_setup_ldargs I’d make all new methods private ones (i.e. leading underscore). an embedded manifests Typo: extra s return None if not temp_manifest else (temp_manifest, mfid) Using a ternary expression runs afoul of PEP 291: distutils should remain compatible with 2.3. (I’m not sure it is right now, we use modern unittest methods in tests and all, but it is no reason for making it worse in new code :) Your patch will also need an entry in Misc/NEWS; at first glance, there is no documentation file to edit. Will you port the patch to packaging in 3.3? I can do it if you don’t have the time, but I’m not set up yet to test on Windows, so I can ask you to test a patch. Also, for the distutils2 backport (which I can do too), we would need to run tests with all versions from 2.4 to 3.3. -- ___ 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
[issue12436] Missing items in installation/setup instructions
Éric Araujo mer...@netwok.org added the comment: In addition to Notepad++ do you think it would be a good idea to at least mention Vim and Emacs with a disclaimer about the learning curve? No. If someone is looking at this page and doesn’t already have a text editor they’re familiar with, I think Notepad++ is the right tool to suggest. Do you think it would be a good idea to add instructions on how to add Python to the Path in Windows? The doc already has that somewhere, unless I misremember. Yes, but isn't there a script somewhere that does that already? One or more in Tools/scripts and maybe in PC or PCbuild too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12436 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13123] bdist_wininst uninstaller does not remove pycache directories
Éric Araujo mer...@netwok.org added the comment: I don’t have a Windows VM set up yet, but I can try to write a patch in the coming weeks and ask you to test it. Deal? -- stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13123 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3902] Packages containing only extension modules have to contain __init__.py
Éric Araujo mer...@netwok.org added the comment: We’re working on a patch on the core-mentorship list. I emailed the diff to the Core-Mentorship list, but since there was no reply I will just attach it here. I added that message here to avoid someone else working on the same bug. I did not reply to the mailing list because it’s not easy to review emailed patches and I don’t have Internet access each day. Please review patch and let me know if you want any changes. Done. You should have received an email; if not, follow the link titled “review” on the right of your patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3902 ___ ___ 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
Mark Hammond skippy.hamm...@gmail.com added the comment: Thanks for the review. One note: | +def manifest_setup_ldargs | I’d make all new methods private ones (i.e. leading underscore). They aren't strictly private and are designed to be overridden by subclasses (although in practice, subclassing the compiler is much harder than it should be, so pywin32 monkey-patches the instance.) This is actually the entire point of my updated patch - to give setup.py authors some level of control over the manifest behaviour. I do intend forward-porting to 3.3 and also to check it is is too late for 3.2 (a quick check before implied it might be OK, but I'm not sure) -- ___ 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
[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch
Éric Araujo mer...@netwok.org added the comment: They aren't strictly private and are designed to be overridden by subclasses OK. I do intend forward-porting to 3.3 and also to check it is is too late for 3.2 (a quick check before implied it might be OK, but I'm not sure) 2.7 and 3.2 are open for bug fixes, as indicated by the versions field of this bug (it’s actually a matrix: component distutils + versions 2.7, 3.2, 3.3, component distutils2 + version 3.3 == packaging and distutils2 + third-party == the distutils2 backport :) -- assignee: tarek - mhammond ___ 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
