Re: PEP 450 Adding a statistics module to Python
Ben Finney, 10.08.2013 07:05: Skip Montanaro writes: Given that installing numpy or scipy is generally no more difficult that executing pip install (scipy|numpy) I'm not really feeling the need for a battery here... See the Rationale of PEP 450 for more reasons why “install NumPy” is not a feasible solution for many use cases, and why having ‘statistics’ as a pure-Python, standard-library package is desirable. The rationale suggests that the module is meant as a simple toolset for non-NumPy users. Are the APIs (class model, function names, etc.) similar enough to make it easy to switch, preferably in both directions? It would be good if a stdlib statistics module could be used as a SciPy fallback for the simple things, and if users of the stdlib module could easily switch their code to SciPy if they need more speed/features/whatever at some point, without having to relearn the name of each single function. I'm not asking for compatibility (doesn't sound reasonable without NumPy arrays), but I think that a similarity in terms of API naming (as far as it makes sense) should be clearly stated, e.g. in the Design Decisions section. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Get filename using filefialog.askfilename
Sarcastic what the kcuf ¿?¿?¿? My english is SO bad? Do you know me? I can not understand this paranoia i only was giving thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3 and SSH Tunnel
What about the security though? To be specific, i need to create an application (python 3.3 strictly) where users will save/load their settings online to a remote hosted database. I do not wish to change the database from listening to any other thing than localhost for security reasons, so i assume the best solution for me would be to make the program create some ssh tunnels before the saving/loading happens. But would this policy make my database (or the rest of the databases that im running on that machine) unsecure? Is there any workaround this? How would you do that online saving/loading? -- http://mail.python.org/mailman/listinfo/python-list
Python 3.3 + QtSql + ssh tunnel - Connection problem
Im using python 3.3 on win7 64bit and trying to connect to a MySQL database on a remote server through a putty ssh tunnel. Running the script below im getting Physical connection to the database did not activate!. What im i doing wrong?! I tried to find a working example but couldnt find one. thx in advance guys from PyQt5 import QtSql def main(): db = QtSql.QSqlDatabase.addDatabase(QMYSQL) db.setHostName(127.0.0.1) db.setPort(3306) db.setDatabaseName(username_databasename) db.setUserName(username) db.setPassword(userpassword) ok = db.open() if ok: print (Physical connection to the database activated) else: print (Physical connection to the database did not activate!) return create_table(db) db.close() main() -- http://mail.python.org/mailman/listinfo/python-list
Re: ftplib returns EOFError
print \t\tUploading file %s... % newname try: self.ftp.storbinary(STOR %s % newname, open(file)) except EOFError: # yep?? self.ftp.connect(self.ftpServ) # reconnecting self.ftp.login(ftpUser, ftpPass) self.ftp.storbinary(STOR %s % newname, open(file)) print \t\tFile %s uploaded % newname -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 450 Adding a statistics module to Python
In article mailman.417.1376104455.1251.python-l...@python.org, Skip Montanaro s...@pobox.com wrote: Given that installing numpy or scipy is generally no more difficult that executing pip install (scipy|numpy) I'm not really feeling the need for a battery here... I just tried installing numpy in a fresh virtualenv on an Ubuntu Precise box. I ran pip install numpy. It took 1.5 minutes. It printed almost 1800 lines of build crap, including 383 warnings and 83 errors. For a newbie, that can be pretty intimidating. That's for the case where I've already installed numpy elsewhere on that box, so I already had the fortran compiler, and the rest of the build chain. For fun, I just spun up a new Ubuntu Precise instance in AWS. It came pre-installed with Python 2.7.3. I tried pip install numpy, which told me that pip was not installed. At least it told me what I needed to do to get pip installed. Unfortunately, I didn't read the message carefully enough and typed sudo apt-get install pip, which of course got me another error because the correct name of the package is python-pip. Doing sudo apt-get install python-pip finally got me to the point where I could start to install numpy. Of course, if I didn't have sudo privs on the box (most corporate environments), I never would have gotten that far. At this point, sudo pip install numpy got me a bunch of errors culminating in RuntimeError: Broken toolchain: cannot link a simple C program, and no indication of how to get any further. At this point, most people would give up. I don't remember the full set of steps I needed to do the first time. Obviously, I would start with installing gcc, but I seem to remember there were additional steps needed to get fortran support. Having some simple statistics baked into the standard python package would be a big win. As shown above, installing numpy can be an insurmountable hurdle for people with insufficient sysadmin-fu. PEP-450 makes cogent arguments why rolling your own statistics routines is fraught with peril. Looking over our source tree, I see we've implemented std deviation in python at least twice. I'm sure they're both naive implementations of the sort PEP-450 warns about. And, yes, backporting to 2.7 would be a big win too. I know the goal is to get everybody onto 3.x, but my pip external dependency list includes 40 modules. It's going to be a long and complicated road to get to the point where I can move to 3.x, and I imagine most non-trivial projects are in a similar situation. -- http://mail.python.org/mailman/listinfo/python-list
Re: Get filename using filefialog.askfilename
On 10 August 2013 11:37, cheirasa...@gmail.com wrote: Sarcastic what the kcuf ¿?¿?¿? My english is SO bad? Do you know me? I can not understand this paranoia i only was giving thanks. Sarcasm and a lack thereof is very hard to see over the Internet. It's probably just a misunderstanding :). -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 450 Adding a statistics module to Python
On 10 August 2013 12:50, Roy Smith r...@panix.com wrote: In article mailman.417.1376104455.1251.python-l...@python.org, Skip Montanaro s...@pobox.com wrote: Given that installing numpy or scipy is generally no more difficult that executing pip install (scipy|numpy) I'm not really feeling the need for a battery here... I just tried installing numpy in a fresh virtualenv on an Ubuntu Precise box. I ran pip install numpy. It took 1.5 minutes. It printed almost 1800 lines of build crap, including 383 warnings and 83 errors. For a newbie, that can be pretty intimidating. That's for the case where I've already installed numpy elsewhere on that box, so I already had the fortran compiler, and the rest of the build chain. For fun, I just spun up a new Ubuntu Precise instance in AWS. It came pre-installed with Python 2.7.3. I tried pip install numpy, which told me that pip was not installed. At least it told me what I needed to do to get pip installed. Unfortunately, I didn't read the message carefully enough and typed sudo apt-get install pip, which of course got me another error because the correct name of the package is python-pip. Doing sudo apt-get install python-pip finally got me to the point where I could start to install numpy. Of course, if I didn't have sudo privs on the box (most corporate environments), I never would have gotten that far. At this point, sudo pip install numpy got me a bunch of errors culminating in RuntimeError: Broken toolchain: cannot link a simple C program, and no indication of how to get any further. You should use apt-get for numpy/scipy on Ubuntu. Although unfortunately IIRC this doesn't work as well as it should since Ubuntu doesn't install the appropriate BLAS/LAPACK libraries by default (leaving you with numpy's fallback libraries). On Windows you should use the MSI installer (or easy_install). Hopefully numpy/scipy will start distributing wheels soon and pip install numpy will actually work. Oscar -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 450 Adding a statistics module to Python
Skip Montanaro s...@pobox.com wrote: installing numpy or scipy is generally no more difficult that executing pip install (scipy|numpy) I described the problems I had trying to follow that advice. In article mailman.425.1376137459.1251.python-l...@python.org, Oscar Benjamin oscar.j.benja...@gmail.com wrote: You should use apt-get for numpy/scipy on Ubuntu. Although unfortunately IIRC this doesn't work as well as it should since Ubuntu doesn't install the appropriate BLAS/LAPACK libraries by default (leaving you with numpy's fallback libraries). That really kind of proves my point. It's *not* easy to install. Theres' a choice of methods, some of which work in some environments, some of which work in others. And even if apt-get is the preferred install method on Ubuntu, it's a method which is unavailable to people without root access (and may be undesirable if you rely on virtualenv to keep multiple projects cleanly separated). And, what happens if you don't have the right libraries? Do you end up with an install which is missing some functionality, or one where all the calls work, but they're slower, or numerically unstable, or what? All these questions go away if it's packaged with the standard library. I'm not sure where the line should be drawn between basic stuff that should be included and advanced stuff that you need an add-on to get, but certainly mean and std-dev should be in the default distribution. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 450 Adding a statistics module to Python
On 10 August 2013 13:43, Roy Smith r...@panix.com wrote: In article mailman.425.1376137459.1251.python-l...@python.org, Oscar Benjamin oscar.j.benja...@gmail.com wrote: You should use apt-get for numpy/scipy on Ubuntu. Although unfortunately IIRC this doesn't work as well as it should since Ubuntu doesn't install the appropriate BLAS/LAPACK libraries by default (leaving you with numpy's fallback libraries). That really kind of proves my point. It's *not* easy to install. Theres' a choice of methods, some of which work in some environments, some of which work in others. And even if apt-get is the preferred install method on Ubuntu, it's a method which is unavailable to people without root access (and may be undesirable if you rely on virtualenv to keep multiple projects cleanly separated). And, what happens if you don't have the right libraries? Do you end up with an install which is missing some functionality, or one where all the calls work, but they're slower, or numerically unstable, or what? AFAIK not having separate BLAS/LAPACK libraries just means that certain operations are a lot slower. If there are differences in accuracy then they aren't significant enough that I've noticed. I think that the reason Ubuntu doesn't install them by default is because it's not sure which ones you want to use. Possibly the best free setup comes from using ATLAS but this is optimised in a CPU-specific way at build time. Ubuntu doesn't provide binaries for it as using generic x86 executables would defeat much of the point of the library (they do make it a lot easier by providing a source package though). Oscar -- http://mail.python.org/mailman/listinfo/python-list
Calling Py_Main() and parsing the output from C
Hello Python C-experts.
I'm trying to embed python27.dll in a C-program written in
MingW-gcc 4.7.2. I've successfully done these initial steps:
typedef int (*Py_Main_t) (int argc, char **argv);
handle = LoadLibrary (python27.dll);
py_main = (Py_Main_t) GetProcAddress (handle, Py_Main);
argv[0] = who_am_I;/* the .exe of the embedding program. python*.dll
doesn't seems to care what this is */
argv[1] = (char*) -c;
argv[2] = PYTHON_CMD; /* see below */
argv[3] = NULL;
rc = (*py_main) (3, argv);
DEBUG: pyembed.c(76): Calling Py_Main():
argv[0] = G:\vc_2010\VC\Projects\EnvTool\src\envtool.exe
argv[1] = -c
argv[2] = import sys;[sys.stdout.write('%s\n' % p) for (i,p) in
enumerate(sys.path)]
argv[3] = NULL.
Which produces the expected 'sys.path[]:
g:\Programfiler\Python27\lib\site-packages\pyzmq-2.2.0.1-py2.7-win32.egg
g:\Programfiler\Python27\lib\site-packages\nose-1.2.1-py2.7.egg
...
But I'd like to grab the stdout from Py_Main() into a pipe, mmap-file or similar
for the calling program to parse. Before I used the embedding solution, I simply
spawned python.exe using my shell and popen(). Then parsed the output
using fgets(). This work fine. But I'd like to try embedding now. Since avoiding
the shell should be faster. No?
How can I accomplish the grabbing of Py_Main() output simplest? Is creating
a memory-mapped file in the calling program a good idea? Can Py_Main() print
to that? If so, how? I'm on Win-XP SP3.
--gv
--
http://mail.python.org/mailman/listinfo/python-list
Python Basic Doubt
Hi Fellow Python Friends, I am new to Python and recently subscribed to the mailing list.I have a doubt regarding the basics of Python. Please help me in understanding the below concept. So doubt is on variables and their contained value. Why does in the below example from Interpreter exploration value of c take pre existing memory location. a=10 id(a) 21665504 b=a id(b) 21665504 c=10 id(c) 21665504 I am actually assigning new value to c. But from the value of id() all three variables take same location. With variables a and b it is ok. But why c taking the same location? Regards, Krishnan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 2013-08-10 21:03, Krishnan Shankar wrote: a=10 id(a) 21665504 b=a id(b) 21665504 c=10 id(c) 21665504 I am actually assigning new value to c. But from the value of id() all three variables take same location. With variables a and b it is ok. But why c taking the same location? As an internal optimization, CPython caches small integer values a = 256 b = 256 a is b True a = 257 b = 257 a is b False Because it's an internal implementation detail, you shouldn't count on this behavior (Jython or Cython or IronPython may differ; or future versions of Python may cache a different range of numbers). Generally, if you are using the is operator to compare against anything other than None, you're doing it wrong. There are exceptions to this, but it takes knowing the particulars. -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
In article mailman.428.1376151419.1251.python-l...@python.org, Krishnan Shankar i.am.song...@gmail.com wrote: Hi Fellow Python Friends, I am new to Python and recently subscribed to the mailing list.I have a doubt regarding the basics of Python. Please help me in understanding the below concept. So doubt is on variables and their contained value. Why does in the below example from Interpreter exploration value of c take pre existing memory location. a=10 id(a) 21665504 b=a id(b) 21665504 c=10 id(c) 21665504 Python doesn't really expose anything about memory locations. The fact that id() returns something which looks like it might be a memory location is purely a detail of the particular implementation you're using. The next thing to understand is that python doesn't have variables. It has objects and names which are bound to those objects. So, what's happening in your example is: 1) a = 10 You're creating an integer object with the value 10, and binding the name a to that object. 2) b = a You're binding another name, b to the same object that a is bound to. 3) c = 10 This is the tricky one. You're using 10 again as a literal, and the interpreter is reusing the same existing (interned) integer object, and binding yet another name, c to it. This part is implementation dependent. Nothing says Python must intern integer literals, it's entirely free to create a new integer object every time you utter 10 in your source code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sat, Aug 10, 2013 at 4:33 PM, Krishnan Shankar i.am.song...@gmail.com wrote: Hi Fellow Python Friends, I am new to Python and recently subscribed to the mailing list.I have a doubt regarding the basics of Python. Please help me in understanding the below concept. So doubt is on variables and their contained value. Tangential to this: Python doesn't have variables that contain anything, but rather has names that are bound to (point to, if you like) objects. You're mostly right, this is just a terminology point. Why does in the below example from Interpreter exploration value of c take pre existing memory location. a=10 id(a) 21665504 b=a id(b) 21665504 c=10 id(c) 21665504 I am actually assigning new value to c. But from the value of id() all three variables take same location. With variables a and b it is ok. But why c taking the same location? CPython caches a number of integer objects for efficiency. Whenever you ask for the integer 10, you'll get the _same_ integer 10. But if you try the same exercise with a much higher number, or with a different value, you should get a unique id. With immutable literals, the interpreter's allowed to reuse them. You don't normally care about the id() of an integer, and nor should you. Same goes for strings; the interpreter's allowed to intern them if it chooses. Generally, don't assume that they're different, don't assume they're the same either. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 8/10/2013 11:33 AM, Krishnan Shankar wrote: Hi Fellow Python Friends, I am new to Python and recently subscribed to the mailing list.I have a doubt regarding the basics of Python. Please help me in understanding the below concept. So doubt is on variables and their contained value. It would be better English to say that you have a 'question' or even 'confusion', rather than a 'doubt'. From your subject line, I got the impression that you doubted that you should learn or use Python. That clearly is not what you meant. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
Hello,
El 10/08/2013 18:40, Tim Chase escribió:
Generally, if you are using the is operator to compare against
anything other than None, you're doing it wrong. There are exceptions
to this, but it takes knowing the particulars.
Now I have one doubt, I use 'is' to compare basic types in python 3, for
example .-
v = []
if type(v) is list:
print('Is list...')
Because I think it is more clear and faster than .-
type(v) == [].__class__ ... or ... isinstance(v, list)
Is this correct?
Thanks.
--
Xavi
--
http://mail.python.org/mailman/listinfo/python-list
The meaning of doubt, was Re: Python Basic Doubt
Terry Reedy wrote: On 8/10/2013 11:33 AM, Krishnan Shankar wrote: Hi Fellow Python Friends, I am new to Python and recently subscribed to the mailing list.I have a doubt regarding the basics of Python. Please help me in understanding the below concept. So doubt is on variables and their contained value. It would be better English to say that you have a 'question' or even 'confusion', rather than a 'doubt'. From your subject line, I got the impression that you doubted that you should learn or use Python. That clearly is not what you meant. Quoting http://en.wikipedia.org/wiki/Indian_English doubt = question or query; e.g. one would say, 'I have a doubt' when one wishes to ask a question. I'd say if Brits can cope (hard as it may be) with the American variant of the language, and native speakers can live with the broken English used to communicate in the rest of the world there is ample room for an Indian flavo(u)r now and then... -- http://mail.python.org/mailman/listinfo/python-list
Re: The meaning of doubt, was Re: Python Basic Doubt
In article mailman.433.1376159810.1251.python-l...@python.org, Peter Otten __pete...@web.de wrote: Quoting http://en.wikipedia.org/wiki/Indian_English doubt = question or query; e.g. one would say, 'I have a doubt' when one wishes to ask a question. I'd say if Brits can cope (hard as it may be) with the American variant of the language, and native speakers can live with the broken English used to communicate in the rest of the world there is ample room for an Indian flavo(u)r now and then... Yup. I used to work with a development team in Bangalore. One of the amusing aspects of the collaboration was the subtle language issues. For example, apparently, Roy is a common *last* name in India. No matter how many times I explained it, the guys over there couldn't seem to get that Roy is my first name and Smith is my last name. So, in settings where everybody was using first names, they would always call me Smith. I shudder to think what carnage I accidentally inflicted on their names :-) And, of course, since we're on the subject, this should be required reading for all programmers: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about- names/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3 and SSH Tunnel
I think I missed an earlier thread of this and I'm not quite sure what your application is, but properly allocating user permissions on your databases should eliminate any security concerns there. Also, for the tunnel, whether you're using one account or multiple (one for each user), those accounts should be properly secured as well. Ignotus On 08/10/2013 06:39 AM, D. Xenakis wrote: What about the security though? To be specific, i need to create an application (python 3.3 strictly) where users will save/load their settings online to a remote hosted database. I do not wish to change the database from listening to any other thing than localhost for security reasons, so i assume the best solution for me would be to make the program create some ssh tunnels before the saving/loading happens. But would this policy make my database (or the rest of the databases that im running on that machine) unsecure? Is there any workaround this? How would you do that online saving/loading? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sat, 10 Aug 2013 20:00:58 +0200, Xavi wrote:
Now I have one doubt, I use 'is' to compare basic types in python 3, for
example .-
v = []
if type(v) is list:
print('Is list...')
No, do not do this. This is unnecessarily restrictive.
Because I think it is more clear and faster than .-
Clear? Maybe. Clear, but does the wrong thing. Using type rejects
subclasses, which is normally a bad idea. Using isinstance accepts
subclasses, which is what we nearly always should do.
As for being faster -- who cares? The difference between calling type and
calling isinstance is about 0.02 microseconds on my slow computer. You
should not try to optimize things which are so unimportant.
The first rule of optimization: Don't do it.
For experts only: Don't do it yet.
Until you have profiled your application, and discovered calling
isinstance is the bottleneck making your application too slow, you are
wasting your time trying to guess what will make it go faster.
type(v) == [].__class__
You should not do that either. Names starting and ending with double-
underscore are reserved for Python. They are not quite private
implementation details, but you almost never need to use them directly.
Why keep a dog and then bark yourself? Python will check __class__ for
you, when and if needed. That is not your job. It is very rare to need to
use __dunder__ attributes by hand.
... or ... isinstance(v, list)
That's the right solution, 99.9% of the time.
Actually, 99% of the time you should not call isinstance at all, but just
catch any errors that occur; or better still, only catch them if you can
do something about it. Otherwise, just allow the exception to propagate
to the caller, who may catch it. Calling isinstance should be rare;
calling type to check for an exact class even rarer.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: The meaning of doubt, was Re: Python Basic Doubt
On Sat, 10 Aug 2013 20:36:52 +0200, Peter Otten wrote: Terry Reedy wrote: On 8/10/2013 11:33 AM, Krishnan Shankar wrote: Hi Fellow Python Friends, I am new to Python and recently subscribed to the mailing list.I have a doubt regarding the basics of Python. Please help me in understanding the below concept. So doubt is on variables and their contained value. It would be better English to say that you have a 'question' or even 'confusion', rather than a 'doubt'. From your subject line, I got the impression that you doubted that you should learn or use Python. That clearly is not what you meant. Quoting http://en.wikipedia.org/wiki/Indian_English doubt = question or query; e.g. one would say, 'I have a doubt' when one wishes to ask a question. I'd say if Brits can cope (hard as it may be) with the American variant of the language, and native speakers can live with the broken English used to communicate in the rest of the world there is ample room for an Indian flavo(u)r now and then... +1 Ill take broken English from a non native speaker over the confusion caused by our American cousins who seam to have everything arse about face (especially if you consider the word Fanny ) Seriously though I can usually work out what the meaning was, it is certainly clearer than any attempt I could make in any other language, which is actually quite shameful. -- My way of joking is to tell the truth. That's the funniest joke in the world. -- Muhammad Ali -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 8/10/2013 2:00 PM, Xavi wrote:
Hello,
El 10/08/2013 18:40, Tim Chase escribió:
Generally, if you are using the is operator to compare against
anything other than None, you're doing it wrong. There are exceptions
to this, but it takes knowing the particulars.
Now I have one doubt, I use 'is' to compare basic types in python 3, for
example .-
v = []
if type(v) is list:
print('Is list...')
Because I think it is more clear and faster than .-
type(v) == [].__class__ ... or ... isinstance(v, list)
Is this correct?
It depends on the context. If one is writing a test for a function that
is defined as returning a list, such as the builtin function *sorted*,
then 'is list' would be correct.
When one knows the type, as in your toy snippet, 'is list' is nonsensical.
In a more typical situation, as when testing the argument to a function
in the body of a function, then 'isinstance(arg, list)' is almost
certainly more correct (but often still not best) as the function should
usually accept at least any list subclass instance.
def popslice(lis, start, stop=None, step=0):
if not isinstance(lis, list):
raise TypeError(Can only popslice a list)
if stop is None: # here is where is *should* be used
start, stop = 0, start
ret = lis[start:stop:step]
del lis[start:stop:step]
return ret
lis = list(range(10))
print(popslice(lis, 2, 9, 2), lis)
[2, 4, 6, 8] [0, 1, 3, 5, 7, 9]
However, why exclude a mutable sequence that support slices but is not
specifically a list?
def popslice(seq, start, stop=None, step=0):
if stop is None: # here is where is *should* be used
start, stop = 0, start
ret = seq[start:stop:step]
del seq[start:stop:step]
return ret
Bad inputs will raise TypeErrors.
TypeError: 'int' object is not subscriptable
TypeError: 'tuple' object doesn't support item deletion
It this is not good enough, wrap the body in
try:
...
except TypeError as e:
raise TypeError(your custom message here)
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: The meaning of doubt, was Re: Python Basic Doubt
On 8/10/2013 2:36 PM, Peter Otten wrote: Terry Reedy wrote: On 8/10/2013 11:33 AM, Krishnan Shankar wrote: Hi Fellow Python Friends, I am new to Python and recently subscribed to the mailing list.I have a doubt regarding the basics of Python. Please help me in understanding the below concept. So doubt is on variables and their contained value. It would be better English to say that you have a 'question' or even 'confusion', rather than a 'doubt'. From your subject line, I got the impression that you doubted that you should learn or use Python. That clearly is not what you meant. Quoting http://en.wikipedia.org/wiki/Indian_English doubt = question or query; e.g. one would say, 'I have a doubt' when one wishes to ask a question. Thank you for verifying by suspicion (in the neutral sense) that this might be a generic Indian English usage. I'd say if Brits can cope (hard as it may be) with the American variant of the language, and native speakers can live with the broken English used to communicate in the rest of the world there is ample room for an Indian flavo(u)r now and then... The issue I raised was one of avoiding misunderstanding, especially in a short subject line. I almost skipped over the post because of it. I could have added a recommendation to be more specific. Any of Question/confusion/doubt about int identity would have been better. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
How many times does unittest run each test?
I am working on a library, and adding one feature broke a seemingly unrelated
feature. As I already had Test Cases written, I decided to try to incorporate
the logging module into my class, and turn on debugging at the logger before
the newly-broken test.
Here is an example script:
# -
#!/usr/bin/env python
import logging
def get_vals():
return ['a','b','c']
class SimpleChecker(object):
def __init__(self, callback=None):
self.callback = callback
self.logger = logging.getLogger(self.__class__.__name__)
h = logging.StreamHandler()
f = logging.Formatter(%(name)s - %(levelname)s - %(message)s)
h.setFormatter(f)
self.logger.addHandler(h)
def __call__(self, thing):
self.logger.debug('calling %s' % thing)
vals = self.callback()
return thing in vals
import unittest
class LoaderTC(unittest.TestCase):
def setUp(self):
self.checker = SimpleChecker(get_vals)
def tearDown(self):
del self.checker
def test_callable(self):
self.assertTrue(callable(self.checker),
'loader did not create callable object')
self.assertTrue(callable(self.checker.callback),
'loader did not create callable callback')
self.checker.logger.setLevel(logging.DEBUG)
self.assertTrue(self.checker('q') is False, checker accepted bad
input)
class NameSpaceTC(unittest.TestCase):
def setUp(self):
self.checker = SimpleChecker(get_vals)
def tearDown(self):
del self.checker
def test_callable(self):
self.assertTrue(callable(self.checker),
'loader did not create callable object')
self.assertTrue(callable(self.checker.callback),
'loader did not create callable callback')
self.checker.logger.setLevel(logging.DEBUG)
self.assertTrue(self.checker('a'), checker did not accept good value)
self.assertFalse(self.checker('f'), checker accepted bad value)
if __name__=='__main__':
unittest.main(verbosity=0)
# ---
When I run this, I get:
SimpleChecker - DEBUG - calling q
SimpleChecker - DEBUG - calling a
SimpleChecker - DEBUG - calling a
SimpleChecker - DEBUG - calling f
SimpleChecker - DEBUG - calling f
--
Ran 2 tests in 0.013s
OK
Exit code: False
Why am I seeing those extra debugging lines? In the script I'm really trying to
debug, I see 12-13 debug messages repeated, making actual debugging difficult.
Josh English
--
http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
In article f7b24010-f3f4-4e86-b6c4-9ddb503d0...@googlegroups.com, Josh English joshua.r.engl...@gmail.com wrote: I am working on a library, and adding one feature broke a seemingly unrelated feature. As I already had Test Cases written, I decided to try to incorporate the logging module into my class, and turn on debugging at the logger before the newly-broken test. Here is an example script: [followed by 60 lines of code] The first thing to do is get this down to some minimal amount of code that demonstrates the problem. For example, you drag in the logging module, and do some semi-complex configuration. Are you SURE your tests are getting run multiple times, or maybe it's just that they're getting LOGGED multiple times. Tear out all the logging stuff. Just use a plain print statement. You've got two different TestCases here. Does the problem happen with just LoaderTC, or with just NameSpaceTC? Keep tearing out code until you can no longer demonstrate the problem. Keep at it until there is not a single line of code remaining which isn't required to demonstrate. Then come back and ask your question again. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
In article mailman.439.137613.1251.python-l...@python.org, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: Because id(n) is not giving you the address of the NAME. It is giving you the address of the 10 Actually, it is giving you the id of the int(10) object. Maybe it's an address, maybe it's not. Only your implementation knows for sure. -- http://mail.python.org/mailman/listinfo/python-list
Re: The meaning of doubt, was Re: Python Basic Doubt
Peter Otten wrote: doubt Oh bother, said Pooh, what's in a word ? http://en.wikipedia.org/wiki/Curry https://pypi.python.org/pypi/curry/ http://en.wikipedia.org/wiki/Currying -- Stanley C. Kitching Human Being Phoenix, Arizona -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sat, Aug 10, 2013 at 7:00 PM, Xavi jara...@gmail.com wrote:
Now I have one doubt, I use 'is' to compare basic types in python 3, for
example .-
v = []
if type(v) is list:
print('Is list...')
Because I think it is more clear and faster than .-
type(v) == [].__class__ ... or ... isinstance(v, list)
Is this correct?
Thanks.
This really should be a separate thread, rather than a follow-up to
the previous one, since it's quite unrelated. But anyway.
The isinstance check is the better one, because it will also accept a
subclass of list, which the others won't.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 08/10/2013 11:00 AM, Xavi wrote:
Hello,
El 10/08/2013 18:40, Tim Chase escribió:
Generally, if you are using the is operator to compare against
anything other than None, you're doing it wrong. There are exceptions
to this, but it takes knowing the particulars.
Now I have one doubt, I use 'is' to compare basic types in python 3,
for example .-
v = []
if type(v) is list:
print('Is list...')
Because I think it is more clear and faster than .-
type(v) == [].__class__ ... or ... isinstance(v, list)
Is this correct?
Thanks.
No! Don't do that! If you want to compare values use the == operator.
This is an oversimplification, but generally useful for all beginner
(and most advanced) programmers:
Don't use is for comparisons. Use ==.
It 20 years of programming Python, I've *needed* to use is ... only
once or twice.
Beyond that, there is a small batch of comparisons where is is
slightly more Pythonic, but not really necessary. And beyond that,
there are several instances where the difference between is and ==
are important.
Mostly, using is is inappropriate and will get you into compassions
that depend on implementation details. For instance don't use is
until you understand this:
q:~ python3
Python 3.3.1 (default, Apr 17 2013, 22:32:14)
[GCC 4.7.3] on linux
Type help, copyright, credits or license for more information.
101 is 1+100
True
1001 is 1+1000
False
Gary Herron
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sat, Aug 10, 2013 at 10:48 PM, Gary Herron gary.her...@islandtraining.com wrote: This is an oversimplification, but generally useful for all beginner (and most advanced) programmers: Don't use is for comparisons. Use ==. It 20 years of programming Python, I've *needed* to use is ... only once or twice. Hrm, I wouldn't make it that hard a rule. Both comparisons have their place. As has been mentioned earlier in this thread, checking if something is None is spelled if something is None. Checking if it equals zero is spelled if it == 0, which is a quite different check. The other common check that uses 'is' is with an argument default where absolutely anything could be passed: _notpassed = object() def frob(appendage, device=_notpassed): Use some appendage to frob some device, or None to frob nothing. Omit device to frob whatever is currently held in that appendage if device is _notpassed: device = ... # whatever you need if device is not None: # frob the device But granted, equality comparisons are a LOT more common than identity comparisons. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
On Saturday, August 10, 2013 1:40:43 PM UTC-7, Roy Smith wrote:
In article f7b24010-f3f4-4e86-b6c4-9ddb503d0...@googlegroups.com,
Josh English wrote:
The first thing to do is get this down to some minimal amount of code
that demonstrates the problem.
For example, you drag in the logging module, and do some semi-complex
configuration. Are you SURE your tests are getting run multiple times,
or maybe it's just that they're getting LOGGED multiple times. Tear out
all the logging stuff. Just use a plain print statement.
You've got two different TestCases here. Does the problem happen with
just LoaderTC, or with just NameSpaceTC?
Ok, then why would things get logged multiple times? The two test cases
actually test a loader function that I could strip out, because it wasn't
relevant. In these cases, the loader was being called with two different
configurations in the individual setUp methods.
I left them there to show that in LoaderTC, there is one debug log coming from
SimpleChecker, but in the NameSpaceTC, each debug message is printed twice. If
I print statements on each test_ method, they are called once.
As far as stripping down the code, I suppose 15 lines can be culled:
#-
import logging
class SimpleChecker(object):
def __init__(self,):
self.logger = logging.getLogger(self.__class__.__name__)
h = logging.StreamHandler()
f = logging.Formatter(%(name)s - %(levelname)s - %(message)s)
h.setFormatter(f)
self.logger.addHandler(h)
def __call__(self, thing):
self.logger.debug('calling %s' % thing)
return thing in ['a','b','c']
import unittest
class LoaderTC(unittest.TestCase):
def setUp(self):
self.checker = SimpleChecker()
def tearDown(self):
del self.checker
def test_callable(self):
self.checker.logger.setLevel(logging.DEBUG)
self.assertTrue(self.checker('q') is False, checker accepted bad
input)
class NameSpaceTC(unittest.TestCase):
def setUp(self):
self.checker = SimpleChecker()
def tearDown(self):
del self.checker
def test_callable(self):
print testing callable
self.checker.logger.setLevel(logging.DEBUG)
self.assertTrue(self.checker('a'), checker did not accept good value)
self.assertFalse(self.checker('f'), checker accepted bad value)
if __name__=='__main__':
unittest.main(verbosity=0)
#---
The output:
SimpleChecker - DEBUG - calling q
setting up NameSpace
testing callable
SimpleChecker - DEBUG - calling a
SimpleChecker - DEBUG - calling a
SimpleChecker - DEBUG - calling f
SimpleChecker - DEBUG - calling f
--
Ran 2 tests in 0.014s
OK
Exit code: False
Josh
--
http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
Aha. Thanks, Ned. This is the answer I was looking for. I use logging in the real classes, and thought that turning setting the level to logging.DEBUG once was easier than hunting down four score of print statements. Josh On Sat, Aug 10, 2013 at 3:52 PM, Ned Batchelder n...@nedbatchelder.com wrote: On 8/10/13 4:40 PM, Roy Smith wrote: In article f7b24010-f3f4-4e86-b6c4-9ddb503d0...@googlegroups.com, Josh English joshua.r.engl...@gmail.com wrote: I am working on a library, and adding one feature broke a seemingly unrelated feature. As I already had Test Cases written, I decided to try to incorporate the logging module into my class, and turn on debugging at the logger before the newly-broken test. Here is an example script: [followed by 60 lines of code] The first thing to do is get this down to some minimal amount of code that demonstrates the problem. For example, you drag in the logging module, and do some semi-complex configuration. Are you SURE your tests are getting run multiple times, or maybe it's just that they're getting LOGGED multiple times. Tear out all the logging stuff. Just use a plain print statement. Roy is right: the problem isn't the tests, it's the logging. You are calling .addHandler in the SimpleChecker.__init__, then you are constructing two SimpleCheckers, each of which adds a handler. In the LoaderTC test, you've only constructed one, adding only one handler, so the calling q line only appears once. Then the NameSpaceTC tests runs, constructs another SimplerChecker, which adds another handler, so now there are two. That's why the calling a and calling f lines appear twice. Move your logging configuration to a place that executes only once. Also, btw, you don't need the del self.checker in your tearDown methods: the test object is destroyed after each test, so any objects it holds will be released after each test with no special action needed on your part. --Ned. -- Josh English joshua.r.engl...@gmail.com http://www.joshuarenglish.com -- http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
On Saturday, August 10, 2013 1:40:43 PM UTC-7, Roy Smith wrote: For example, you drag in the logging module, and do some semi-complex configuration. Are you SURE your tests are getting run multiple times, or maybe it's just that they're getting LOGGED multiple times. Tear out all the logging stuff. Just use a plain print statement. In article 35d12db6-c367-4a45-a68e-8ed4c0ae1...@googlegroups.com, Josh English joshua.r.engl...@gmail.com wrote: Ok, then why would things get logged multiple times? Maybe you've got two different handlers which are both getting the same logging events and somehow they both end up in your stderr stream. Likely? Maybe not, but if you don't have any logging code in the test at all, it becomes impossible. You can't have a bug in a line of code that doesn't exist (yeah, I know, that's a bit of a handwave). When a test (or any other code) is doing something you don't understand, the best way to start understanding it is to create a minimal test case; the absolute smallest amount of code that demonstrates the problem. I don't understand the whole SimpleChecker class. You've created a class, and defined your own __call__(), just so you can check if a string is in a list? Couldn't this be done much simpler with a plain old function: def checker(thing): print calling %s % thing return thing in ['a','b','c'] -- http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
On Sun, Aug 11, 2013 at 12:14 AM, Roy Smith r...@panix.com wrote:
Maybe you've got two different handlers which are both getting the same
logging events and somehow they both end up in your stderr stream.
Likely? Maybe not, but if you don't have any logging code in the test
at all, it becomes impossible. You can't have a bug in a line of code
that doesn't exist (yeah, I know, that's a bit of a handwave).
Likely? Very much so, to the extent that it is, if not a FAQ,
certainly a Not All That Uncommonly Asked Question. So many times
someone places logging code in something that gets called twice, and
ends up with two handlers. Personally, I much prefer to debug with
straight-up 'print' - much less hassle. I'd turn to the logging module
only if I actually need its functionality (logging to some place other
than the console, or leaving the log statements in and {en|dis}abling
them at run-time).
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
On 8/10/13 4:40 PM, Roy Smith wrote: In article f7b24010-f3f4-4e86-b6c4-9ddb503d0...@googlegroups.com, Josh English joshua.r.engl...@gmail.com wrote: I am working on a library, and adding one feature broke a seemingly unrelated feature. As I already had Test Cases written, I decided to try to incorporate the logging module into my class, and turn on debugging at the logger before the newly-broken test. Here is an example script: [followed by 60 lines of code] The first thing to do is get this down to some minimal amount of code that demonstrates the problem. For example, you drag in the logging module, and do some semi-complex configuration. Are you SURE your tests are getting run multiple times, or maybe it's just that they're getting LOGGED multiple times. Tear out all the logging stuff. Just use a plain print statement. Roy is right: the problem isn't the tests, it's the logging. You are calling .addHandler in the SimpleChecker.__init__, then you are constructing two SimpleCheckers, each of which adds a handler. In the LoaderTC test, you've only constructed one, adding only one handler, so the calling q line only appears once. Then the NameSpaceTC tests runs, constructs another SimplerChecker, which adds another handler, so now there are two. That's why the calling a and calling f lines appear twice. Move your logging configuration to a place that executes only once. Also, btw, you don't need the del self.checker in your tearDown methods: the test object is destroyed after each test, so any objects it holds will be released after each test with no special action needed on your part. --Ned. -- http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
On Saturday, August 10, 2013 4:14:09 PM UTC-7, Roy Smith wrote: I don't understand the whole SimpleChecker class. You've created a class, and defined your own __call__(), just so you can check if a string is in a list? Couldn't this be done much simpler with a plain old function: def checker(thing): print calling %s % thing return thing in ['a','b','c'] SimpleCheck is an extremely watered down version of my XML checker (https://pypi.python.org/pypi/XMLCheck/0.6.7). I'm working a feature that allows the checker to call a function to get acceptable values, instead of defining them at the start of the program. I included all of that because it's the shape of the script I'm working with. The real problem was setting additional handlers where they shouldn't be. Josh -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 08/10/2013 03:09 PM, Chris Angelico wrote: On Sat, Aug 10, 2013 at 10:48 PM, Gary Herron gary.her...@islandtraining.com wrote: This is an oversimplification, but generally useful for all beginner (and most advanced) programmers: Don't use is for comparisons. Use ==. It 20 years of programming Python, I've *needed* to use is ... only once or twice. Hrm, I wouldn't make it that hard a rule. Both comparisons have their place. As has been mentioned earlier in this thread, checking if something is None is spelled if something is None. Checking if it equals zero is spelled if it == 0, which is a quite different check. The other common check that uses 'is' is with an argument default where absolutely anything could be passed: _notpassed = object() def frob(appendage, device=_notpassed): Use some appendage to frob some device, or None to frob nothing. Omit device to frob whatever is currently held in that appendage if device is _notpassed: device = ... # whatever you need if device is not None: # frob the device But granted, equality comparisons are a LOT more common than identity comparisons. ChrisA Everything you say is true, and even reasonable for those who know what's up. But for each of your examples, using == is equivalent to using is. Each of if something == None if device == _not passed if device != None would all work as expected. In none of those cases is is actually needed. Given that, and the implementation dependent oddities, I still believe that it is *highly* misleading to teach a beginner about is. Here's a challenge: What is the simplest non-contrived example where an is comparison is *required*. Where substitution of an == comparison would cause the program to fail or be significantly less efficient? (I'm not including the nearly immeasurably small timing difference between v==None and v is None.) Gary Herron -- http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
On Saturday, August 10, 2013 4:21:35 PM UTC-7, Chris Angelico wrote:
On Sun, Aug 11, 2013 at 12:14 AM, Roy Smith wrote:
Maybe you've got two different handlers which are both getting the same
loggingvents and somehow they both end up in your stderr stream.
Likely? Maybe not, but if you don't have any logging code in the test
at all, it becomes impossible. You can't have a bug in a line of code
that doesn't exist (yeah, I know, that's a bit of a handwave).
Likely? Very much so, to the extent that it is, if not a FAQ,
certainly a Not All That Uncommonly Asked Question. So many times
someone places logging code in something that gets called twice, and
ends up with two handlers. Personally, I much prefer to debug with
straight-up 'print' - much less hassle. I'd turn to the logging module
only if I actually need its functionality (logging to some place other
than the console, or leaving the log statements in and {en|dis}abling
them at run-time).
Yes, I definitely need the NUATAQ sheet for Python.
I'm using logging for debugging, because it is pretty straightforward and can
be activated for a small section of the module. My modules run long (3,000
lines or so) and finding all those dastardly print statements is a pain, and
littering my code with if debug: print message clauses. Logging just makes it
simple.
Josh
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sun, Aug 11, 2013 at 1:42 AM, Gary Herron gary.her...@islandtraining.com wrote: On 08/10/2013 03:09 PM, Chris Angelico wrote: _notpassed = object() def frob(appendage, device=_notpassed): Use some appendage to frob some device, or None to frob nothing. Omit device to frob whatever is currently held in that appendage if device is _notpassed: device = ... # whatever you need if device is not None: # frob the device But granted, equality comparisons are a LOT more common than identity comparisons. ChrisA Everything you say is true, and even reasonable for those who know what's up. But for each of your examples, using == is equivalent to using is. Each of if something == None if device == _not passed if device != None would all work as expected. In none of those cases is is actually needed. Wrong. If you do equality comparisons, it's entirely possible for something to be passed in that compares equal to the RHS without actually being it, so is is precisely what's wanted. (Plus, why go through a potentially expensive comparison check when you can simply check object identity - which could be, for instance, an address check? But performance is a distant second to correctness here.) Given that, and the implementation dependent oddities, I still believe that it is *highly* misleading to teach a beginner about is. Here's a challenge: What is the simplest non-contrived example where an is comparison is *required*. Where substitution of an == comparison would cause the program to fail or be significantly less efficient? (I'm not including the nearly immeasurably small timing difference between v==None and v is None.) All it takes is a slightly odd or buggy __eq__ implementation and the == versions will misbehave. To check if an argument is something, you use is, not ==. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
On Sun, Aug 11, 2013 at 1:52 AM, Josh English joshua.r.engl...@gmail.com wrote: I'm using logging for debugging, because it is pretty straightforward and can be activated for a small section of the module. My modules run long (3,000 lines or so) and finding all those dastardly print statements is a pain, and littering my code with if debug: print message clauses. Logging just makes it simple. So logging might be the right tool for your job. Tip: Sometimes it helps, when trying to pin down an issue, to use an additional debugging aid. You're already using logging? Add print calls. Already got a heartbeat function? Run it through a single-stepping debugger as well. Usually that sort of thing just gives you multiple probes at the actual problem, but occasionally you'll get an issue like this, and suddenly it's really obvious because one probe behaves completely differently from the other. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 8/10/2013 8:42 PM, Gary Herron wrote:
But for each of your examples, using == is equivalent to using is.
Each of
if something == None
if device == _not passed
if device != None
would all work as expected. In none of those cases is is actually
needed.
class EqualAll:
def __eq__(self, other): return True
ea = EqualAll()
print(ea == None)
print(ea == float('nan'))
True
True
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sun, Aug 11, 2013 at 2:25 AM, Terry Reedy tjre...@udel.edu wrote: On 8/10/2013 8:42 PM, Gary Herron wrote: But for each of your examples, using == is equivalent to using is. Each of if something == None if device == _not passed if device != None would all work as expected. In none of those cases is is actually needed. class EqualAll: def __eq__(self, other): return True That's a contrived example, of course, but it's easy to have a bug in __eq__ that results in the same behaviour. I can't imagine any code that would actually WANT that, unless you're trying to represent Animal Farm. class EqualAll: def __eq__(self, other): if (isinstance(other, pig): return 3 # Some are more equal than others return True ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Am I not seeing the Error?
I am checking my 1292-line script for syntax errors. I ran the following
commands in a terminal to check for errors, but I do not see the error.
collier@Nacho-Laptop:/media/collier/AI/Pysh$ python3 -m py_compile
./beta_engine
File ./beta_engine, line 344
JOB_WRITEURGFILES =
multiprocessing.Process(write2file('./mem/ENGINE_PID', ENGINEPID);
write2file(SENTEMPPATH, ''); write2file(INPUTMEM, ''));
JOB_WRITEURGFILES.start()
^
SyntaxError: invalid syntax
collier@Nacho-Laptop:/media/collier/AI/Pysh$ pylint ./beta_engine
No config file found, using default configuration
* Module beta_engine
E:344,0: invalid syntax
Here is line 344:
JOB_WRITEURGFILES =
multiprocessing.Process(write2file('./mem/ENGINE_PID', ENGINEPID);
write2file(SENTEMPPATH, ''); write2file(INPUTMEM, ''));
JOB_WRITEURGFILES.start()
The ENGINEPID is a variable containing a string. My write2file function is
def write2file(openfile, WRITE):
with open(openfile, 'rw') as file:
file.write(WRITE)
Mahalo,
devyncjohn...@gmail.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Am I not seeing the Error?
On Sun, Aug 11, 2013 at 3:19 AM, Devyn Collier Johnson
devyncjohn...@gmail.com wrote:
am checking my 1292-line script for syntax errors. I ran the following
commands in a terminal to check for errors, but I do not see the error.
collier@Nacho-Laptop:/media/collier/AI/Pysh$ python3 -m py_compile
./beta_engine
File ./beta_engine, line 344
JOB_WRITEURGFILES =
multiprocessing.Process(write2file('./mem/ENGINE_PID', ENGINEPID);
write2file(SENTEMPPATH, ''); write2file(INPUTMEM, ''));
JOB_WRITEURGFILES.start()
^
SyntaxError: invalid syntax
When you get a syntax error you can't understand, look at the previous
line of code. Perhaps something there is incomplete; maybe you have
mismatched parentheses, so this line is considered to be part of the
same expression.
Next thing to do is split it into more lines. Why is all that in a single line?
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Am I not seeing the Error?
In article mailman.452.1376188442.1251.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: When you get a syntax error you can't understand, look at the previous line of code. Perhaps something there is incomplete; maybe you have mismatched parentheses, so this line is considered to be part of the same expression. Next thing to do is split it into more lines. Why is all that in a single line? Also, try reformatting the code in a tool like emacs or eclipse which does syntax coloring and auto indenting. Often, if you're missing some piece of punctuation, it will become obvious when your tool tries to indent things in some unexpected way. Or suddenly starts coloring all of your program text as if it were a string literal :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Am I not seeing the Error?
On Sun, Aug 11, 2013 at 3:43 AM, Roy Smith r...@panix.com wrote: In article mailman.452.1376188442.1251.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: When you get a syntax error you can't understand, look at the previous line of code. Perhaps something there is incomplete; maybe you have mismatched parentheses, so this line is considered to be part of the same expression. Next thing to do is split it into more lines. Why is all that in a single line? Also, try reformatting the code in a tool like emacs or eclipse which does syntax coloring and auto indenting. Often, if you're missing some piece of punctuation, it will become obvious when your tool tries to indent things in some unexpected way. Or suddenly starts coloring all of your program text as if it were a string literal :-) Agreed. Though I've had some odd issues with SciTE in that way; I think its Python handling may have bugs in it here and there. But 95% of the time it's helpful. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Am I not seeing the Error?
On 8/10/2013 10:19 PM, Devyn Collier Johnson wrote:
I am checking my 1292-line script for syntax errors. I ran the following
commands in a terminal to check for errors, but I do not see the error.
collier@Nacho-Laptop:/media/collier/AI/Pysh$ python3 -m py_compile
./beta_engine
File ./beta_engine, line 344
JOB_WRITEURGFILES =
multiprocessing.Process(write2file('./mem/ENGINE_PID', ENGINEPID);
That should be a comma; so should the next semicolon below.
write2file(SENTEMPPATH, ''); write2file(INPUTMEM, ''));
This last one is 'correct', but delete it
JOB_WRITEURGFILES.start()
and put this statement on a line by itself.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
Thanks Tim, This takes me to one more question. 'is' operator is used to compare objects and it should not be used to compare data. So can it be compared with 'False'. i.e. Is this code possible if a is False: print 'Yes' if b is False: print 'No' Because i recommended this should not be done. But my colleagues say it is correct. Regards, Krishnan On Sat, Aug 10, 2013 at 10:10 PM, Tim Chase python.l...@tim.thechases.comwrote: On 2013-08-10 21:03, Krishnan Shankar wrote: a=10 id(a) 21665504 b=a id(b) 21665504 c=10 id(c) 21665504 I am actually assigning new value to c. But from the value of id() all three variables take same location. With variables a and b it is ok. But why c taking the same location? As an internal optimization, CPython caches small integer values a = 256 b = 256 a is b True a = 257 b = 257 a is b False Because it's an internal implementation detail, you shouldn't count on this behavior (Jython or Cython or IronPython may differ; or future versions of Python may cache a different range of numbers). Generally, if you are using the is operator to compare against anything other than None, you're doing it wrong. There are exceptions to this, but it takes knowing the particulars. -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sun, Aug 11, 2013 at 4:09 AM, Krishnan Shankar i.am.song...@gmail.com wrote: i.e. Is this code possible if a is False: print 'Yes' if b is False: print 'No' You would use that if you want to check if a/b is the exact bool value False. Normally you would simply spell it thus: if not a: print 'Yes' if not b: print 'No' which will accept any value and interpret it as either empty (false) or non-empty (true). Using the equality operator here adds another level of potential confusion: 0 == False True [] == False False 0.0 == False True () == False False whereas if you use the normal boolean conversion, those ARE all false: bool(0) False bool([]) False bool(0.0) False bool(()) False ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 08/10/2013 08:09 PM, Krishnan Shankar wrote:
Thanks Tim,
This takes me to one more question.
'is' operator is used to compare objects and it should not be used to
compare data.
So can it be compared with 'False'.
i.e. Is this code possible
if a is False:
print 'Yes'
if b is False:
print 'No'
Depends on what you want. If you want to differentiate between a value
of False, and other false-like values 0, (), [], {} and so on, then you
need to be explicit with
if a is False:
Normally, that's not what you want, so you use
if not a:
to catch any of those false-like values.
Because i recommended this should not be done. But my colleagues say
it is correct.
Regards,
Krishnan
On Sat, Aug 10, 2013 at 10:10 PM, Tim Chase
python.l...@tim.thechases.com mailto:python.l...@tim.thechases.com
wrote:
On 2013-08-10 21:03, Krishnan Shankar wrote:
a=10
id(a)
21665504
b=a
id(b)
21665504
c=10
id(c)
21665504
I am actually assigning new value to c. But from the value of id()
all three variables take same location. With variables a and b it
is ok. But why c taking the same location?
As an internal optimization, CPython caches small integer values
a = 256
b = 256
a is b
True
a = 257
b = 257
a is b
False
Because it's an internal implementation detail, you shouldn't count
on this behavior (Jython or Cython or IronPython may differ; or
future versions of Python may cache a different range of numbers).
Generally, if you are using the is operator to compare against
anything other than None, you're doing it wrong. There are exceptions
to this, but it takes knowing the particulars.
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 08/10/2013 06:00 PM, Chris Angelico wrote: On Sun, Aug 11, 2013 at 1:42 AM, Gary Herron gary.her...@islandtraining.com wrote: On 08/10/2013 03:09 PM, Chris Angelico wrote: _notpassed = object() def frob(appendage, device=_notpassed): Use some appendage to frob some device, or None to frob nothing. Omit device to frob whatever is currently held in that appendage if device is _notpassed: device = ... # whatever you need if device is not None: # frob the device But granted, equality comparisons are a LOT more common than identity comparisons. ChrisA Everything you say is true, and even reasonable for those who know what's up. But for each of your examples, using == is equivalent to using is. Each of if something == None if device == _not passed if device != None would all work as expected. In none of those cases is is actually needed. Wrong. If you do equality comparisons, it's entirely possible for something to be passed in that compares equal to the RHS without actually being it, so is is precisely what's wanted. (Plus, why go through a potentially expensive comparison check when you can simply check object identity - which could be, for instance, an address check? But performance is a distant second to correctness here.) You're missing my point. Our knee-jerk reaction to beginners using is should be: Don't do that! You almost certainly want ==. Consider is an advanced topic. Then you can spend as much time as you want trying to coach them into an understanding of the precise details. But until they have that understanding, they are well served by a rule-of-thumb that says: Use == not is for comparisons. Given that, and the implementation dependent oddities, I still believe that it is *highly* misleading to teach a beginner about is. Here's a challenge: What is the simplest non-contrived example where an is comparison is *required*. Where substitution of an == comparison would cause the program to fail or be significantly less efficient? (I'm not including the nearly immeasurably small timing difference between v==None and v is None.) All it takes is a slightly odd or buggy __eq__ implementation and the == versions will misbehave. To check if an argument is something, you use is, not ==. No, sorry, but any use of the word is in an English sentence is way too ambiguous to specify a correct translation into code. To check if a calculation of some value is a million, you'd write value == 100 not value is 100 even though there are plenty of other examples where is would be correct. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 08/10/2013 09:09 PM, Krishnan Shankar wrote: i.e. Is this code possible if a is False: print 'Yes' if b is False: print 'No' Because i recommended this should not be done. But my colleagues say it is correct. You are probably correct in your believe that this idiom should be avoided. As Chris says, it's much more pythonic to just use if not a. There is one case where the recommended idiom is to use the 'is' operator. That's when you want an empty list as a default parameter to a function. Since lists are mutable, often times using [] as a default parameter is the wrong thing to do. This is the recommended idiom: def my_func(mylist = None): if mylist is None: mylist = [] -- http://mail.python.org/mailman/listinfo/python-list
Elegant compare
class my_class: def __init__(self, attr1, attr2): self.attr1 = attr1 #string self.attr2 = attr2 #string def __lt__(self, other): if self.attr1 other.attr1: return True else: return self.attr2 other.attr2 I will run into problems if attr1 or attr2 is None, and they legitimately can be. I know I can check for attr1 or attr2 or both being None and react accordingly, but my real class has ten attributes and that approach will be long. What are my alternatives? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sun, Aug 11, 2013 at 4:21 AM, Gary Herron gary.her...@islandtraining.com wrote: On 08/10/2013 06:00 PM, Chris Angelico wrote: Wrong. If you do equality comparisons, it's entirely possible for something to be passed in that compares equal to the RHS without actually being it, so is is precisely what's wanted. (Plus, why go through a potentially expensive comparison check when you can simply check object identity - which could be, for instance, an address check? But performance is a distant second to correctness here.) You're missing my point. Our knee-jerk reaction to beginners using is should be: Don't do that! You almost certainly want ==. Consider is an advanced topic. Then you can spend as much time as you want trying to coach them into an understanding of the precise details. But until they have that understanding, they are well served by a rule-of-thumb that says: Use == not is for comparisons. No, I'm not missing your point; I'm disagreeing with it. I think that 'is' should be taught, that it is every bit as important as '=='; you're walking down the path of GOTO considered harmful, of decrying some particular language feature because it can be misused. All it takes is a slightly odd or buggy __eq__ implementation and the == versions will misbehave. To check if an argument is something, you use is, not ==. No, sorry, but any use of the word is in an English sentence is way too ambiguous to specify a correct translation into code. To check if a calculation of some value is a million, you'd write value == 100 not value is 100 even though there are plenty of other examples where is would be correct. Granted, English is a poor litmus test for code. But in this particular example, we're talking about immutable types (simple integers), where value and identity are practically the same. A Python implementation would be perfectly justified in interning *every* integer, in which case the 'is' would work perfectly here. The distinction between the two is important when the objects are mutable (so they have an identity that's distinct from their current values). ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Elegant compare
On Sun, Aug 11, 2013 at 4:41 AM, Jason Friedman jsf80...@gmail.com wrote: class my_class: def __init__(self, attr1, attr2): self.attr1 = attr1 #string self.attr2 = attr2 #string def __lt__(self, other): if self.attr1 other.attr1: return True else: return self.attr2 other.attr2 I will run into problems if attr1 or attr2 is None, and they legitimately can be. I know I can check for attr1 or attr2 or both being None and react accordingly, but my real class has ten attributes and that approach will be long. What are my alternatives? The first question is: What should the comparison do with a None value? Should it be considered less than every string? If so, you could simply use: if (self.attr1 or ) (other.attr1 or ): which will treat any falsy value as blank. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 11 August 2013 04:43, Chris Angelico ros...@gmail.com wrote: On Sun, Aug 11, 2013 at 4:21 AM, Gary Herron gary.her...@islandtraining.com wrote: On 08/10/2013 06:00 PM, Chris Angelico wrote: All it takes is a slightly odd or buggy __eq__ implementation and the == versions will misbehave. To check if an argument is something, you use is, not ==. No, sorry, but any use of the word is in an English sentence is way too ambiguous to specify a correct translation into code. To check if a calculation of some value is a million, you'd write value == 100 not value is 100 even though there are plenty of other examples where is would be correct. Granted, English is a poor litmus test for code. But in this particular example, we're talking about immutable types (simple integers), where value and identity are practically the same. A Python implementation would be perfectly justified in interning *every* integer, in which case the 'is' would work perfectly here. The distinction between the two is important when the objects are mutable (so they have an identity that's distinct from their current values). I don't follow this argument. Tuples are immutable yet you're crazy if you check their equality with is. In Python identity and equality are very distinct. I follow (and agree) with the other arguments: is is useful and should be used. It's just this part in particular sounds off. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 08/10/2013 08:43 PM, Chris Angelico wrote: On Sun, Aug 11, 2013 at 4:21 AM, Gary Herron gary.her...@islandtraining.com wrote: On 08/10/2013 06:00 PM, Chris Angelico wrote: Wrong. If you do equality comparisons, it's entirely possible for something to be passed in that compares equal to the RHS without actually being it, so is is precisely what's wanted. (Plus, why go through a potentially expensive comparison check when you can simply check object identity - which could be, for instance, an address check? But performance is a distant second to correctness here.) You're missing my point. Our knee-jerk reaction to beginners using is should be: Don't do that! You almost certainly want ==. Consider is an advanced topic. Then you can spend as much time as you want trying to coach them into an understanding of the precise details. But until they have that understanding, they are well served by a rule-of-thumb that says: Use == not is for comparisons. No, I'm not missing your point; I'm disagreeing with it. I think that 'is' should be taught, that it is every bit as important as '=='; you're walking down the path of GOTO considered harmful, of decrying some particular language feature because it can be misused. // I agree that both == and is must be taught. But it's the order in which things are introduced which I'm quibbling about. Something like this makes sense (to me): Lesson 1: Use == for comparisons, save is for a more advanced lesson. Lesson 2: Use is for singleton types like if a is None: and other easily defined circumstances. Lesson 3: The whole truth, accompanied by a whole chapter's worth of material that describes Python's data model and the difference between value versus identity and assignment versus binding ... A beginner, on his first program or two, can understand 1, and perhaps parrot 2 without understanding (or needing to). But the step from there to 3 is huge. It's folly to dump that on a first-time programmer. (It's probably even folly to dump that on a seasoned programmer just starting in Python. I still remember not understanding the explanation for is when I first read it. And it continued to make no sense until I had enough experience to understand the difference betwen C/C++ assignment to variables and Python's binding of variables.) All it takes is a slightly odd or buggy __eq__ implementation and the == versions will misbehave. To check if an argument is something, you use is, not ==. No, sorry, but any use of the word is in an English sentence is way too ambiguous to specify a correct translation into code. To check if a calculation of some value is a million, you'd write value == 100 not value is 100 even though there are plenty of other examples where is would be correct. Granted, English is a poor litmus test for code. But in this particular example, we're talking about immutable types (simple integers), where value and identity are practically the same. A Python implementation would be perfectly justified in interning *every* integer, in which case the 'is' would work perfectly here. The distinction between the two is important when the objects are mutable (so they have an identity that's distinct from their current values). Granted. But please note: There is *nothing* in that sentence which is fit for a beginner programmer. ... immutable, value/identity, interning ... In one ear and out the other. :-) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sun, Aug 11, 2013 at 5:04 AM, Joshua Landau jos...@landau.ws wrote: On 11 August 2013 04:43, Chris Angelico ros...@gmail.com wrote: The distinction between the two is important when the objects are mutable (so they have an identity that's distinct from their current values). I don't follow this argument. Tuples are immutable yet you're crazy if you check their equality with is. In Python identity and equality are very distinct. True, it's not strictly an issue of mutability of that one level. But anything that's truly immutable (a tuple/frozenset of ints/strings) can in theory be interned. In some languages (no Pythons as far as I'm aware, though one could easily do so and still be fully compliant), all strings are automatically interned, so there's no difference between value and identity for them. A tuple containing a list, for instance, needs its identity; a tuple of three integers is identifiable entirely by its value. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sun, Aug 11, 2013 at 5:29 AM, Gary Herron gary.her...@islandtraining.com wrote: A beginner, on his first program or two, can understand 1, and perhaps parrot 2 without understanding (or needing to). But the step from there to 3 is huge. It's folly to dump that on a first-time programmer. (It's probably even folly to dump that on a seasoned programmer just starting in Python. I still remember not understanding the explanation for is when I first read it. And it continued to make no sense until I had enough experience to understand the difference betwen C/C++ assignment to variables and Python's binding of variables.) See, that's where the problem is. You will never grok the difference between == and is if you're still thinking about C variables. (Though you *might* be able to explain it by talking solely about char* and the way two C strings can be the same but stored at different places in memory. But that would be unhelpful most of the time.) This is important *early* reading for a new Python programmer: http://mail.python.org/pipermail/tutor/2010-December/080505.html Note that it was originally posted on python-tutor, so it was definitely aimed at the inexperienced. On 08/10/2013 08:43 PM, Chris Angelico wrote: Granted, English is a poor litmus test for code. But in this particular example, we're talking about immutable types (simple integers), where value and identity are practically the same. A Python implementation would be perfectly justified in interning *every* integer, in which case the 'is' would work perfectly here. The distinction between the two is important when the objects are mutable (so they have an identity that's distinct from their current values). Granted. But please note: There is *nothing* in that sentence which is fit for a beginner programmer. ... immutable, value/identity, interning ... In one ear and out the other. :-) Right. This isn't my explanation of 'is' and '=='; it's my explanation of why it's important to HAVE an explanation of the aforementioned. :) Though the difference between value and identity is significant and important, and mutability is bound to crop up fairly early on; so really, it's only the concept of interning that would be really advanced. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Paramiko Help. Execute command to Interactive Shell which is opened by SSHClient()
On Thursday, August 8, 2013 12:50:25 PM UTC+5:30, sagar varule wrote: Hi All, Im using Paramiko for my SSH automation. Im using method that is shown in demo_simple.py example which comes with Paramiko. Below is code from demo_simple.py. As you can make out, below code opens SSH connection and opens Interactie Shell, and then wait for the command from user. I want to submit the command to this Interactive Shell using code. try: client = paramiko.SSHClient() client.load_system_host_keys() client.set_missing_host_key_policy(paramiko.WarningPolicy()) print '*** Connecting...' client.connect(hostname, port, username, password) chan = client.invoke_shell() print repr(client.get_transport()) print '*** Here we go!' print interactive.interactive_shell(chan) chan.close() client.close() Well Another approach I tried is instead of opening interactive_shell, directly issue command using; stdin, stdout, stderr = client.exec_command(bv_cmd) for line in stderr.readlines(): print line for line in stdout.readlines(): print line But problem here is client.exec_command(bv_cmd) waits for command to execute completely and then it returns to stdout,stderr. And I want to see the ouput from the command during its execution. Because my command takes long time for execution. Big Picture in My Mind: Big Picture I that want to achieve is, Opening different SSH connection to different host, and it will issue commands to all host, wait for execution. All execution should happen parallel.(just wanted to share my thought, and wanted to hear opinions from you all. Is this possible??). I am not big programmer, just 2 years experience with asp.net C# 2.0 so i would appreciate if discussion happens in simple english. Can any one comment on this.. -- http://mail.python.org/mailman/listinfo/python-list
[issue18647] re.error: nothing to repeat
Armin Rigo added the comment: Just a side note for 2.7: could I recommend people to be really extra, extra careful when changing what kind of regexps are accepted and what kind of regexps are outright rejected? I believe the risk of making long-existing and working 2.7 programs suddenly crash on the next 2.7 micro version should *by far* outweight the theoretical advantage of crashing early on sufficiently bogus regexps. (Fwiw, I believe the same would apply on 3.x too, where rejecting previously-accepted regexps should only be done in a minor version upgrade.) -- nosy: +arigo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18647 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Stefan Behnel added the comment: I gave the implementation a try and attached an incomplete patch. Some tests are failing. It turns out that it's not entirely easy to do this. As Antoine noticed, the hack in the C implementation of the TreeBuilder makes it tricky to integrate with other targets, specifically when intercepting events that the tree builder needs . That's a more general bug and it currently gets in the way. Anyway, here's how it should eventually look like. -- Added file: http://bugs.python.org/file31211/iterparse_TreeEventBuilder.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18647] re.error: nothing to repeat
Serhiy Storchaka added the comment:
Serhiy, yup, that regexp is slow, but it does finish - so the engine is doing
something to avoid _unbounded_ repetitive matching of an empty string.
Yes, it finish, but it has exponential computation complexity. Increase the
length of the string to 21, 22, 30, 100...
There were multiple bug reports about hanged regexps which actually had
quadratic or exponential computation complexity (see for example issue1662581,
issue16430, issue15077, issue15515). In all such cases the regexp can be
rewritten to have linear computation complexity. However peoples constantly do
such mistakes.
Armin, I totally agree with you.
Note that before b78c321ee9a5 the regexp '(?:.{0,6}.{0,5535})?' was
forbidden while '(?:.{0,6}.{0,5534})?' and '(?:.{0,6}.{0,5536})?' were
allowed. Existing check allowed false positives.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18647
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18695] os.statvfs() not working well with unicode paths
Serhiy Storchaka added the comment: 2.7.x is a minor version, not 2.7. We fixed Unicode issues in Python 2 bugfixes many times. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18695 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18701] Remove outdated PY_VERSION_HEX checks
New submission from Serhiy Storchaka: Here is a patch which removes PY_VERSION_HEX checks in Modules/_ctypes/_ctypes.c, Modules/_sre.c, Objects/stringlib/unicodedefs.h and removes the Modules/_sqlite/sqlitecompat.h file. _sre.c checks support Python versions 2.2, 2.2 or 1.6 which doesn't made sense because the code overall uses Unicode object API available only in Python =3.3. unicodedefs.h contains code to support Python 3.0, but stringlib code can't be shared with Python 3.3. _ctypes.c and sqlitecompat.h contain code to support Python 2.5 which is not supported version. -- assignee: serhiy.storchaka components: Extension Modules, Interpreter Core files: no_version_checks.patch keywords: patch messages: 194789 nosy: amaury.forgeotdarc, belopolsky, benjamin.peterson, ezio.melotti, ghaering, haypo, lemburg, meador.inge, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Remove outdated PY_VERSION_HEX checks type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file31212/no_version_checks.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18701 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18702] Report skipped tests as skipped
New submission from Serhiy Storchaka: Some tests in Python testsuite are silently skipped if requirements is not satisfied. The proposed patch adds explicit skipUnless() and raise SkipTest() so that these tests now reported as skipped. I.e. the code like if not condition: def test_foo(self): ... is replaced by @unittest.skipUnless(condition, requires foo) def test_foo(self): ... and the code like def test_foo(self): ... if not condition: return ... is replaced by def test_foo(self): ... if not condition: raise unittest.SkipTest(requires foo) ... -- components: Tests files: skip_tests.patch keywords: patch messages: 194790 nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Report skipped tests as skipped type: enhancement versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file31213/skip_tests.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18702 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18268] ElementTree.fromstring non-deterministically gives unicode text data
Changes by Eli Bendersky eli...@gmail.com: -- resolution: - invalid stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18268 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18668] Properly document setting m_size in PyModuleDef
Roundup Robot added the comment: New changeset f55ba27776d4 by Eli Bendersky in branch '3.3': Issue #18668: Further clarify m_size setting for non-negative values http://hg.python.org/cpython/rev/f55ba27776d4 New changeset d43435e82e21 by Eli Bendersky in branch 'default': Issue #18668: Further clarify m_size setting for non-negative values http://hg.python.org/cpython/rev/d43435e82e21 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18668 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18418] Thread.isAlive() sometimes True after fork
A. Jesse Jiryu Davis added the comment: Bump. I think my most recent patch (August 4) addresses all of Charles-François's comments. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17909] Autodetecting JSON encoding
Changes by Serhiy Storchaka storch...@gmail.com: -- stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17909 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16400] update default PyPI behavior in docs re: listing versions
Roundup Robot added the comment: New changeset dd0d751cc7f1 by Christian Heimes in branch 'default': Issue #16400: Add command line option for isolated mode. http://hg.python.org/cpython/rev/dd0d751cc7f1 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16400 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8713] multiprocessing needs option to eschew fork() under Linux
Changes by Richard Oudkerk shibt...@gmail.com: Added file: http://bugs.python.org/file31214/c7aa0005f231.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16499] CLI option for isolated mode
Roundup Robot added the comment: New changeset 06c39789061e by Christian Heimes in branch 'default': typo, changeset dd0d751cc7f1 belongs to issue #16499 not issue #16400 http://hg.python.org/cpython/rev/06c39789061e -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16499 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16400] update default PyPI behavior in docs re: listing versions
Roundup Robot added the comment: New changeset 06c39789061e by Christian Heimes in branch 'default': typo, changeset dd0d751cc7f1 belongs to issue #16499 not issue #16400 http://hg.python.org/cpython/rev/06c39789061e -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16400 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8713] multiprocessing needs option to eschew fork() under Linux
Richard Oudkerk added the comment: The forkserver process is now started using _posixsubprocess.fork_exec(). This should fix the order dependent problem mentioned before. Also the forkserver tests are now reenabled on OSX. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16499] CLI option for isolated mode
Changes by Christian Heimes li...@cheimes.de: -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16499 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18504] IDLE:Improvements- Improving Mock_Text
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti stage: test needed - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15651] PEP 3121, 384 refactoring applied to elementtree module
Roundup Robot added the comment: New changeset 8a060e2de608 by Eli Bendersky in branch 'default': Issue #15651: PEP 3121 refactoring for _elementtree http://hg.python.org/cpython/rev/8a060e2de608 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15651 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15651] PEP 3121, 384 refactoring applied to elementtree module
Eli Bendersky added the comment: Antoine, I committed your patch (with a bit of comments added), *leaving the module caching in*. This is because removing it breaks the tests, unfortunately. The _elementtree tests are so crooked that they manage to create a situation in which the module under test throws ParseError which is a different class from ET.ParseError. This is achieved by multiple invocations of import_fresh_module with various fresh blocked parameters, and I still haven't fully traced all the problems yet. Since this caching only potentially harms other tests, it's ok to leave in. A longer term solution to all this will be http://mail.python.org/pipermail/python-dev/2013-August/127766.html - I want to eventually run all monkey-patch the import environment to simulate some situation sub-tests of ET in different subprocesses to they are kept independent. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15651 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18483] Add hour-24 type of time to test_http2time_formats in test_http_cookiejar.py
Roundup Robot added the comment: New changeset ab8da1936297 by Ezio Melotti in branch '3.3': #18483: add one more date format in test_http2time_formats. Patch by Vajrasky Kok. http://hg.python.org/cpython/rev/ab8da1936297 New changeset 5c3708f23351 by Ezio Melotti in branch 'default': #18483: merge with 3.3. http://hg.python.org/cpython/rev/5c3708f23351 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18483] Add hour-24 type of time to test_http2time_formats in test_http_cookiejar.py
Ezio Melotti added the comment: Fixed, thanks for the report and the patch! -- assignee: - ezio.melotti nosy: +ezio.melotti resolution: - fixed stage: - committed/rejected status: open - closed type: - enhancement versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18484] No unit test for iso2time function from http.cookiejar module
Roundup Robot added the comment: New changeset fe5d105eba4b by Ezio Melotti in branch '3.3': #18484: improve test coverage of http.cookiejar. Patch by Vajrasky Kok. http://hg.python.org/cpython/rev/fe5d105eba4b New changeset 7bf1f8892df5 by Ezio Melotti in branch 'default': #18484: merge with 3.3. http://hg.python.org/cpython/rev/7bf1f8892df5 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18484] No unit test for iso2time function from http.cookiejar module
Ezio Melotti added the comment: Fixed, thanks for the patch! -- assignee: - ezio.melotti nosy: +ezio.melotti resolution: - fixed stage: patch review - committed/rejected status: open - closed type: - enhancement versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18466] Spelling mistakes in various code comments.
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18465] There are unused variables and unused import in Lib/test/test_minidom.py
Roundup Robot added the comment: New changeset 4daa18b5ad49 by Ezio Melotti in branch '3.3': #18465: fix unused variables in test_minidom. Patch by Vajrasky Kok. http://hg.python.org/cpython/rev/4daa18b5ad49 New changeset 47770b408321 by Ezio Melotti in branch 'default': #18465: merge with 3.3. http://hg.python.org/cpython/rev/47770b408321 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18465 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18465] There are unused variables and unused import in Lib/test/test_minidom.py
Ezio Melotti added the comment: Fixed, thanks for the report and the patch! -- assignee: - ezio.melotti nosy: +ezio.melotti resolution: - fixed stage: - committed/rejected status: open - closed type: - enhancement versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18465 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18453] There are unused variables inside DateTimeTestCase class in test_xmlrpc.py
Roundup Robot added the comment: New changeset 28c756093a63 by Ezio Melotti in branch '3.3': #18453: fix unused variables in test_xmlrpc. Patch by Vajrasky Kok. http://hg.python.org/cpython/rev/28c756093a63 New changeset 9f7581816890 by Ezio Melotti in branch 'default': #18453: merge with 3.3. http://hg.python.org/cpython/rev/9f7581816890 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18453 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18453] There are unused variables inside DateTimeTestCase class in test_xmlrpc.py
Ezio Melotti added the comment: Fixed, thanks for the report and the patch! -- assignee: - ezio.melotti nosy: +ezio.melotti resolution: - fixed stage: - committed/rejected status: open - closed type: - enhancement versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18453 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18516] Typos in Lib/email/generator.py and Lib/email/architecture.rst
Ezio Melotti added the comment: Fixed in 168f6ac90abf (3.3) and 40ef5ce25d08 (default). Thanks for the report! -- assignee: docs@python - ezio.melotti nosy: +ezio.melotti resolution: - fixed stage: - committed/rejected status: open - closed type: - enhancement versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18516 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18512] sys.stdout.write does not allow bytes in Python 3.x
Ezio Melotti added the comment: You can do sys.stdout.buffer.write(bhello) Note that this might not work when sys.stdout has been replaced with something else (e.g. a StringIO). -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18512 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18667] missing HAVE_FCHOWNAT
Larry Hastings added the comment: Here's a patch for trunk. It's essentially what salinger wrote, but as a patch file so it works for review. I poked around a little to make sure we weren't going to have another baffling situation like fchmodat. AFAICT, nope, it's fine, it's as simple as the four-line patch before. -- Added file: http://bugs.python.org/file31215/larry.have_fchownat.trunk.patch.1.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18667 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18667] missing HAVE_FCHOWNAT
Larry Hastings added the comment: And here's a patch for 3.3. I should have mentioned--both these patches pass the same tests as an unmodified trunk. So I think it's just ready to go in. -- Added file: http://bugs.python.org/file31216/larry.have_fchownat.3.3.patch.1.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18667 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18505] Duplicate function names in test_email.py
Roundup Robot added the comment: New changeset 53d54503fc06 by Ezio Melotti in branch '3.3': #18505: fix duplicate name and remove duplicate test. Patch by Vajrasky Kok. http://hg.python.org/cpython/rev/53d54503fc06 New changeset cb0fba5c7828 by Ezio Melotti in branch 'default': #18505: merge with 3.3. http://hg.python.org/cpython/rev/cb0fba5c7828 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18505 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18505] Duplicate function names in test_email.py
Ezio Melotti added the comment: Fixed, thanks for the report and the patch! -- assignee: - ezio.melotti nosy: +ezio.melotti resolution: - fixed stage: - committed/rejected status: open - closed type: - enhancement versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18505 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18696] In unittest.TestCase.longMessage doc remove a redundant sentence
Ezio Melotti added the comment: Agreed, closing. -- nosy: +ezio.melotti resolution: - invalid stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18696 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings
Tim Golden added the comment: I attach a patch against 3.3; this is substantially Dave Chambers' original patch with a trivial test added and a doc change. This means that HKCR is scanned to determine extensions and these will override anything in the mimetypes db. The doc change highlights the possibility of overriding this by passing files=[]. I can't see an easy solution for this which will suit everyone but I've sat on it waay too long already. The module startup time is increased but, for bugfix releases, I can't see any other solution which won't break compatibility somewhere. I'm taking the simplest view which says that: .jpg = image/pjpeg is broken but that the winreg code has been in place for too long to simply back it out altogether. I'll commit appropriate versions of this within the next day to 2.7, 3.3 and 3.4 unless anyone objects. Please understand: this *is* a compromise; but I don't think there's a perfect solution for this, short of the rethink which mimetypes needs per MALs suggestion or otherwise. -- Added file: http://bugs.python.org/file31217/issue15207.33.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15207 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0) deprecated function inspect.getargspec()
Roundup Robot added the comment: New changeset bc49e82ee013 by R David Murray in branch '3.3': #8112: Update the documenting xmlrpc server to use getfullargspec. http://hg.python.org/cpython/rev/bc49e82ee013 New changeset 69e515209fa9 by R David Murray in branch 'default': Merge #8112: Update the documenting xmlrpc server to use getfullargspec. http://hg.python.org/cpython/rev/69e515209fa9 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0) deprecated function inspect.getargspec()
R. David Murray added the comment: Thanks, Claudio. -- resolution: - fixed stage: test needed - committed/rejected status: open - closed versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0) deprecated function inspect.getargspec()
Changes by R. David Murray rdmur...@bitdance.com: -- Removed message: http://bugs.python.org/msg194816 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
