Re: Python and the need for speed
On Tue, Apr 11, 2017 at 8:08 PM, Steve D'Aprano wrote: > Comprehensions may have been around for a decade or two in Haskell, but most > older languages don't have them. I'm pretty sure Java doesn't. Java does not have comprehensions per se, but the Streams API introduced in Java 8 is similar in concept and also much more powerful -- for example, streams can be executed either serially or in parallel, which is not a feature of any list comprehension I've ever seen. https://docs.oracle.com/javase/8/docs/api/java/util/stream/package-summary.html > Does > Javascript? Comprehensions feel like a fancy new language feature to me. ES6 was going to include array comprehensions and generator comprehensions but these didn't make it into the final version. My understanding is that they were deferred because the committee hoped to come up with something more LINQ-like, which I think is also greatly motivated by parallelism concerns. -- https://mail.python.org/mailman/listinfo/python-list
CPython Class variable exposed to Python is altered.
Hi,
Learning CPython, I've made this simple exercice, a module test which
contains an object Test.
The object Test has an attribute name, fixed at instanciation.
So, I try my code with a script:
---
from test import Test
for n in ("The name", "Foo", "Spam"):
t = Test(n)
print("%s --> %s" %(n, t.name))
---
And the return:
Uhe name --> Uhe name
Goo --> Goo
Tpam --> Tpam
As we can see, the first letter is changed with the next letter in
alphabetical order, but not only for the attribute name, also for the
reference n.
Same into a console:
(py352_venv) vincent@djoliba:~/CPython/py352_venv/pydcraw$ python
Python 3.5.2 (default, Dec 19 2016, 11:46:33)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from test import Test
>>> for n in ("The name", "Foo", "Spam"):
... t = Test(n)
... print("%s --> %s" %(n, t.name))
...
Uhe name --> Uhe name
Goo --> Goo
Tpam --> Tpam
I'm working in a venv.
The testmodule.c is attached.
The setup.py
from distutils.core import setup, Extension
setup(name="test", version="1.0",
ext_modules=[
Extension("test", ["testmodule.c"],
libraries=[])
])
Best,
Vincent
--
https://mail.python.org/mailman/listinfo/python-list
Re: CPython Class variable exposed to Python is altered.
Le 12/04/17 à 08:57, Vincent Vande Vyvre a écrit :
Hi,
Learning CPython, I've made this simple exercice, a module test which
contains an object Test.
The object Test has an attribute name, fixed at instanciation.
So, I try my code with a script:
---
from test import Test
for n in ("The name", "Foo", "Spam"):
t = Test(n)
print("%s --> %s" %(n, t.name))
---
And the return:
Uhe name --> Uhe name
Goo --> Goo
Tpam --> Tpam
As we can see, the first letter is changed with the next letter in
alphabetical order, but not only for the attribute name, also for the
reference n.
Same into a console:
(py352_venv) vincent@djoliba:~/CPython/py352_venv/pydcraw$ python
Python 3.5.2 (default, Dec 19 2016, 11:46:33)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from test import Test
>>> for n in ("The name", "Foo", "Spam"):
... t = Test(n)
... print("%s --> %s" %(n, t.name))
...
Uhe name --> Uhe name
Goo --> Goo
Tpam --> Tpam
I'm working in a venv.
The testmodule.c is attached.
The setup.py
from distutils.core import setup, Extension
setup(name="test", version="1.0",
ext_modules=[
Extension("test", ["testmodule.c"],
libraries=[])
])
Best,
Vincent
I see the attachement is rejected.
This is the testmodule.c
---
#include
#include "structmember.h"
typedef struct {
PyObject_HEAD
PyObject *name;
} Test;
static void
Test_dealloc(Test* self)
{
Py_XDECREF(self->name);
}
static PyObject *
Test_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
{
Test *self;
self = (Test *)type->tp_alloc(type, 0);
if (self != NULL){
self->name = PyUnicode_FromString("");
if (self->name == NULL){
Py_DECREF(self);
return NULL;
}
}
return (PyObject *)self;
}
static int
Test_init(Test *self, PyObject *args, PyObject *kwds)
{
PyObject *name, *tmp;
static char *kwlist[] = {"name", NULL};
if (!PyArg_ParseTupleAndKeywords(args, kwds, "s|", kwlist, &name))
return -1;
if (name) {
tmp = self->name;
Py_INCREF(name);
self->name = name;
Py_XDECREF(tmp);
}
return 0;
}
static PyMemberDef Test_members[] = {
{"name", T_STRING, offsetof(Test, name), 0,
"The object name"},
{NULL} /* Sentinel */
};
static PyMethodDef Test_methods[] = {
{NULL} /* sentinel */
};
static PyTypeObject TestType = {
PyVarObject_HEAD_INIT(NULL, 0)
"test.Test", /* tp_name */
sizeof(Test), /* tp_basicsize */
0,/* tp_itemsize */
(destructor)Test_dealloc, /* tp_dealloc */
0,/* tp_print */
0,/* tp_getattr */
0,/* tp_setattr */
0,/* tp_reserved */
0,/* tp_repr */
0,/* tp_as_number */
0,/* tp_as_sequence */
0,/* tp_as_mapping */
0,/* tp_hash */
0,/* tp_call */
0,/* tp_str */
0,/* tp_getattro */
0,/* tp_setattro */
0,/* tp_as_buffer */
Py_TPFLAGS_DEFAULT |
Py_TPFLAGS_BASETYPE, /* tp_flags */
"Test object",/* tp_doc */
0,/* tp_traverse */
0,/* tp_clear */
0,/* tp_richcompare */
0,/* tp_weaklistoffset */
0,/* tp_iter */
0,/* tp_iternext */
Test_methods, /* tp_methods */
Test_members, /* tp_members */
0,/* tp_getset */
0,/* tp_base */
0,/* tp_dict */
0,/* tp_descr_get */
0,/* tp_descr_set */
0,/* tp_dictoffset */
(initproc)Test_init, /* tp_init */
0,/* tp_alloc */
Test_new, /* tp_new */
};
static PyModuleDef testmodule = {
PyModuleDef_HEAD_INIT,
"test",
"Example module.",
-1,
NULL, NULL, NULL, NULL, NULL
};
PyMODINIT_FUNC
PyInit_test(void)
{
PyObject* m;
if (PyType_Ready(&TestType) < 0)
return NULL;
m = PyModule_Create(&testmodule);
if (m == NULL)
return NULL;
P
Re: Inclusion of of python and python libraries licensed with BSD- 3 clause license in proprietary software
On Wednesday, 12 April 2017 07:12:27 UTC+5:30, Steve D'Aprano wrote: > On Wed, 12 Apr 2017 06:35 am, Abhishek Kumar wrote: > > > Hello, > > > > I tried finding the answer but even the lawyers in my town have no idea > > Where is your town? > > > > about it and searching the web leaved me puzzled. > > What have you tried? > > The first few links found here: > > https://duckduckgo.com/?q=BSD-3+licence+faqs > > > seem pretty easy to understand. It's a very short and simple licence, > precisely because it puts very few requirements on you. If you are using > Library X (which is under the BSD-3 licence) then all you need do to meet > the licence requirements is to include Library X's copyright notice and > licence. You don't have to provide the source code to Library X, or to your > own application. > > > > I am planning to make a software in python which will include libraries > > licensed under BSD- 3 clause. Can I sell this software under proprietary > > license > > Yes. > > > > and legally inhibit redistribution by users under my own license. > > Yes. > > > > Also if you know anyone who holds knowledge in this field then please do > > let me know.. Your response will be really helpful. > > > > Regards, > > Abhishek Kumar > > ᐧ > > -- > Steve > “Cheer up,” they said, “things could be worse.” So I cheered up, and sure > enough, things got worse. Hello, I'm living in Pune(India) the lawyers keep on giving different answers some yes you can distribute the software under proprietary license and restrict users from ditributing it in any form while other negate it.. A tried googling and like the lawyers got different answers.. So I posted in stack exchange here is the the link : http://opensource.stackexchange.com/questions/5361/use-of-bsd-3-clause-license-and-python-software-license-for-proprietary-use? I hope you have an experience(legal) in software license Also if you know some one who holds a knowledge in software licenses then please do let me know.. Regards, Abhishek -- https://mail.python.org/mailman/listinfo/python-list
What is the difference between x[:]=y and x=y[:]?
I have a list of list and like to expand each "list element" by appending a 1 and a 0 to it. For example, from "lr = [[1], [0]]" expand to "lr = [[1,1], [0,1], [1,0], [0,0]]". The following won't work: Python 3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 19:28:18) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> lr = [[1], [0]] >>> lx = [] >>> for i in range(len(lr)): ... lx[:] = lr[i] ... lx.append(0) ... lr[i].append(1) ... lr.append(lx) ... >>> lr [[1, 1], [0, 1], [0, 0], [0, 0]] >>> But the following does: >>> lr = [[1], [0]] >>> lx = [] >>> for i in range(len(lr)): ... lx = lr[i][:] ... lx.append(0) ... lr[i].append(1) ... lr.append(lx) ... >>> lr [[1, 1], [0, 1], [1, 0], [0, 0]] >>> After stepping through the first one manually: >>> lr = [[1], [0]] >>> lx[:] = lr[0] >>> lx.append(0) >>> lx [1, 0] >>> lr[0].append(1) >>> lr [[1, 1], [0]] >>> lr.append(lx) >>> lr [[1, 1], [0], [1, 0]] >>> So far so good... >>> lx[:] = lr[1] >>> lx.append(0) >>> lx [0, 0] >>> lr[1].append(1) >>> lr [[1, 1], [0, 1], [0, 0]] >>> Woops! What's wrong? --Jach Fong -- https://mail.python.org/mailman/listinfo/python-list
Re: What is the difference between x[:]=y and x=y[:]?
On Wed, 12 Apr 2017 01:08:07 -0700, jfong wrote: > I have a list of list and like to expand each "list element" by > appending a 1 and a 0 to it. For example, from "lr = [[1], [0]]" expand > to "lr = [[1,1], [0,1], [1,0], [0,0]]". > > The following won't work: > > Python 3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 19:28:18) [MSC v.1600 32 > bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" > for more information. lr = [[1], [0]] lx = [] for i in range(len(lr)): > ... lx[:] = lr[i] > ... lx.append(0) > ... lr[i].append(1) > ... lr.append(lx) > ... lr > [[1, 1], [0, 1], [0, 0], [0, 0]] > But the following does: > lr = [[1], [0]] lx = [] for i in range(len(lr)): > ... lx = lr[i][:] > ... lx.append(0) > ... lr[i].append(1) > ... lr.append(lx) > ... lr > [[1, 1], [0, 1], [1, 0], [0, 0]] > After stepping through the first one manually: > lr = [[1], [0]] lx[:] = lr[0] lx.append(0) lx > [1, 0] lr[0].append(1) lr > [[1, 1], [0]] lr.append(lx) lr > [[1, 1], [0], [1, 0]] > So far so good... > lx[:] = lr[1] lx.append(0) lx > [0, 0] lr[1].append(1) lr > [[1, 1], [0, 1], [0, 0]] > Woops! What's wrong? > > --Jach Fong 1st never* use range to step through items in a list if you need the index as well as the item use Enumerate a=[[1],[2]] for i,x in enumerate(a): a[i].append(0) print a * like all rules an experienced programmer may find a usage case where it may be broken -- While money doesn't buy love, it puts you in a great bargaining position. -- https://mail.python.org/mailman/listinfo/python-list
Re: What is the difference between x[:]=y and x=y[:]?
jf...@ms4.hinet.net wrote: Assuming both x and y are lists x[:] = y replaces the items in x with the items in y while x = y[:] makes a copy of y and binds that to the name x. In both cases x and y remain different lists, but in only in the second case x is rebound. This becomes relevant when initially there are other names bound to x. Compare: >>> z = x = [1, 2] >>> y = [10, 20, 30] >>> x[:] = y # replace the values, z affected >>> z [10, 20, 30] >>> z = x = [1, 2] >>> y = [10, 20, 30] >>> x = y[:] # rebind. x and z are now different lists >>> z [1, 2] -- https://mail.python.org/mailman/listinfo/python-list
Re: CPython Class variable exposed to Python is altered.
Vincent Vande Vyvre wrote:
> Le 12/04/17 à 08:57, Vincent Vande Vyvre a écrit :
>> Hi,
>>
>> Learning CPython, I've made this simple exercice, a module test which
>> contains an object Test.
>>
>> The object Test has an attribute name, fixed at instanciation.
>>
>> So, I try my code with a script:
>>
>> ---
>> from test import Test
>>
>> for n in ("The name", "Foo", "Spam"):
>> t = Test(n)
>> print("%s --> %s" %(n, t.name))
>> ---
>>
>> And the return:
>>
>> Uhe name --> Uhe name
>> Goo --> Goo
>> Tpam --> Tpam
>>
>> As we can see, the first letter is changed with the next letter in
>> alphabetical order, but not only for the attribute name, also for the
>> reference n.
> if (!PyArg_ParseTupleAndKeywords(args, kwds, "s|", kwlist, &name))
> return -1;
>
> if (name) {
> tmp = self->name;
> Py_INCREF(name);
While I don't know how to do this properly you seem to be applying
Py_INCREF() to a C string rather than a Python string object. C being C you
can cast anything to anything else...
Aren't there any warnings at compile time?
--
https://mail.python.org/mailman/listinfo/python-list
Re: CPython Class variable exposed to Python is altered.
Le 12/04/17 à 10:51, Peter Otten a écrit :
Vincent Vande Vyvre wrote:
Le 12/04/17 à 08:57, Vincent Vande Vyvre a écrit :
Hi,
Learning CPython, I've made this simple exercice, a module test which
contains an object Test.
The object Test has an attribute name, fixed at instanciation.
So, I try my code with a script:
---
from test import Test
for n in ("The name", "Foo", "Spam"):
t = Test(n)
print("%s --> %s" %(n, t.name))
---
And the return:
Uhe name --> Uhe name
Goo --> Goo
Tpam --> Tpam
As we can see, the first letter is changed with the next letter in
alphabetical order, but not only for the attribute name, also for the
reference n.
if (!PyArg_ParseTupleAndKeywords(args, kwds, "s|", kwlist, &name))
return -1;
if (name) {
tmp = self->name;
Py_INCREF(name);
While I don't know how to do this properly you seem to be applying
Py_INCREF() to a C string rather than a Python string object. C being C you
can cast anything to anything else...
Aren't there any warnings at compile time?
No, no warning.
For the truth, this code is copy-pasted from the doc.
https://docs.python.org/3.5//extending/newtypes.html#adding-data-and-methods-to-the-basic-example
Vincent
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Tue, 11 Apr 2017 16:31:16 -0700, Rick Johnson wrote: > On Tuesday, April 11, 2017 at 9:56:45 AM UTC-5, Steve D'Aprano wrote: >> On Tue, 11 Apr 2017 07:56 pm, Brecht Machiels wrote: >> > On 2017-04-11 08:19:31 +, Steven D'Aprano said: >> > >> > I understand that high performance was never a goal in CPython >> > development (and Python language design!), but recent events >> > (DropBox, Google) might help to reconsider that standpoint. >> >> *shrug* It isn't as if high-performance is a requirement for all code. > > But given the choice, no prospective "language shopper" is going to > choose the slower language over a faster language -- at least not from a > pool of similar languages with similar features (no comparing Python to > C, please!). So even if you don't need the speed _today_, you may need > it _tomorrow_. And once you've written a few hundred thousand lines of > code, well, you're committed to the language you chose yesterday. but cost is also a factor , not just cost of the tools but cost in time writing & debugging he software the write. if they can produce a finished product in half the time with a "slower" language the speed may not be important (especially when the application is IO bound & spends 90% of its time idling anyway). if this were not the case then we would all be writing Assembler > >> And it isn't as if Python is in any serious risk of losing popularity. >> No language can expect to be popular forever. Eventually Python will be >> as obsolete as or niche as COBOL, >> Tcl or ABC. But that day is not now. > > But considering (as you pointed out) that Python is 20 years old now, > and has also recently suffered a major community fracturing with the > release of Py3000, that day is getting ever closer. I don't see how > Python can survive when a small core of language devs consistently > ignore the wider community. > > >> > Here's a wild idea: consider Python 3 feature-complete. >> >> I think that will conflict with the many, many people who want Python >> to have more features, and care more about them than speed. > > Python-ideas and Python-dev do not represent the majority of the Python > community. They are out there, right now, writing code and solving > problems. But when Python fails to aid in this endeavor, they will not > come here to complain, no, they will search for a new language. In other > words: they will vote with their feet. -- I realize that command does have its fascination, even under circumstances such as these, but I neither enjoy the idea of command nor am I frightened of it. It simply exists, and I will do whatever logically needs to be done. -- Spock, "The Galileo Seven", stardate 2812.7 -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 2017-04-11 14:56:33 +, Steve D'Aprano said: On Tue, 11 Apr 2017 07:56 pm, Brecht Machiels wrote: Hey! This random, ignorant blogger has feelings too! :-) Hi, and welcome! Sorry, I wasn't *specifically* referring to you, except in the sense that you aren't a compiler expert. That's ok. No offense taken. But I also think that while making Python faster is a good goal to have, it seems that for most people, and most companies, it isn't their priority. That may very well be correct. I have used Python/NumPy extensively for data processing/analysis, and I haven't been disappointed by its performance in that area (so far, at least). However, rinohtype is located in a very different niche and it would greatly benefit a lot from a speed boost. Rendering the Sphinx documentation (311 pages) takes almost 10 minutes on my i7, which is simply too long given the available processing power. And yes, I have spent a lot time profiling and optimizing the code. You're always welcome to demonstrate my incompetence by means of a pull request, of course ;-) I have toyed with the idea of porting rinohtype to JavaScript, for the increased performance (though that is not certain) and the advantage of being able to run in the browser. While it may not be an extreme amount of work to port rinohtype itself using something like RapydScript, the docutils and Sphinx dependencies are not easily replaced. As for moving to a compiled language (Nim or Rust would be interesting choices, IMO), it doesn't make much sense. rinohtype should be easily extendable with new document templates for example. An interpreted language like Python is ideal for that (not to mention it's lovely syntax). The Python ecosystem is actually quite healthy, if you need to speed up code there are lots of solutions, and some of them are even good solutions. There seem to be no solutions for my use case (rinohtype). Have you tried Nuitka? I have, a long time ago, so it's a bit vague. But if it performed marginally better than CPython, I would have remembered. Definitely not enough to warrant having to distribute binaries. Nevertheless, it is interesting to discuss whether or not any of these features will go mainstream or make it into CPython. Indeed! I initially wanted to include the following in the article, but decided it would be too controversial. But now that I've been exposed as an ignorant and naive blogger, I might as well share these thoughts. I have the feeling that a faster Python will never materialise unless the CPython core developers make performance a high priority. I think you are both right and wrong. You are right in the sense that none of the companies exploring Python optimizers have wanted to carry the maintenance burden themselves. Their aim is to prove the concept, then push it back into CPython and have the core devs maintain it. But you're also wrong, in the sense that you're focused on *revolutionary* speed-ups rather than *evolutionary* optimizations. CPython is faster today than it was in version 1.5, despite doing MUCH more. Python continues to shave slow code off and improve performance. No, this isn't likely to make Python ten times faster, but its performance does incrementally increase. I do appreciate the evolutionary speedups of CPython. However, I love Python and it's just a bit frustrating that it's not all that it could be. Python *could* be faster, it's just not moving in that direction. But, it may indeed be I'm just one of the few that think that Python is not fast enough. If that is the case, it of course makes no sense to focus more on performance. However, we don't really know how Python's performance is affecting its popularity. It would be good to have some kind of information about user's motivations for choosing Python or moving away from it. Have any polls been organized in the past to try to find out? I realize that work on CPython (and thus the language itself) is done by unpaid volunteers. But I assume that they also want the language to thrive, and therefore want to cater to the wishes of the userbase at some level. So perhaps the conclusion to this discussion is that we should first try to find out whether performance is an issue for a large part of the community (or possible newcomers). Best regards, Brecht -- https://mail.python.org/mailman/listinfo/python-list
Re: CPython Class variable exposed to Python is altered.
Vincent Vande Vyvre wrote:
> Le 12/04/17 à 10:51, Peter Otten a écrit :
>> Vincent Vande Vyvre wrote:
>>
>>> Le 12/04/17 à 08:57, Vincent Vande Vyvre a écrit :
Hi,
Learning CPython, I've made this simple exercice, a module test which
contains an object Test.
The object Test has an attribute name, fixed at instanciation.
So, I try my code with a script:
---
from test import Test
for n in ("The name", "Foo", "Spam"):
t = Test(n)
print("%s --> %s" %(n, t.name))
---
And the return:
Uhe name --> Uhe name
Goo --> Goo
Tpam --> Tpam
As we can see, the first letter is changed with the next letter in
alphabetical order, but not only for the attribute name, also for the
reference n.
>>> if (!PyArg_ParseTupleAndKeywords(args, kwds, "s|", kwlist, &name))
>>> return -1;
>>>
>>> if (name) {
>>> tmp = self->name;
>>> Py_INCREF(name);
>> While I don't know how to do this properly you seem to be applying
>> Py_INCREF() to a C string rather than a Python string object. C being C
>> you can cast anything to anything else...
>>
>> Aren't there any warnings at compile time?
>>
>
> No, no warning.
>
>
> For the truth, this code is copy-pasted from the doc.
>
> https://docs.python.org/3.5//extending/newtypes.html#adding-data-and-methods-to-the-basic-example
But the example expects objects (the big O), not strings. Following the
example you need
if (!PyArg_ParseTupleAndKeywords(args, kwds, "O|", kwlist, &name))
return -1;
and also
static PyMemberDef Test_members[] = {
{"name", T_OBJECT_EX, offsetof(Test, name), 0,
"The object name"},
{NULL} /* Sentinel */
};
If you want a string instead of an object you must not apply Py_INCREF(),
you probably have to manage its lifetime yourself.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wednesday, 12 April 2017 07:48:57 UTC+1, Steven D'Aprano wrote:
> On Tue, 11 Apr 2017 21:10:56 -0700, Rick Johnson wrote:
>
> > high level languages like Python should make it difficult, if not
> > impossible, to write sub-
> > optimal code (at least in the blatantly obvious cases).
>
> Here's another example:
>
> answer = 0
> for i in range(10):
> answer += 1
>
> instead of
>
> answer = 10
>
> So... how exactly does the compiler prohibit stupid code?
Actually, an optimising C compiler (not one of mine!) probably could reduce
that to answer=10. And eliminate even that if 'answer' was never used.
But that's not really the issue here. Assume that such a loop /is/ doing
something more useful. The problems with Python (last time I looked anyway)
were these:
(1) If answer was a global variable, then it needs a symbol table lookup to
find out what it is. That would not happen in a static language, or a less
dynamic one, as you already have the address.
And this lookup happens for every loop iteration.
(2) There is also 'range', which could have been redefined to mean something
else, so /that/ needs a lookup. The byte-code compiler can't just assume this
loop is to be executed 10 times.
(3) This was fixed long ago but at one time, even when 'range' had been
established to be a range, it involved constructing a list of items (10 here,
but it could be a million), and then iterating over the list.
This might seem crazy, but it might have been exceptable for a script language
at one time. Not for a general purpose one however.
(4) Python's integer types being immutable, the += operation means evaluating
the result, then creating a new integer object and binding 'a' to that new
value. (Correct me if I'm wrong.)
These are all things the language could point a finger at before blaming the
user for writing inefficient code.
The problem is also the language encouraging people to use high-level but
inefficient methods, as the emphasis is on productivity and readability**
rather than performance. In fact most users probably have no idea on what is
efficient and what isn't.
If I wanted to work with the code for character 'A' (ie. the integer 65), in
another language it might represent it as 'A' which is mapped to 65. In Python,
'A' is a string. To get the integer code, I have to use ord('A'). To do that,
it has to look up 'ord', than execute a function call... In the meantime the
more static language has long since finished whatever it was going to do with
that code.
(** Although I find code full of class definitions, one-liners, decorators and
all the other esoterics, incomprehensive. I'm sure I'm not the only one, so
perhaps readability isn't too much of a priority either.)
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: CPython Class variable exposed to Python is altered.
Le 12/04/17 à 11:47, Peter Otten a écrit :
Vincent Vande Vyvre wrote:
No, no warning.
For the truth, this code is copy-pasted from the doc.
https://docs.python.org/3.5//extending/newtypes.html#adding-data-and-methods-to-the-basic-example
But the example expects objects (the big O), not strings. Following the
example you need
if (!PyArg_ParseTupleAndKeywords(args, kwds, "O|", kwlist, &name))
return -1;
and also
static PyMemberDef Test_members[] = {
{"name", T_OBJECT_EX, offsetof(Test, name), 0,
"The object name"},
{NULL} /* Sentinel */
};
If you want a string instead of an object you must not apply Py_INCREF(),
you probably have to manage its lifetime yourself.
I've just installed a new venv with the 3.6.1 and tested your changes.
And now, that's all right.
I see the devil is into the details ...
Many thanks Peter
Vincent
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
Paul Rubin : > I'd be interested to know how to open a disk file asynchronously in a > single-threaded Python program under Linux. As far as I can tell there > is no way to do it. Traditionally, disk access in Linux has been considered nonblocking. There is AIO, but that hasn't been used much. I have seen quite a bit of activity on the Linux FS mailing list recently on AIO so maybe that will change in the future. I believe the lack of asynchronous disk I/O is related to the grand Solaris idea which Linux adopted: all memory is on a disk and RAM is merely a cache. You can turn disk access into memory access with mmap() and you can turn memory access into disk access with /proc/mem. If you access a file and the relevant bytes are already cached in RAM you get them instantaneously; otherwise you'll have to wait for a "page fault" to be processed. If you need to execute a CPU instruction and the relevant address is already cached in RAM, the CPU can proceed without delay; otherwise the CPU will have to wait for a page fault to be processed. As swapping is no longer considered normal on modern computers, the memory-disk duality doesn't seem all that practical anymore. Rather, you'd like to treat the disk analogously to network access and keep RAM access separate. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
bart4...@gmail.com: > On Wednesday, 12 April 2017 07:48:57 UTC+1, Steven D'Aprano wrote: >> Here's another example: >> >> answer = 0 >> for i in range(10): >> answer += 1 >> >> instead of >> >> answer = 10 >> >> So... how exactly does the compiler prohibit stupid code? > > Actually, an optimising C compiler (not one of mine!) probably could > reduce that to answer=10. One of the reasons C compilers need to address "stupid" code like that is that it may arise from macros or from generated code. Maybe the statement "answer += 1" is "answer = answer * 1.01 + 0.0001" in some other (compile-time) circumstances. A similar situation can hit Python as well through a (virtual) method call, a dynamic function call or a conditional import, for example. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: What is the difference between x[:]=y and x=y[:]?
Peter Otten at 2017/4/12 UTC+8 PM 4:41:36 wrote: > jf...@ms4.hinet.net wrote: > > Assuming both x and y are lists > > x[:] = y > > replaces the items in x with the items in y while > > > x = y[:] > > makes a copy of y and binds that to the name x. In both cases x and y remain > different lists, but in only in the second case x is rebound. This becomes > relevant when initially there are other names bound to x. Compare: > > > >>> z = x = [1, 2] > >>> y = [10, 20, 30] > >>> x[:] = y # replace the values, z affected > >>> z > [10, 20, 30] > > > >>> z = x = [1, 2] > >>> y = [10, 20, 30] > >>> x = y[:] # rebind. x and z are now different lists > >>> z > [1, 2] Thank you Peter, I think I know the problem now. The append(lx) method actually append a link to the name lx, not append a copy of lx. When use lx[:]=lr[i]. the lx's content changes and it also reflected to the lr. When use lx=lr[i][:], a new lx was created and it will not affect the old one linked in the lr. Anyway it seems as better to use append(lx[:]) for this sake:-) --Jach -- https://mail.python.org/mailman/listinfo/python-list
PyDev 5.7.0 Released
PyDev 5.7.0 Release Highlights --- * **Important** PyDev now requires Java 8 and Eclipse 4.6 (Neon) onwards. * PyDev 5.2.0 is the last release supporting Eclipse 4.5 (Mars). * **PyLint** * The PyLint integration is much improved. * Working along with the PyDev code-analysis. * If there's an equivalent code analysis error in PyLint and PyDev, the PyLint one is hidden. * **Ctrl+1** on PyLint error line shows option to silent error in that line. * See: http://pydev.org/manual_adv_pylint.html for details. * **Debugger** * Fixed issue when sorting which could lead to error comparing a value with None. * Fixed issue which prevented debugger from working with Jython due to the lack of sys._current_frames. * Testing Jython on CI. * **Code Completion** * Properly unpacking assigns from a parameter to an instance with type documented in docstring. **#PyDev-778** * **Others** * When assigning parameters to attributes (**Ctrl+1** on function **def**), skip adding duplicate assignments. * When adding parameters to docstrings (**Ctrl+1** on function **def**), it will now properly update an existing docstring, not only create one from scratch. * In Windows, when searching executables, priority is given to a python executable found in the PATH (as in Mac/Linux). * Fixed issue were space was wrongly removed in code formatter. **#PyDev-784** What is PyDev? --- PyDev is an open-source Python IDE on top of Eclipse for Python, Jython and IronPython development. It comes with goodies such as code completion, syntax highlighting, syntax analysis, code analysis, refactor, debug, interactive console, etc. Details on PyDev: http://pydev.org Details on its development: http://pydev.blogspot.com What is LiClipse? --- LiClipse is a PyDev standalone with goodies such as support for Multiple cursors, theming, TextMate bundles and a number of other languages such as Django Templates, Jinja2, Kivy Language, Mako Templates, Html, Javascript, etc. It's also a commercial counterpart which helps supporting the development of PyDev. Details on LiClipse: http://www.liclipse.com/ Cheers, -- Fabio Zadrozny -- Software Developer LiClipse http://www.liclipse.com PyDev - Python Development Environment for Eclipse http://pydev.org http://pydev.blogspot.com PyVmMonitor - Python Profiler http://www.pyvmmonitor.com/ -- https://mail.python.org/mailman/listinfo/python-list
closing image automatically in for loop , python
Dear all
I have several *.sfd files which created by a simulation code. I wrote a
program containing a for Loop which reads each time one .sfd file and plot
the requested Parameters. I have two request:
1- my Problem is that for Showing successive Images in for Loop I have to
Close the Image MANAULLY each time to read next sdf file. can anyone please
tell me which command do I have to use so the code Close the Images
automatically.
2- more over, can anyone please tell me how can I create a movie with this
code.
in the following you can see my code
#
# in this program, PYTHON reads the reduced files and plot the variables .
import sys
import sdf
import numpy as np
import matplotlib.pyplot as plt
from matplotlib.font_manager import FontProperties
fp = FontProperties('Symbola')
# information from EPOCH input.deck
nx,ny= 1200, 1600
xmin=-100e-6
xmax = 50e-6
ymin = -100e-6
ymax = 100e-6
X =np.linspace(xmin,xmax,nx) #Generate linearly spaced vector. The spacing
between the points is (x2-x1)/(n-1).
Y =np.linspace(ymin,ymax,ny)
#
for n in range(0,27):
nstr = str(n)#.zfill(4)
#print nstr
##
fig = plt.figure() #plot several figures simultaneously
. reading Ex
filename ="Ex_resample" +'_sdf_'+ str(n)+'.dat'
with open(filename, 'rb') as f: #read binary file
data = np.fromfile(f, dtype='float64', count=nx*ny) #float64 for Double
precision float numbers
Ex = np.reshape(data, [ny, nx], order='F')
#print Ex.max()
#Display image with scaled colors:
plt.subplot(222)
fig1=plt.imshow(Ex, extent=[X.min()*1e6, X.max()*1e6, Y.min()*1e6,
Y.max()*1e6], vmin=0, vmax=2e12, cmap='brg', aspect='auto') #cmap='jet',
'nipy_spectral','hot','gist_ncar'
#plt.suptitle('Ex')
plt.title('sdf '+ str(n)+ '; Time= ' +str(n*50)+ 'ps',color='green',
fontsize=15)
plt.xlabel('x($\mu$m)')
plt.ylabel('y($\mu$m)')
plt.text(40,80,'Ex',color='red', fontsize=15)
plt.colorbar()
plt.show()
#fig.savefig('test.jpg')
sys.exit()
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wednesday, 12 April 2017 10:57:10 UTC+1, bart...@gmail.com wrote: > On Wednesday, 12 April 2017 07:48:57 UTC+1, Steven D'Aprano wrote: > > for i in range(10): > > answer += 1 > > So... how exactly does the compiler prohibit stupid code? > And this lookup happens for every loop iteration. I've just looked at byte-code for that loop (using an on-line Python as I don't have it on this machine). I counted 7 byte-codes that need to be executed per iteration, plus five to set up the loop, one of which needs to call a function. My language does the same loop with only 4 byte-codes. Loop setup needs 2 (to store '10' into the loop counter). It also has the option of using a loop with no control variable (as it's not used here). Still four byte-codes, but the looping byte-code is a bit faster. Plus there is the option of using ++answer instead of answer += 1. Now there are only two byte-codes! (NB don't try ++ in Python.) These are straightforward language enhancements. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Swiss Ephemeris
On 04/10/2017 07:29 AM, Deborah Swanson wrote: Fully recognizing that most of what you wrote was tongue-in-cheek, I just want to say that regardless of the wonders of modern medicine, it's a pity they learn so little about successful medicines other than their own. In other academic scientific disciplines such as physics and chemistry it's not uncommon to see history of science courses in the curriculum. But not in medicine. I learned what I know about ancient Greek science from a university physics professor, though I doubt he would ever have guessed that one of his students would someday breathe new life into that ancient science by attempting to ressurrect it. The great ancients were no less endowed with intelligence than we are, they simply directed it to different ends. 1/ success of medicine astrology is yet to be demonstrated 2/ history of science is about history, not actual science 3/ Ancients were probably as intelligent as we are, they just lacked a proper education and were filled with many false information I can understand why people would study ancient medicines, I don't when they decide to consider it actual applicable science. It could be harmful in some cases. But since it's done in Python, I guess we can let it slide :o) jm -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
bart4...@gmail.com writes: > On Wednesday, 12 April 2017 10:57:10 UTC+1, bart...@gmail.com wrote: >> On Wednesday, 12 April 2017 07:48:57 UTC+1, Steven D'Aprano wrote: > >> > for i in range(10): >> > answer += 1 > >> > So... how exactly does the compiler prohibit stupid code? > >> And this lookup happens for every loop iteration. > > I've just looked at byte-code for that loop (using an on-line Python > as I don't have it on this machine). I counted 7 byte-codes that need > to be executed per iteration, plus five to set up the loop, one of > which needs to call a function. > > My language does the same loop with only 4 byte-codes. Loop setup > needs 2 (to store '10' into the loop counter). > > It also has the option of using a loop with no control variable (as > it's not used here). Still four byte-codes, but the looping byte-code > is a bit faster. > > Plus there is the option of using ++answer instead of answer += 1. Now > there are only two byte-codes! (NB don't try ++ in Python.) > > These are straightforward language enhancements. FYI, the question is not how to optimize the code but how to prevent the programmer from writing stupid code in the first place. Someone suggested that a language should do that. But you appear to be talking about the original topic of the thread, as seen on the subject line, so ok :) -- https://mail.python.org/mailman/listinfo/python-list
Re: What is the difference between x[:]=y and x=y[:]?
jf...@ms4.hinet.net wrote: > Peter Otten at 2017/4/12 UTC+8 PM 4:41:36 wrote: >> jf...@ms4.hinet.net wrote: >> >> Assuming both x and y are lists >> >> x[:] = y >> >> replaces the items in x with the items in y while >> >> >> x = y[:] >> >> makes a copy of y and binds that to the name x. In both cases x and y >> remain different lists, but in only in the second case x is rebound. This >> becomes relevant when initially there are other names bound to x. >> Compare: >> >> >> >>> z = x = [1, 2] >> >>> y = [10, 20, 30] >> >>> x[:] = y # replace the values, z affected >> >>> z >> [10, 20, 30] >> >> >> >>> z = x = [1, 2] >> >>> y = [10, 20, 30] >> >>> x = y[:] # rebind. x and z are now different lists >> >>> z >> [1, 2] > > Thank you Peter, I think I know the problem now. The append(lx) method > actually append a link to the name lx, not append a copy of lx. When use > lx[:]=lr[i]. the lx's content changes and it also reflected to the lr. > When use lx=lr[i][:], a new lx was created and it will not affect the old > one linked in the lr. > > Anyway it seems as better to use append(lx[:]) for this sake:-) I should add that you can write lr = [[1], [0]] lx = [] for i in range(len(lr)): > ... lx = lr[i][:] > ... lx.append(0) > ... lr[i].append(1) > ... lr.append(lx) > ... lr >[[1, 1], [0, 1], [1, 0], [0, 0]] > idiomatially as >>> lr = [[1], [0]] >>> [inner + tail for tail in [[1], [0]] for inner in lr] [[1, 1], [0, 1], [1, 0], [0, 0]] Note that there is a difference -- the resulting list does not share any lists with the original `lr` as concatenating two lists produces a new one: >>> a = [1] >>> b = [2] >>> c = a + b >>> a is c False >>> b is c False -- https://mail.python.org/mailman/listinfo/python-list
Re: IOError: [Errno 12] Not enough space
On Wednesday, April 12, 2017 at 11:13:22 AM UTC+5:30, LnT wrote: > Hello eryk sun, > Thanks so much for your input. > > could you please advice. > 1) Any workaround for this issue ? > 2) is it good to report issue in Windows OS help desk ? > > Regards, > LnT > > > > On Wednesday, April 12, 2017 at 8:18:11 AM UTC+5:30, eryk sun wrote: > > On Tue, Apr 11, 2017 at 12:30 PM, LnT wrote: > > > Opening browser 'firefox' to base url 'https://onbdev.nbpa.com/zae' > > > [ WARN ] Keyword 'Capture Page Screenshot' could not be run on failure: > > > No browser is open > > > | FAIL | > > > IOError: [Errno 12] Not enough space > > > > > > > > > I have cleared %TEMP% and reran the script. > > > > Errno 12 is ENOMEM. It's a memory error and has nothing to do with > > disk space. The fact that you're getting this error while doing I/O > > seems odd if you're really using Windows 10. In Windows 7 this error > > is not uncommon with console I/O, since a small 64K heap of shared > > memory is used for IPC between the client and the console host > > (conhost.exe). Buffers for reading from and writing to the console can > > be no larger than the largest contiguous block in this shared heap. > > Otherwise the request fails with ERROR_NOT_ENOUGH_MEMORY, which the > > CRT translates to the errno value ENOMEM. Windows 8+ uses a kernel > > device (ConDrv) for IPC between the client and console host, so it > > doesn't have this limitation. Hi , you may please close this thread. Resolved the issue. Root cause - Post restart the Windows VM , Firefox browser was blocked @ Firewall. Regards, LnT -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
Steve D'Aprano writes: > On Wed, 12 Apr 2017 03:39 am, Paul Rubin wrote: > >> I still do my everyday stuff in Python and I'd like to get more >> conversant with stuff like numpy, but it feels like an old-fashioned >> language these days. > > "Old fashioned"? With await/async just added to the language, and type > annotations? And comprehensions and iterators? > > Admittedly type annotations are mostly of interest to large projects with > many developers and a huge code base. But the rest? > > Comprehensions may have been around for a decade or two in Haskell, but most > older languages don't have them. I'm pretty sure Java doesn't. Does > Javascript? Comprehensions feel like a fancy new language feature to > me. They've been in in Haskell for nearly three decades, but they were around before that. Miranda had them, as did Miranda's immediate predecessor, KRC. KRC dates from about 1980, so if you've been using that lineage of languages, list comprehensions have been a standard feature for 37 years. I've been using them almost my entire programming life. It seems odd that ECMAScript (the JavaScript standard) does not have them, but then JS seems to hide its function nature under an imperative bushel. Just another perspective... -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wednesday, 12 April 2017 12:56:32 UTC+1, Jussi Piitulainen wrote: > bartc writes: > > > These are straightforward language enhancements. > > FYI, the question is not how to optimize the code but how to prevent the > programmer from writing stupid code in the first place. Someone > suggested that a language should do that. The 'stupid code' thing is a red herring. I assume the code people write is there for a reason. But the language can also play a part in not allowing certain things to be expressed naturally. So the for-loop in the example has to have a control-variable even if it's not referenced. There is no 'case' or 'switch' statement to test one expression against multiple possibilities; usually the suggestion is to use a Dict, more of a heavyweight feature of unknown efficiency. You can't take a numeric constant and give it a name, without turning it into a global variable which now needs a lookup and which can't be folded with other constants. It seems Python completely disregards the question of efficiency, leaving that minor detail to implementations. But they can only work with what the language provides. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wednesday, April 12, 2017 at 7:09:04 PM UTC+5:30, Ben Bacarisse wrote: > Steve D'Aprano writes: > > > On Wed, 12 Apr 2017 03:39 am, Paul Rubin wrote: > > > >> I still do my everyday stuff in Python and I'd like to get more > >> conversant with stuff like numpy, but it feels like an old-fashioned > >> language these days. > > > > "Old fashioned"? With await/async just added to the language, and type > > annotations? And comprehensions and iterators? > > > > Admittedly type annotations are mostly of interest to large projects with > > many developers and a huge code base. But the rest? > > > > Comprehensions may have been around for a decade or two in Haskell, but most > > older languages don't have them. I'm pretty sure Java doesn't. Does > > Javascript? Comprehensions feel like a fancy new language feature to > > me. > > They've been in in Haskell for nearly three decades, but they were > around before that. Miranda had them, as did Miranda's immediate > predecessor, KRC. KRC dates from about 1980, so if you've been using > that lineage of languages, list comprehensions have been a standard > feature for 37 years. I've been using them almost my entire programming > life. > > It seems odd that ECMAScript (the JavaScript standard) does not have > them, but then JS seems to hide its function nature under an imperative > bushel. Comes from set comprehensions in SETL (I think) ie about 50 years old https://en.wikipedia.org/wiki/SETL Which itself goes back another 50 years to Zermelo-Fraenkel set theory [Miranda actually used to call list comprehensions as ZF-expressions] -- https://mail.python.org/mailman/listinfo/python-list
external process not terminating
I have an app (using 2.7) that processes requests. When a request of type "A" is received I need to start an external process. When a request of type "B" is received I need to check and see if that external process has completed or not and then do some stuff depending on if it has or not. The issue I am running into is that when the external process is done is does not exit, it goes into a zombie state, e.g.: 1 Z root 13703 13644 0 80 0 - 0 exit 09:37 ? 00:00:00 [python] Initially I was starting the process with Popen like this: DEVNULL = open(os.devnull, "wb") subprocess.Popen(cmd+args, stdin=DEVNULL, stdout=DEVNULL, stderr=DEVNULL, close_fds=True) I tried using os.spawn: os.spawnv(os.P_NOWAIT, 'python', cmd+args) But still the process did not exit. Anyone know how I can get the external process to terminate when done? TIA! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 04/12/2017 03:33 AM, Brecht Machiels wrote: > However, rinohtype is located in a very different niche and it would > greatly benefit a lot from a speed boost. Rendering the Sphinx > documentation (311 pages) takes almost 10 minutes on my i7, which is > simply too long given the available processing power. And yes, I have > spent a lot time profiling and optimizing the code. You're always > welcome to demonstrate my incompetence by means of a pull request, of > course ;-) You talked about PyPy before. Did you try rinohtype on pypy3? I tried to download pypy3 just now but the x86_64 binary package isn't compatible with my old distro (Centos 7) and I don't quite have time to build it from source. But if I can get that running I would like to try your rinoh demos with it and see how it performs. I've seen some pretty good speedups on slow, CPU-intensive python code before with pypy. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 04/11/2017 06:38 PM, Paul Rubin wrote: > Grant Edwards writes: >> If there are now other Python implementations (e.g. MicroPython) with >> C APIs that differ from CPython, then it seems like it is no longer >> redundant to say "the CPython API". > > Perhaps there should be an attempt to define a unified API like the Java > JNI, Lisp FFI's, etc. This is not at all what the CPython API is all about. The CPython API is of course for extending Python with or embedding Python in C. Equivalent to the JNI and Lisp FFI is the CFFI [1]. The JNI, the FFI, and the CFFI, are all for calling native code from within their respective languages, if I understand correctly. They don't define a standard way for native code to call into these languages. [1] https://cffi.readthedocs.io/en/latest/ -- https://mail.python.org/mailman/listinfo/python-list
XML tree to a pandas dataframe
What is the best way to convert XML document into a pandas dataframe? Regards. David -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 2017-04-12 14:46:45 +, Michael Torrie said: On 04/12/2017 03:33 AM, Brecht Machiels wrote: However, rinohtype is located in a very different niche and it would greatly benefit a lot from a speed boost. Rendering the Sphinx documentation (311 pages) takes almost 10 minutes on my i7, which is simply too long given the available processing power. And yes, I have spent a lot time profiling and optimizing the code. You're always welcome to demonstrate my incompetence by means of a pull request, of course ;-) You talked about PyPy before. Did you try rinohtype on pypy3? I did. See https://bitbucket.org/pypy/pypy/issues/2365/rinohtype-much-slower-on-pypy3 A long time ago, I also backported rinohtype to Python2 to test with PyPy2. See https://mail.python.org/pipermail/pypy-dev/2015-August/013767.html I haven't been able to try the latest PyPy3 release because there is no binary for macOS, and building it using pyenv fails (https://github.com/pyenv/pyenv/issues/890). I tried to download pypy3 just now but the x86_64 binary package isn't compatible with my old distro (Centos 7) and I don't quite have time to build it from source. But if I can get that running I would like to try your rinoh demos with it and see how it performs. I've seen some pretty good speedups on slow, CPU-intensive python code before with pypy. It would be great if you could run the benchmark I mention in my first link and share the results. Highly appreciated! Best regards, Brecht -- https://mail.python.org/mailman/listinfo/python-list
Re: closing image automatically in for loop , python
On Wed, 12 Apr 2017 04:18:45 -0700, Masoud Afshari wrote: > filename ="Ex_resample" +'_sdf_'+ str(n)+'.dat' > with open(filename, 'rb') as f: #read binary file data = np.fromfile(f, > dtype='float64', count=nx*ny) #float64 for Double precision float numbers > Ex = np.reshape(data, [ny, nx], order='F') > #print Ex.max() Your use of the 'with open(...) as f :' should automatically close access to filename once beyond that section. In your posting, the commented-out sections and garbled spacing would prevent anything useful from happening. Does that accurately reflect the code you're trying to run? -F -- https://mail.python.org/mailman/listinfo/python-list
How to pd.read_csv into a DataFrame with multiple seperators?
Have a look at this example. http://www.ebi.ac.uk/ena/data/warehouse/search?query=%22geo_circ(-0.587,-90.5713,170)%22&result=sequence_release&display=text How to pd.read_csv into a DataFrame with multiple seperators? Regards. David -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
bart4...@gmail.com writes: > On Wednesday, 12 April 2017 12:56:32 UTC+1, Jussi Piitulainen wrote: >> bartc writes: >> > >> > These are straightforward language enhancements. >> >> FYI, the question is not how to optimize the code but how to prevent >> the programmer from writing stupid code in the first place. Someone >> suggested that a language should do that. > > The 'stupid code' thing is a red herring. I assume the code people > write is there for a reason. So you walked in to a conversation about something that does not interest you and simply started talking about your own thing. Because of course you did. I get confused when you do that. -- https://mail.python.org/mailman/listinfo/python-list
Re: IOError: [Errno 12] Not enough space
On 12-4-2017 7:54, LnT wrote: > > Hi Irmen, > > you may please find full log @ https://pastebin.mozilla.org/9018753 I have no idea what I'm looking at. But my initial response was wrong, see the reply by eryk sun; your error has nothing to do with disk space but rather, a lack of system memory. Irmen -- https://mail.python.org/mailman/listinfo/python-list
HOT LIST
Hi Hope you doing great! Greeting from Niche Soft Solutions. I would like to present our topnotch consultants currently available. Please have a look at the below hot list of Niche Soft Solutions and mail your Direct Client requirements to j...@nichesoftsolutions.com Please add my Email ID to your mailing list and send the requirements on daily basis You can reach me at 503-536-2043 Name Technology Experience Visa status Current Location Relocation Tapasya .Net & Data Analyst 10+ H1B CO OPEN Malika Java 9+ H1B CA OPEN Vinoth Data Stage Developer 7+ H1B MI OPEN Sumathi QA Tester 8+ H1B CT OPEN Rahul People Soft 8+ H1B CA OPEN Laxman Java 10+ H1B VA VA Pooja Gosh WebMethod Developer 7+ H1B CA OPEN Rashi Guidewire Developer 8+ H1B TX OPEN Shabeer WebMethod Developer 7+ H1B NC OPEN -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wednesday, 12 April 2017 16:50:01 UTC+1, Jussi Piitulainen wrote: > bart4...@gmail.com writes: > > > On Wednesday, 12 April 2017 12:56:32 UTC+1, Jussi Piitulainen wrote: > >> bartc writes: > >> > > > >> > These are straightforward language enhancements. > >> > >> FYI, the question is not how to optimize the code but how to prevent > >> the programmer from writing stupid code in the first place. Someone > >> suggested that a language should do that. > > > > The 'stupid code' thing is a red herring. I assume the code people > > write is there for a reason. > > So you walked in to a conversation about something that does not > interest you and simply started talking about your own thing. > > Because of course you did. > > I get confused when you do that. Huh? The subject is making Python faster. It's generally agreed that being very dynamic makes that harder, everything else being equal. I don't agree that stopping people writing silly code is that helpful. It might be in the itself silly example of 'for i in range(10): x+=1', but usually there will be a good reason for such a loop. If you want to argue that bad choices of algorithm and bad code are a factor in performance, then there's that too. But that applies equally to every language. You can choose the best algorithm and perfectly correct code, and Python will still most likely execute it more slowely than a less dynamic language. If by some chance Python is faster, then it will probably be because it's offloading the real work to some library, not written in Python. -- https://mail.python.org/mailman/listinfo/python-list
Re: XML tree to a pandas dataframe
On Thu, Apr 13, 2017 at 12:54 AM, David Shi via Python-list wrote: > What is the best way to convert XML document into a pandas dataframe? > Regards. > David I don't know. What's the least painful way to gouge out my eyes with a rusty fork? You're going to need to know the layout of the XML document. Since XML is not, by nature, a tabular data structure, it's not going to directly translate into a dataframe (in the way that, say, a CSV file can). You'll need to figure out what represents a row and what represents the fields within that row. This will probably involve a large amount of work parsing the XML file; you can do the low level heavy lifting with lxml or equivalent, but compiling the parsed data into rows and columns is all up to you. In all sincerity I say to you: Good luck. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wednesday, 12 April 2017 16:04:53 UTC+1, Brecht Machiels wrote: > On 2017-04-12 14:46:45 +, Michael Torrie said: > It would be great if you could run the benchmark I mention in my first > link and share the results. Highly appreciated! Were you ever able to isolate what it was that's taking up most of the time? Either in general or in the bit that pypy has trouble with. Or is execution time spread too widely? (I looked at your project but it's too large, and didn't get much further with the github benchmark, which requires me to subscribe, but the .sh file extensions don't seem too promising to someone on Windows.) Your program seems to be to do with typesetting. Is it possible to at least least quantity the work that is being done in terms of total bytes (and total files) of input, and bytes of output? That might enable comparisons with other systems executing similar tasks, to see if the Python version is taking unreasonably long. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Namedtuples: some unexpected inconveniences
I won't say the following points are categorically true, but I became
convinced enough they were true in this instance that I abandoned the
advised strategy. Which was to use defaultdict to group the list of
namedtuples by one of the fields for the purpose of determining whether
certain other fields in each group were either missing values or
contained contradictory values.
Are these bugs, or was there something I could have done to avoid these
problems? Or are they just things you need to know working with
namedtuples?
The list of namedtuples was created with:
infile = open("E:\\Coding projects\\Pycharm\\Moving\\Moving 2017 in -
test.csv")
rows = csv.reader(infile)fieldnames = next(rows)
Record = namedtuple("Record", fieldnames)
records = [Record._make(fieldnames)]
records.extend(Record._make(row) for row in rows)
. . .
(many lines of field processing code)
. . .
then the attempt to group the records by title:
import operator
records[1:] = sorted(records[1:], key=operator.attrgetter("title",
"Date")) groups = defaultdict() for r in records[1:]:
# if the key doesn't exist, make a new group
if r.title not in groups.keys():
groups[r.title] = [r]
# if key (group) exists, append this record
else:
groups[r.title].append(r)
(Please note that this default dict will not automatically make new keys
when they are encountered, possibly because the keys of the defaultdict
are made from namedtuples and the values are namedtuples. So you have to
include the step to make a new key when a key is not found.)
If you succeed in modifying records in a group, the dismaying thing is
that the underlying records are not updated, making the entire exercise
totally pointless, which was a severe and unexpected inconvenience.
It looks like the values and the structure were only copied from the
original list of namedtuples to the defaultdict. The rows of the
grouped-by dict still behave like namedtuples, but they are no longer
the same namedtuples as the original list of namedtuples. (I'm sure I
didn't say that quite right, please correct me if you have better words
for it.)
It might be possible to complete the operation and then write out the
groups of rows of namedtuples in the dict to a simple list of
namedtuples, discarding the original, but at the time I noticed that
modifying rows in a group didn't change the values in the original list
of namedtuples, I still had further to go with the dict of groups, and
it was looking easier by the minute to solve the missing values problem
directly from the original list of namedtuples, so that's what I did.
If requested I can reproduce how I saw that the original list of
namedtuples was not changed when I modified field values in group rows
of the dict, but it's lengthy and messy. It might be worthwhile though
if someone might see a mistake I made, though I found the same behavior
several different ways. Which was when I called it barking up the wrong
tree and quit trying to solve the problem that way.
Another inconvenience is that there appears to be no way to access field
values of a named tuple by variable, although I've had limited success
accessing by variable indices. However, direct attempts to do so, like:
values = {row[label] for row in group}
(where 'label' is a variable for the field names of a namedtuple)
gets "object has no attribute 'label'
or, where 'record' is a row in a list of namedtuples and 'label' is a
variable for the fieldnames of a namedtuple:
value = getattr(record, label)
setattr(record, label, value) also don't work.
You get the error 'object has no attribute 'label' every time.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Namedtuples: some unexpected inconveniences
On 2017-04-12 20:57, Deborah Swanson wrote:
I won't say the following points are categorically true, but I became
convinced enough they were true in this instance that I abandoned the
advised strategy. Which was to use defaultdict to group the list of
namedtuples by one of the fields for the purpose of determining whether
certain other fields in each group were either missing values or
contained contradictory values.
Are these bugs, or was there something I could have done to avoid these
problems? Or are they just things you need to know working with
namedtuples?
The list of namedtuples was created with:
infile = open("E:\\Coding projects\\Pycharm\\Moving\\Moving 2017 in -
test.csv")
rows = csv.reader(infile)fieldnames = next(rows)
Record = namedtuple("Record", fieldnames)
records = [Record._make(fieldnames)]
records.extend(Record._make(row) for row in rows)
. . .
(many lines of field processing code)
. . .
then the attempt to group the records by title:
import operator
records[1:] = sorted(records[1:], key=operator.attrgetter("title",
"Date")) groups = defaultdict() for r in records[1:]:
# if the key doesn't exist, make a new group
if r.title not in groups.keys():
groups[r.title] = [r]
# if key (group) exists, append this record
else:
groups[r.title].append(r)
(Please note that this default dict will not automatically make new keys
when they are encountered, possibly because the keys of the defaultdict
are made from namedtuples and the values are namedtuples. So you have to
include the step to make a new key when a key is not found.)
The defaultdict _will_ work when you use it properly. :-)
The line should be:
groups = defaultdict(list)
so that it'll make a new list every time a new key is automatically added.
Another point: namedtuples, as with normal tuples, are immutable; once
created, you can't change an attribute. A dict might be a better bet.
If you succeed in modifying records in a group, the dismaying thing is
that the underlying records are not updated, making the entire exercise
totally pointless, which was a severe and unexpected inconvenience.
It looks like the values and the structure were only copied from the
original list of namedtuples to the defaultdict. The rows of the
grouped-by dict still behave like namedtuples, but they are no longer
the same namedtuples as the original list of namedtuples. (I'm sure I
didn't say that quite right, please correct me if you have better words
for it.)
It might be possible to complete the operation and then write out the
groups of rows of namedtuples in the dict to a simple list of
namedtuples, discarding the original, but at the time I noticed that
modifying rows in a group didn't change the values in the original list
of namedtuples, I still had further to go with the dict of groups, and
it was looking easier by the minute to solve the missing values problem
directly from the original list of namedtuples, so that's what I did.
If requested I can reproduce how I saw that the original list of
namedtuples was not changed when I modified field values in group rows
of the dict, but it's lengthy and messy. It might be worthwhile though
if someone might see a mistake I made, though I found the same behavior
several different ways. Which was when I called it barking up the wrong
tree and quit trying to solve the problem that way.
Another inconvenience is that there appears to be no way to access field
values of a named tuple by variable, although I've had limited success
accessing by variable indices. However, direct attempts to do so, like:
values = {row[label] for row in group}
(where 'label' is a variable for the field names of a namedtuple)
gets "object has no attribute 'label'
or, where 'record' is a row in a list of namedtuples and 'label' is a
variable for the fieldnames of a namedtuple:
value = getattr(record, label)
setattr(record, label, value) also don't work.
You get the error 'object has no attribute 'label' every time.
--
https://mail.python.org/mailman/listinfo/python-list
Passing parameters thru decorators
Hi,
I'm trying to work out how to pass parameters through decorators:
class Meow():
def __init__(self, arg1, arg2):
print("INIT ClassBasedDecoratorWithParams")
print(arg1)
print(arg2)
def makebold(self, fn):
def wrapped():
return "" + fn() + ""
return wrapped
banana = Meow("foo", "bar")
@banana.makebold("foobar")
def hello():
return "hello world"
print(hello())
Returns error:
INIT ClassBasedDecoratorWithParams
Traceback (most recent call last):
foo
File "/Users/andrew/PycharmProjects/untitled3/meow5.py", line 15, in
bar
@banana.makebold("foobar")
TypeError: wrapped() takes 0 positional arguments but 1 was given
so I add a var to wrapped:
def makebold(self, fn):
def wrapped(flibble):
print(flibble)
return "" + fn() + ""
return wrapped
Returns error:
INIT ClassBasedDecoratorWithParams
Traceback (most recent call last):
foo
bar
File "/Users/andrew/PycharmProjects/untitled3/meow5.py", line 16, in
@banana.makebold("foobar")
File "/Users/andrew/PycharmProjects/untitled3/meow5.py", line 11, in wrapped
return "" + fn() + ""
TypeError: 'str' object is not callable
This is confusing me. How do I get hold of the "foobar" string so I can use it
in the decorator?
Cheers,
Andrew
--
https://mail.python.org/mailman/listinfo/python-list
Re: Namedtuples: some unexpected inconveniences
Deborah Swanson wrote:
> I won't say the following points are categorically true, but I became
> convinced enough they were true in this instance that I abandoned the
> advised strategy. Which was to use defaultdict to group the list of
> namedtuples by one of the fields for the purpose of determining whether
> certain other fields in each group were either missing values or
> contained contradictory values.
>
> Are these bugs, or was there something I could have done to avoid these
> problems? Or are they just things you need to know working with
> namedtuples?
>
> The list of namedtuples was created with:
>
> infile = open("E:\\Coding projects\\Pycharm\\Moving\\Moving 2017 in -
> test.csv")
> rows = csv.reader(infile)fieldnames = next(rows)
> Record = namedtuple("Record", fieldnames)
> records = [Record._make(fieldnames)]
> records.extend(Record._make(row) for row in rows)
> . . .
> (many lines of field processing code)
> . . .
>
> then the attempt to group the records by title:
>
> import operator
> records[1:] = sorted(records[1:], key=operator.attrgetter("title",
> "Date"))
Personally I would immediately discard the header row once and for all, not
again and again on every operation.
> groups = defaultdict() for r in records[1:]:
> # if the key doesn't exist, make a new group
> if r.title not in groups.keys():
> groups[r.title] = [r]
> # if key (group) exists, append this record
> else:
> groups[r.title].append(r)
You are not using the defaultdict the way it is intended; the groups can be
built with
groups = defaultdict(list)
for r in records[1:]:
groups[r.title].append(r)
> (Please note that this default dict will not automatically make new keys
> when they are encountered, possibly because the keys of the defaultdict
> are made from namedtuples and the values are namedtuples. So you have to
> include the step to make a new key when a key is not found.)
>
> If you succeed in modifying records in a group, the dismaying thing is
> that the underlying records are not updated, making the entire exercise
> totally pointless, which was a severe and unexpected inconvenience.
>
> It looks like the values and the structure were only copied from the
> original list of namedtuples to the defaultdict. The rows of the
> grouped-by dict still behave like namedtuples, but they are no longer
> the same namedtuples as the original list of namedtuples. (I'm sure I
> didn't say that quite right, please correct me if you have better words
> for it.)
They should be the same namedtuple. Something is wrong with your actual code
or your diagnosis or both.
>
> It might be possible to complete the operation and then write out the
> groups of rows of namedtuples in the dict to a simple list of
> namedtuples, discarding the original, but at the time I noticed that
> modifying rows in a group didn't change the values in the original list
> of namedtuples, I still had further to go with the dict of groups, and
> it was looking easier by the minute to solve the missing values problem
> directly from the original list of namedtuples, so that's what I did.
>
> If requested I can reproduce how I saw that the original list of
> namedtuples was not changed when I modified field values in group rows
> of the dict, but it's lengthy and messy. It might be worthwhile though
> if someone might see a mistake I made, though I found the same behavior
> several different ways. Which was when I called it barking up the wrong
> tree and quit trying to solve the problem that way.
>
> Another inconvenience is that there appears to be no way to access field
> values of a named tuple by variable, although I've had limited success
> accessing by variable indices. However, direct attempts to do so, like:
>
> values = {row[label] for row in group}
> (where 'label' is a variable for the field names of a namedtuple)
>
> gets "object has no attribute 'label'
>
> or, where 'record' is a row in a list of namedtuples and 'label' is a
> variable for the fieldnames of a namedtuple:
>
> value = getattr(record, label)
That should work.
> setattr(record, label, value) also don't work.
>
> You get the error 'object has no attribute 'label' every time.
Indeed you cannot change the namedtuple's attributes. Like the "normal"
tuple it is designed to be immutable. If you want changes in one list (the
group) to appear in another (the original records) you need a mutable data
type.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Passing parameters thru decorators
On 2017-04-12 21:42, andrew.hol...@otternetworks.de wrote:
Hi,
I'm trying to work out how to pass parameters through decorators:
class Meow():
def __init__(self, arg1, arg2):
print("INIT ClassBasedDecoratorWithParams")
print(arg1)
print(arg2)
def makebold(self, fn):
def wrapped():
return "" + fn() + ""
return wrapped
banana = Meow("foo", "bar")
@banana.makebold("foobar")
def hello():
return "hello world"
print(hello())
Returns error:
INIT ClassBasedDecoratorWithParams
Traceback (most recent call last):
foo
File "/Users/andrew/PycharmProjects/untitled3/meow5.py", line 15, in
bar
@banana.makebold("foobar")
TypeError: wrapped() takes 0 positional arguments but 1 was given
so I add a var to wrapped:
def makebold(self, fn):
def wrapped(flibble):
print(flibble)
return "" + fn() + ""
return wrapped
Returns error:
INIT ClassBasedDecoratorWithParams
Traceback (most recent call last):
foo
bar
File "/Users/andrew/PycharmProjects/untitled3/meow5.py", line 16, in
@banana.makebold("foobar")
File "/Users/andrew/PycharmProjects/untitled3/meow5.py", line 11, in wrapped
return "" + fn() + ""
TypeError: 'str' object is not callable
This is confusing me. How do I get hold of the "foobar" string so I can use it
in the decorator?
You're passing "foobar" into 'makebold' in the parameter 'fn' and then
trying to call 'fn' in the return statement. You can't call a string.
--
https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
> -Original Message-
> From: Python-list
> [mailto:python-list-bounces+python=deborahswanson.net@python.o
> rg] On Behalf Of MRAB
> Sent: Wednesday, April 12, 2017 1:42 PM
> To: python-list@python.org
> Subject: Re: Namedtuples: some unexpected inconveniences
>
>
> On 2017-04-12 20:57, Deborah Swanson wrote:
> > Are these bugs, or was there something I could have done to avoid
> > these problems? Or are they just things you need to know
> working with namedtuples?
> >
> > The list of namedtuples was created with:
> >
> > infile = open("E:\\Coding projects\\Pycharm\\Moving\\Moving
> 2017 in -
> > test.csv")
> > rows = csv.reader(infile)fieldnames = next(rows)
> > Record = namedtuple("Record", fieldnames)
> > records = [Record._make(fieldnames)]
> > records.extend(Record._make(row) for row in rows)
> > . . .
> > (many lines of field processing code)
> > . . .
> >
> > then the attempt to group the records by title:
> >
> > import operator
> > records[1:] = sorted(records[1:], key=operator.attrgetter("title",
> > "Date")) groups = defaultdict() for r in records[1:]:
> > # if the key doesn't exist, make a new group
> > if r.title not in groups.keys():
> > groups[r.title] = [r]
> > # if key (group) exists, append this record
> > else:
> > groups[r.title].append(r)
> >
> > (Please note that this default dict will not automatically make new
> > keys when they are encountered, possibly because the keys of the
> > defaultdict are made from namedtuples and the values are
> namedtuples.
> > So you have to include the step to make a new key when a key is not
> > found.)
MRAB said:
> The defaultdict _will_ work when you use it properly. :-)
>
> The line should be:
>
> groups = defaultdict(list)
>
> so that it'll make a new list every time a new key is
> automatically added.
Arg. Now I remember the thought crossing my mind early on, and noticing
that the characterizing property of a defaultdict was what you set the
default to be. Too bad I forgot that useful thought once I was entangled
with all those other problems.
Thanks for jogging that memory stuck in a hidey hole.
> Another point: namedtuples, as with normal tuples, are immutable; once
> created, you can't change an attribute. A dict might be a better bet.
Yes, namedtuples still being tuples was a point mentioned in passing by
someone, I think Steve D'Aprano, but I didn't immediately see that as
being the roadblock to accessing field values by variable. It does make
sense now though, although others on the list also didn't see it, so I'm
not feeling as bad about it as I could.
Namedtuples absolutely was the right data structure for two thirds of
this program. I only ran into trouble with it trying to do the
defaultdict group by thing. And it all turned out ok just by going back
to the original list.
Now, if I could understand why the namedtuples grouped by the
defaultdict were only copied instead of remaining the same namedtuples
as the list they were copied from, that should wrap this set of problems
up.
Many thanks again!
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
Re: Passing parameters thru decorators
andrew.hol...@otternetworks.de wrote:
> Hi,
>
> I'm trying to work out how to pass parameters through decorators:
>
> class Meow():
>
> def __init__(self, arg1, arg2):
> print("INIT ClassBasedDecoratorWithParams")
> print(arg1)
> print(arg2)
>
> def makebold(self, fn):
> def wrapped():
> return "" + fn() + ""
> return wrapped
>
> banana = Meow("foo", "bar")
> @banana.makebold("foobar")
>
> def hello():
> return "hello world"
>
> print(hello())
>
>
> Returns error:
> INIT ClassBasedDecoratorWithParams
> Traceback (most recent call last):
> foo
> File "/Users/andrew/PycharmProjects/untitled3/meow5.py", line 15, in
>
> bar
> @banana.makebold("foobar")
> TypeError: wrapped() takes 0 positional arguments but 1 was given
>
>
> so I add a var to wrapped:
>
> def makebold(self, fn):
> def wrapped(flibble):
> print(flibble)
> return "" + fn() + ""
> return wrapped
>
> Returns error:
> INIT ClassBasedDecoratorWithParams
> Traceback (most recent call last):
> foo
> bar
> File "/Users/andrew/PycharmProjects/untitled3/meow5.py", line 16, in
>
>
> @banana.makebold("foobar")
> File "/Users/andrew/PycharmProjects/untitled3/meow5.py", line 11, in
> wrapped
> return "" + fn() + ""
> TypeError: 'str' object is not callable
>
> This is confusing me. How do I get hold of the "foobar" string so I can
> use it in the decorator?
You need one more level of indirection:
class Meow():
def __init__(self, arg1, arg2):
print("INIT ClassBasedDecoratorWithParams")
print(arg1)
print(arg2)
def makebold(self, flibble):
def decorator(fn):
def wrapped():
print("flibble =", flibble)
return "" + fn() + ""
return wrapped
return decorator
banana = Meow("foo", "bar")
@banana.makebold("foobar")
def hello():
return "hello world"
print(hello())
--
https://mail.python.org/mailman/listinfo/python-list
Re: external process not terminating
On Wed, Apr 12, 2017 at 10:51 AM, Dennis Lee Bieber wrote: > On Wed, 12 Apr 2017 09:51:12 -0400, Larry Martell > declaimed the following: > > >> >>Anyone know how I can get the external process to terminate when done? >> > > It has... You just haven't cleaned up after it... > > https://en.wikipedia.org/wiki/Zombie_process > > """ > This occurs for child processes, where the entry is still needed to allow > the parent process to read its child's exit status: once the exit status is > read via the wait system call, the zombie's entry is removed from the > process table and it is said to be "reaped". > """ Thanks. I knew that but I had lost the forest for the trees. I added a call to os.waitpid() and now all is well. -- https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Peter Otten wrote, on Wednesday, April 12, 2017 1:45 PM
>
> Deborah Swanson wrote:
>
> > I won't say the following points are categorically true, but I
became
> > convinced enough they were true in this instance that I abandoned
the
> > advised strategy. Which was to use defaultdict to group the list of
> > namedtuples by one of the fields for the purpose of determining
> > whether certain other fields in each group were either missing
values
> > or contained contradictory values.
> >
> > Are these bugs, or was there something I could have done to avoid
> > these problems? Or are they just things you need to know working
with
> > namedtuples?
> >
> > The list of namedtuples was created with:
> >
> > infile = open("E:\\Coding projects\\Pycharm\\Moving\\Moving 2017 in
-
> > test.csv")
> > rows = csv.reader(infile)fieldnames = next(rows)
> > Record = namedtuple("Record", fieldnames)
> > records = [Record._make(fieldnames)]
> > records.extend(Record._make(row) for row in rows)
> > . . .
> > (many lines of field processing code)
> > . . .
> >
> > then the attempt to group the records by title:
> >
> > import operator
> > records[1:] = sorted(records[1:], key=operator.attrgetter("title",
> > "Date"))
>
> Personally I would immediately discard the header row once and for
all, not
> again and again on every operation.
Well, perhaps, but I need the header row to stay in place to write the
list to a csv when I'm done (which is why it's there in the first
place). There might be a tiny performance edge in discarding the header
row for the sort, but there would also be a hit to recreate it at output
time.
> > groups = defaultdict() for r in records[1:]:
> > # if the key doesn't exist, make a new group
> > if r.title not in groups.keys():
> > groups[r.title] = [r]
> > # if key (group) exists, append this record
> > else:
> > groups[r.title].append(r)
>
> You are not using the defaultdict the way it is intended; the
> groups can be built with
>
> groups = defaultdict(list)
> for r in records[1:]:
> groups[r.title].append(r)
Yes, going back to your original post I see now that's what you gave,
and it's probably why I noticed defaultdict's being characterized by
what you make the default to be. Too bad I lost track of that.
> > (Please note that this default dict will not automatically make new
> > keys when they are encountered, possibly because the keys of the
> > defaultdict are made from namedtuples and the values are
namedtuples.
> > So you have to include the step to make a new key when a key is not
> > found.)
> >
> > If you succeed in modifying records in a group, the dismaying thing
is
> > that the underlying records are not updated, making the entire
> > exercise totally pointless, which was a severe and unexpected
> > inconvenience.
> >
> > It looks like the values and the structure were only copied from the
> > original list of namedtuples to the defaultdict. The rows of the
> > grouped-by dict still behave like namedtuples, but they are no
longer
> > the same namedtuples as the original list of namedtuples. (I'm sure
I
> > didn't say that quite right, please correct me if you have better
> > words for it.)
>
> They should be the same namedtuple. Something is wrong with
> your actual code or your diagnosis or both.
Well, I didn't see them behaving as the same namedtuples, and I looked
hard at it, many different ways. If someone could point out the mistake
I might have made to get only copies of them or why they necessarily
would be the same namedtuples, I'd certainly look into it. Or better yet
some code that does the same thing and they remain the same ones.
(But I think you got it right in your last sentence below. defaultdict
copied them because they were immutable, leaving the original list
unchanged.)
> > It might be possible to complete the operation and then write out
the
> > groups of rows of namedtuples in the dict to a simple list of
> > namedtuples, discarding the original, but at the time I noticed that
> > modifying rows in a group didn't change the values in the original
> > list of namedtuples, I still had further to go with the dict of
> > groups, and it was looking easier by the minute to solve the
missing
> > values problem directly from the original list of namedtuples, so
> > that's what I did.
> >
> > If requested I can reproduce how I saw that the original list of
> > namedtuples was not changed when I modified field values in group
rows
> > of the dict, but it's lengthy and messy. It might be worthwhile
though
> > if someone might see a mistake I made, though I found the same
> > behavior several different ways. Which was when I called it barking
up
> > the wrong tree and quit trying to solve the problem that way.
> >
> > Another inconvenience is that there appears to be no way to access
> > field values of a named tuple by variable, although I've had limited
> > success accessing by v
RE: Namedtuples: some unexpected inconveniences
Deborah Swanson wrote: >> >value = getattr(record, label) >> >> That should work. > > We may agree that it *should* work, by an intuitive grasp of how it > should work, but it doesn't. You get "object has no attribute 'label'. Only if the namedtuple (1) does not have a label attribute and (2) the value of the name label is the string "label" In that case both label = "label" getattr(record, label) and record.label will fail with the same AttributeError. The problem is *not* the dynamic access through getattr(). >> Indeed you cannot change the namedtuple's attributes. Like the "normal" >> tuple it is designed to be immutable. If you want changes in one list >> (the group) to appear in another (the original records) you need a >> mutable data type. > > Sadly, that does seem to be the correct conclusion here. Think hard if you really need the original list. -- https://mail.python.org/mailman/listinfo/python-list
Merging multiple sorted sequences.
Hi. I need to be able to lazily merge a variable number of already-sorted(*) variable-length sequences into a single sorted sequence. The merge should continue until the longest sequence has been exhausted. (*) They may in practice be a lazy source of data known to only ever be generated in an order that's "sorted" from the POV of this function. I have the following - can anyone think of any improvements (other than indentation style on the try/excepts ;) )? This seems like the sort of thing for which there might be a built-in or recipe that I've missed. - def merge(*sources): items = [] for source in (iter(s) for s in sources): try: items.append([next(source), source]) except StopIteration: pass while len(items) > 1: items.sort(key=lambda item: item[0]) lowest = items[0] yield lowest[0] try: lowest[0] = next(lowest[1]) except StopIteration: del items[0] if len(items) != 0: yield items[0][0] yield from items[0][1] - Test code: - a = range(10) b = range(4, 50, 3) c = range(20, 100, 5) # Greedy version to verify result: greedy = list(a) + list(b) + list(c) greedy.sort() # Test multiple sequences: assert list(merge(a, b, c)) == greedy # Test a single sequence: assert list(merge(greedy)) == list(merge(a, b, c)) # Test no sequences: assert list(merge()) == [] assert list(merge([], (), range(0))) == [] - Thanks, E. -- https://mail.python.org/mailman/listinfo/python-list
Re: Merging multiple sorted sequences.
Erik wrote: > I need to be able to lazily merge a variable number of already-sorted(*) > variable-length sequences into a single sorted sequence. https://docs.python.org/dev/library/heapq.html#heapq.merge -- https://mail.python.org/mailman/listinfo/python-list
Re: Merging multiple sorted sequences.
On Wed, Apr 12, 2017 at 4:44 PM, Ian Kelly wrote: > On Wed, Apr 12, 2017 at 4:15 PM, Erik wrote: >> while len(items) > 1: >> items.sort(key=lambda item: item[0]) > > This might be okay since Timsort on an already-sorted list should be > O(n). But there's not really any need to keep them sorted and I would > just use "lowest = min(items, key=itemgetter(0))". Actually, you should consider using a heap. -- https://mail.python.org/mailman/listinfo/python-list
Re: Merging multiple sorted sequences.
On Wed, Apr 12, 2017 at 4:15 PM, Erik wrote: > Hi. > > I need to be able to lazily merge a variable number of already-sorted(*) > variable-length sequences into a single sorted sequence. The merge should > continue until the longest sequence has been exhausted. > > (*) They may in practice be a lazy source of data known to only ever be > generated in an order that's "sorted" from the POV of this function. > > I have the following - can anyone think of any improvements (other than > indentation style on the try/excepts ;) )? This seems like the sort of thing > for which there might be a built-in or recipe that I've missed. There probably should be. I know I've implemented something similar in the past. > - > def merge(*sources): > items = [] > for source in (iter(s) for s in sources): >try: items.append([next(source), source]) >except StopIteration: pass > > while len(items) > 1: > items.sort(key=lambda item: item[0]) This might be okay since Timsort on an already-sorted list should be O(n). But there's not really any need to keep them sorted and I would just use "lowest = min(items, key=itemgetter(0))". > lowest = items[0] > yield lowest[0] > > try: lowest[0] = next(lowest[1]) > except StopIteration: del items[0] > > if len(items) != 0: "if items:" >yield items[0][0] >yield from items[0][1] > - -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
bart4...@gmail.com wrote: But the language can also play a part in not allowing certain things to be expressed naturally. So the for-loop in the example has to have a control-variable even if it's not referenced. If the compiler can recognise when code is "stupid", it's probably capable of doing something more intelligent than just rejecting it outright. E.g. it could notice that a loop variable wasn't used anywhere in the function and optimise it out. And it could recognise x += 1 and emit an ADD_ONE bytecode for it. Etc. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Merging multiple sorted sequences.
On 12/04/17 23:44, Ian Kelly wrote: This might be okay since Timsort on an already-sorted list should be O(n). But there's not really any need to keep them sorted and I would just use "lowest = min(items, key=itemgetter(0))". Sure (and this was my main worry). I had it in my head for some reason that min() would return the smallest key, not the object (and hence I wouldn't be able to know which sequence object to get the next value from - sorting means it's always at index 0). But of course, min() returns the outer object containing the key so I don't need to sort them to know how to address the correct sequence object. operator.itemgetter() probably helps a bit, too ;) I've done all that and it works. Thanks, E. -- https://mail.python.org/mailman/listinfo/python-list
Re: Merging multiple sorted sequences.
Hi Peter, On 12/04/17 23:42, Peter Otten wrote: Erik wrote: I need to be able to lazily merge a variable number of already-sorted(*) variable-length sequences into a single sorted sequence. https://docs.python.org/dev/library/heapq.html#heapq.merge AFAICT (looking at the Python 3.5 heapq implementation, albeit very briefly), it seems like that is a greedy algorithm. Am I missing something? Thanks, E. -- https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Peter Otten wrote, on Wednesday, April 12, 2017 3:15 PM > > Deborah Swanson wrote: > > >> >value = getattr(record, label) > >> > >> That should work. > > > > We may agree that it *should* work, by an intuitive grasp of how it > > should work, but it doesn't. You get "object has no attribute 'label'. > > Only if the namedtuple > > (1) does not have a label attribute and > (2) the value of the name label is the string "label" > > In that case both > > label = "label" > getattr(record, label) > > and > > record.label > > will fail with the same AttributeError. The problem is *not* the dynamic > access through getattr(). Agreed, it's not getattr's fault. It's a small point, but I suspect getattr(record, label) would still fail, even if label's value is 'label' and only 'label', but what's the point of having a variable if it will only ever have just one value? The question would be whether the compiler (interpreter?) would look at getattr(record, label), evaluate label and see that there is a field named 'label', but I suspect it wouldn't take that many steps. It wants to see recordset.fieldname, and a bare "label" does not reference the object. I don't exactly understand your point (2). If the namedtuple does not have a label attribute, then getattr(record, label) will get the error whether the name label holds the string 'label' or not. And it wants to see recordset.fieldname, not just fieldname. But maybe I misunderstood what you were saying. This stuff is quite loopy to think about, at least for me it is. > >> Indeed you cannot change the namedtuple's attributes. Like the > >> "normal" tuple it is designed to be immutable. If you want changes in > >> one list (the group) to appear in another (the original records) you > >> need a mutable data type. > > > > Sadly, that does seem to be the correct conclusion here. > > Think hard if you really need the original list. It's possible you might transform the namedtuple into a mutable type, and I didn't try that. But it seems like the group-by defaultdict strategy would have to have a significant performance edge to be worth it and you wouldn't have any of the namedtuple properties to work with after the transformation. I also ran into some trouble with your algorithm that follows making the defaultdict, and I'm not sure what value there would be in hashing through that. Though I'm certainly willing to if you are. It worked to simply stay with the original list of namedtuples to begin with. I remain grateful for your introduction to the collections module. What a neat little package of tools! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Thursday, 13 April 2017 00:09:35 UTC+1, Gregory Ewing wrote: > bart4...@gmail.com wrote: > > > But the language can also play a part in not allowing certain things to be > > expressed naturally. So the for-loop in the example has to have a > > control-variable even if it's not referenced. > > If the compiler can recognise when code is "stupid", it's > probably capable of doing something more intelligent than > just rejecting it outright. > > E.g. it could notice that a loop variable wasn't used > anywhere in the function and optimise it out. And it could > recognise x += 1 and emit an ADD_ONE bytecode for it. > Etc. Maybe. (Although I think Python would have difficulty in turning x+=1 into a single opcode, if using normal object references and a shared object model.) But I wouldn't be happy about a language deciding my code is 'stupid'. I might for example have an N-times loop containing x+=1 because I want to know how long it takes to execute x+=1 N times. (This is a common problem with benchmarking code actually, as you can end up measuring how long it takes /not/ to do something instead of doing it!) Anyway that loop example (I think it was Steve's) was a simple illustration. It will usually be harder to figure out if a bit of code is rational. Even with x+=1, isn't it possible to override the + or += operation with user code? Code which change the handling method at each iteration. This is dynamism making a rod for its own back. 99.99...% of the time that won't happen, but... -- bartc -- https://mail.python.org/mailman/listinfo/python-list
"Goto" statement in Python
On 12 April 2017 at 02:44, Nathan Ernst wrote:
> goto is a misunderstood and much misaligned creature. It is a very useful
> feature, but like nearly any programming construct can be abused.
>
> Constructs like 'break', 'continue' or 'next' in languages like Python or
> C/C++ are goto's with implied labels.
>
> As Mikhail said, goto's can be great to break out of nested loops (only a
> handful of languages support named 'breaks').
>
> So, instead of:
> bool found = false;
> for (int i = 0; i = ...; ++i)
> {
> for (int h = 0; h = ...; ++h)
> {
>if (some_condition)
> found = true;
> }
> if (found) break;
> }
>
> You can have:
>
> for (int i = 0; i = ...; ++i)
> {
> for (int h = 0; h = ...; ++h)
> {
>if (some_condition)
> goto found;
> }
> }
> // not found
>
> found:
> // handle found
>
> The second is better for a number of reasons: it's clearer. It has fewer
> variables (smaller stack), it has fewer branches (better for the CPU's
> branch prediction), and it has fewer instructions (better for CPU
> instruction cache). This is a trivial, contrived example, but I've seen
> more than 4x nested loops using an exit flag like this (at every level of
> the loops) that could have been replaced with a lot less code.
>
> People need to stop drinking "X is considered harmful." Even Dijkstra later
> lamented that his "Goto considered harmful" paper was misinterpreted and
> misrepresented as advocating that goto should never be used.
>
> Additionally, I'd recommend everyone read '"Considered Harmful" Essays
> Considered Harmful': http://meyerweb.com/eric/comment/chech.html
>
> Regards,
> Nate
>
Here are recent related discussions about exiting from
nested loops (at least seems to be so):
https://mail.python.org/pipermail/python-ideas/2017-March/044932.html
https://mail.python.org/pipermail/python-ideas/2017-March/045049.html
I personally have difficulties to fully understand some
of the examples given in those proposals, namely
that proposals were thought for other(?) purposes also,
not only breaking nested loops.
At a first glance it seems to me that "goto" would solve
the nested breaking problem and in a nice flexible way.
(correct me if I am wrong, probably I'm missing something)
So besides nested loops, in my practice I had occasions
when I would want to use "goto".
It would be fair to say that those occasions are not so common,
but I'll try to give an example. Say, there is some
pure procedural processing for some simple task
and I don't want to make the script heavy and just
care for the clarity:
===
Log = ""
S = "lorem ipsum"
for s in S:
if s == "i" :
message = "found on stage 1"
goto .output
S = S + " hello world"
for s in S:
if s == "d" :
message = "found on stage 2"
goto .output
print "not found"
print "S = ", S
goto .exit
.output
print message
Log = Log + message
.exit:
print "exiting"
=
For me it looks clear and I'd say easy to comprehend,
Main critic would be obviously that it is not
a good, *scalable application*, but quite often I don't
even have this in mind, and just want to express a
step-by-step direct instructions.
In this case sticking any "def():.." inside the script
does not make any sense for me. Simplicity here
reflects the fact that this code represents
exactly what I want the computer to do.
And a working variant of this would be like:
===
Log = ""
found = False
Error = False
S = "lorem ipsum"
if not found:
for s in S:
if s == "i" :
message = "found on stage 1"
found = True
if not found:
S = S + " hello world"
for s in S:
if s == "d" :
message = "found on stage 2"
found = True
if not found:
Error = True
print "Error : not found"
print "S = ", S
if not Error:
print message
Log = Log + message
print "exiting"
==
This is working code, but I would say there is
a lot extra indentation, and if I don't care about
application scalability, those are just adding noise
and I it needs some boolean flags.
I am not sure what examples to add here ...
it seems to me that e.g. if I would use Python
for modelling "pipeline" algorithms
this could be helpful also.
Now if I count in the nested loops breaking problematic,
seems that there is at least a prerequisite for existence of "goto".
Am I right?
Mikhail
--
https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Deborah Swanson wrote, on Wednesday, April 12, 2017 4:29 PM > > Peter Otten wrote, on Wednesday, April 12, 2017 3:15 PM > > > > >> Indeed you cannot change the namedtuple's attributes. Like the > > >> "normal" tuple it is designed to be immutable. If you want changes in > > >> one list (the group) to appear in another (the original records) you > > >> need a mutable data type. > > > > > > Sadly, that does seem to be the correct conclusion here. > > > > Think hard if you really need the original list. > > It's possible you might transform the namedtuple into a > mutable type, and I didn't try that. But it seems like the > group-by defaultdict strategy would have to have a > significant performance edge to be worth it and you wouldn't > have any of the namedtuple properties to work with after the > transformation. I also ran into some trouble with your > algorithm that follows making the defaultdict, and I'm not > sure what value there would be in hashing through that. > Though I'm certainly willing to if you are. > > It worked to simply stay with the original list of > namedtuples to begin with. > > I remain grateful for your introduction to the collections > module. What a neat little package of tools! I know it's quick for this double-take, but it occurs to me that transforming to a mutable type isn't a performance evaluation at all. Filling in missing values is the last step before outputting the processed list, so it might not be necessary to work with namedtuples at that point. The algorithm to fill in the missing values for each group (which would no longer be namedtuples) in the defaultdict is something I'm back at the drawing board for. But it shouldn't be too hard. Haha, we'll see! -- https://mail.python.org/mailman/listinfo/python-list
Re: "Goto" statement in Python
On 04/12/2017 04:42 PM, Mikhail V wrote:
On 12 April 2017 at 02:44, Nathan Ernst wrote:
goto is a misunderstood and much misaligned creature. It is a very useful
feature, but like nearly any programming construct can be abused.
Constructs like 'break', 'continue' or 'next' in languages like Python or
C/C++ are goto's with implied labels.
As Mikhail said, goto's can be great to break out of nested loops (only a
handful of languages support named 'breaks').
So, instead of:
bool found = false;
for (int i = 0; i = ...; ++i)
{
for (int h = 0; h = ...; ++h)
{
if (some_condition)
found = true;
}
if (found) break;
}
You can have:
for (int i = 0; i = ...; ++i)
{
for (int h = 0; h = ...; ++h)
{
if (some_condition)
goto found;
}
}
// not found
found:
// handle found
The second is better for a number of reasons: it's clearer. It has fewer
variables (smaller stack), it has fewer branches (better for the CPU's
branch prediction), and it has fewer instructions (better for CPU
instruction cache). This is a trivial, contrived example, but I've seen
more than 4x nested loops using an exit flag like this (at every level of
the loops) that could have been replaced with a lot less code.
People need to stop drinking "X is considered harmful." Even Dijkstra later
lamented that his "Goto considered harmful" paper was misinterpreted and
misrepresented as advocating that goto should never be used.
Additionally, I'd recommend everyone read '"Considered Harmful" Essays
Considered Harmful': http://meyerweb.com/eric/comment/chech.html
Regards,
Nate
Here are recent related discussions about exiting from
nested loops (at least seems to be so):
https://mail.python.org/pipermail/python-ideas/2017-March/044932.html
https://mail.python.org/pipermail/python-ideas/2017-March/045049.html
I personally have difficulties to fully understand some
of the examples given in those proposals, namely
that proposals were thought for other(?) purposes also,
not only breaking nested loops.
At a first glance it seems to me that "goto" would solve
the nested breaking problem and in a nice flexible way.
(correct me if I am wrong, probably I'm missing something)
So besides nested loops, in my practice I had occasions
when I would want to use "goto".
It would be fair to say that those occasions are not so common,
but I'll try to give an example. Say, there is some
pure procedural processing for some simple task
and I don't want to make the script heavy and just
care for the clarity:
===
Log = ""
S = "lorem ipsum"
for s in S:
if s == "i" :
message = "found on stage 1"
goto .output
S = S + " hello world"
for s in S:
if s == "d" :
message = "found on stage 2"
goto .output
print "not found"
print "S = ", S
goto .exit
.output
print message
Log = Log + message
.exit:
print "exiting"
=
For me it looks clear and I'd say easy to comprehend,
Main critic would be obviously that it is not
a good, *scalable application*, but quite often I don't
even have this in mind, and just want to express a
step-by-step direct instructions.
In this case sticking any "def():.." inside the script
does not make any sense for me. Simplicity here
reflects the fact that this code represents
exactly what I want the computer to do.
And a working variant of this would be like:
===
Log = ""
found = False
Error = False
S = "lorem ipsum"
if not found:
for s in S:
if s == "i" :
message = "found on stage 1"
found = True
if not found:
S = S + " hello world"
for s in S:
if s == "d" :
message = "found on stage 2"
found = True
if not found:
Error = True
print "Error : not found"
print "S = ", S
if not Error:
print message
Log = Log + message
print "exiting"
==
This is working code, but I would say there is
a lot extra indentation, and if I don't care about
application scalability, those are just adding noise
and I it needs some boolean flags.
I am not sure what examples to add here ...
it seems to me that e.g. if I would use Python
for modelling "pipeline" algorithms
this could be helpful also.
Now if I count in the nested loops breaking problematic,
seems that there is at least a prerequisite for existence of "goto".
Am I right?
Mikhail
def finder:
for s in S:
if s == 'i':
return 'found on stage 1'
S = S + ' hello world'
for s in S:
if s == 'd':
return 'found on stage 2'
raise ValueError('not found; S=' + S)
try:
message = finder()
print(message)
log += message
except ValueError as e:
print(e)
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Merging multiple sorted sequences.
Hi Ian, On 13/04/17 00:09, Erik wrote: On 12/04/17 23:44, Ian Kelly wrote: I would just use "lowest = min(items, key=itemgetter(0))". I had it in my head for some reason that min() would return the smallest key, not the object (and hence I wouldn't be able to know which sequence object to get the next value from - sorting means it's always at index 0). Actually, no, that wasn't my issue. It was that I don't know the index of the source to 'del'ete from the list when it has exhausted. The code always deletes item 0 and my test sequences are such that they happen to exhaust in first to last order, so that works by accident. If you swap the definitions of the 'a', 'b', and 'c' test data, then it all goes horribly wrong with the "min()" change. However, I can use the 'remove' method on the items list to delete that element instead. It's going to do a linear search of the list to find the correct element, but I expect the number of sources to be trivially small compared to the amount of data in each, so for my specific case that should be OK. Thanks, E. -- https://mail.python.org/mailman/listinfo/python-list
Re: What is the difference between x[:]=y and x=y[:]?
Peter Otten at 2017/4/12 UTC+8 PM 8:13:53 wrote: > I should add that you can write > > lr = [[1], [0]] > lx = [] > for i in range(len(lr)): > > ... lx = lr[i][:] > > ... lx.append(0) > > ... lr[i].append(1) > > ... lr.append(lx) > > ... > lr > >[[1, 1], [0, 1], [1, 0], [0, 0]] > > > > idiomatially as > > >>> lr = [[1], [0]] > >>> [inner + tail for tail in [[1], [0]] for inner in lr] > [[1, 1], [0, 1], [1, 0], [0, 0]] > > Note that there is a difference -- the resulting list does not share any > lists with the original `lr` as concatenating two lists produces a new one: > > >>> a = [1] > >>> b = [2] > >>> c = a + b > >>> a is c > False > >>> b is c > False I was a little embarrassed when looking at my codes. It may take me a long time to get used to thinking in the "Pythonic" way:-( But definitely I have learned much from this forum:-) -- https://mail.python.org/mailman/listinfo/python-list
Python Command Line Arguments
I have this code which I got from
https://www.tutorialspoint.com/python/python_command_line_arguments.htm The
example works fine but when I modify it to what I need, it only half works. The
problem is the try/except. If you don't specify an input/output, they are blank
at the end but it shouldn't be.
import getopt
import sys
def main(argv):
inputfile = ''
outputfile = ''
try:
opts, args = getopt.getopt(argv,"hi:o:",["ifile=","ofile="])
except getopt.GetoptError:
inputfile = 'Input'
outputfile = 'Output'
if inputfile == '':
for opt, arg in opts:
if opt == '-h':
print ('Usage: Encrypt.py -i -o ')
sys.exit()
elif opt in ("-i", "--ifile"):
inputfile = arg
elif opt in ("-o", "--ofile"):
outputfile = arg
else:
''
print 'In: ' + inputfile
print 'Out: ' + outputfile
if __name__ == "__main__":
main(sys.argv[1:])
--
https://mail.python.org/mailman/listinfo/python-list
homework confusion
Hello! So I have a homework assignment that I can't seem to understand. The
problems are talking about classes and subclasses. My issue is that the
examples use objects as arguments and I don't know how to make that happen
without getting a name error. The question is:
Create a subclass of Openable called Lockable for representing physical objects
that can be unlocked and opened. Remember to make sure that Lockable is a
subclass of Openable. In addition to the methods and attributes it
automatically inherits from Openable and Thing, it should have:
A public boolean attribute called is_locked that represents whether or not the
object is locked.
A public attribute called key which is a Thing object that represents the item
that can be used as akey to unlock the Lockable object.
An overridden constructor that takes two strings (the name and the location), a
Thing (the key), and two optional boolean values (first, whether the object
starts off open and second, whether it starts out locked). If neither of the
optional boolean values are given, then the object should default to being
closed but not locked. If only the first of the optional arguments (the
starting "openness" state) is given, then the object should start out unlocked.
Your version of .__init__() for Lockable must use the version of .__init__()
from the superclass Openable to handle the name, location, and "openness"
state. Setting the is_locked and key attributes are the only ones you need to
handle separately.
So you should be able to create Lockable objects with commands* like
Lockable("front door", "in the foyer", house_key, False, True) (returning an
object that starts out closed and locked), or Lockable("diary", "under Sam's
bed", tiny_key, True) (returning an object that starts out open and unlocked),
or Lockable("ancient treasure chest", "at the bottom of the sea", rusty_key)
(returning an object that starts out closed and unlocked).
*Assuming that the variables house_key, tiny_key, and rusty_key already exist
and refer to instances of Things.
My code is:
class Thing:
"""represents physical objects in a game
attributes: name(str), location(str)"""
def __init__(self, name, location):
"""creates a Thing with a name and location
str, str"""
self.name = name
self.location = location
def __repr__(self):
"""returns the Thing as a string that could be used to create a Thing
None-> str"""
return "Thing(" + self.name + ", " + self.location + ")"
def description(self):
"""returnd the Thing along with its name and location in a string
None -> str"""
return "The " + repr(self.name) + " is " + repr(self.location) + "."
class Openable(Thing):
"""representing the Things that can be opened
attributes: name(str), location(str), is_open(str)"""
def __init__(self, name, location, is_open = False):
"""creates a Thing with a name and location
str, str"""
Thing.__init__(self, name, location)
self.is_open = is_open
def __repr__(self):
"""returns the Thing as a string that could be used to create an
Openable
None-> str"""
return "Openable('" + self.name + "', '" + self.location + "', '" +
str(self.is_open) + "')"
def description(self):
"""returnd the Thing along with its name and location and whether it is
open in a string
None -> str"""
if self.is_open == True:
opened = "is open"
else:
opened = "is closed"
return "The " + self.name + self.location + " is " + opened + "."
def try_open(self):
"""tries to open the Openable and returns the result
None -> bool"""
if self.is_open == True:
return False
if self.is_open == False:
self.is_open = True
return True
class Lockable(Openable):
"""respresents the Openable Things that are Lockable
attributes: name(str), location(str), is_open(str), is_locked(str),
key(str)"""
def __init__(self, name, location, key, is_open = False, is_locked = False):
"""creates a Thing with a name and location
str, str"""
Openable.__init__(self, name, location, is_open = False)
self.is_locked = is_locked
def __repr__(self):
"""returns the Thing as a string that could be used to create an
Lockable
None-> str"""
return "Lockable('" + self.name + "', '" + self.location + "', '" +
str(self.is_open) + "', '" + str(self.is_locked) + "')"
def description(self):
"""returnd the Thing along with its name and location and whether it is
open in a string and whether it is locked
None -> str"""
if self.is_open == True:
opened = "is open"
return "The " + self.name + self.location + " is " + opened + "."
elif self.is_open == Flase:
opened = "is closed"
i
Re: Python Command Line Arguments
> > I have this code which I got from https://www.tutorialspoint. > com/python/python_command_line_arguments.htm The example works fine but > when I modify it to what I need, it only half works. The problem is the > try/except. If you don't specify an input/output, they are blank at the end > but it shouldn't be. > > import getopt > import sys > Hello Ian, I am guessing you are wanting to parse command-line arguments rather than particularly wanting to use the getopt module. If I am correct you might want to spend your time instead learning the argparse module: https://docs.python.org/3/library/argparse.html https://docs.python.org/3/howto/argparse.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Merging multiple sorted sequences.
On 4/12/2017 7:15 PM, Erik wrote: Hi Peter, On 12/04/17 23:42, Peter Otten wrote: Erik wrote: I need to be able to lazily merge a variable number of already-sorted(*) variable-length sequences into a single sorted sequence. https://docs.python.org/dev/library/heapq.html#heapq.merge AFAICT (looking at the Python 3.5 heapq implementation, albeit very briefly), it seems like that is a greedy algorithm. Am I missing something? Yes. Read the source to see what it does and why one or more inputs could be infinite iterators. Hint: it does *not* heapify everything at once. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Moderating the list [was: Python and the need for speed]
> > However, it's simply a technical fact: the thing which we moderate is the >> mailing list. We can control which posts make it through from the newsgroup >> by blocking them at the gateway. But the posts will continue to appear on >> comp.lang.python which is, as the description says, unmoderated. >> > > TJG Thank you, Tim and Ethan and the other moderators, for performing that function. It makes the reading experience more pleasant for me. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Command Line Arguments
On 2017-04-13 02:59, ian.steg...@gmail.com wrote:
I have this code which I got from
https://www.tutorialspoint.com/python/python_command_line_arguments.htm The
example works fine but when I modify it to what I need, it only half works. The
problem is the try/except. If you don't specify an input/output, they are blank
at the end but it shouldn't be.
import getopt
import sys
def main(argv):
inputfile = ''
outputfile = ''
try:
opts, args = getopt.getopt(argv,"hi:o:",["ifile=","ofile="])
except getopt.GetoptError:
inputfile = 'Input'
outputfile = 'Output'
if inputfile == '':
for opt, arg in opts:
if opt == '-h':
print ('Usage: Encrypt.py -i -o ')
sys.exit()
elif opt in ("-i", "--ifile"):
inputfile = arg
elif opt in ("-o", "--ofile"):
outputfile = arg
else:
''
print 'In: ' + inputfile
print 'Out: ' + outputfile
if __name__ == "__main__":
main(sys.argv[1:])
You'll get the GetoptError exception if an option that requires an
argument doesn't have one. That's not the same as omitting the option
entirely.
For example:
# No -i option.
foo
# Option -i present but without its required argument.
foo -i
--
https://mail.python.org/mailman/listinfo/python-list
Re: homework confusion
>
> The example command is: Lockable("diary", "under Sam's bed", tiny_key,
> True)
>
> And I keep getting a NameError: tiny_key is not defined.
>
> What do I do?
>
Without knowing what your professor intends this is a guess: define
tiny_key. For example
tiny_key = "some string"
thing = Lockable("diary", "under Sam's bed", tiny_key, True)
or
tiny_key = 1234
thing = Lockable("diary", "under Sam's bed", tiny_key, True)
Maybe in the next assignment the professor will ask you to collect by key
the Lockables that you construct.
--
https://mail.python.org/mailman/listinfo/python-list
Re: homework confusion
On 2017-04-13 03:13, Lauren Fugate wrote:
[snip]
Read the last 2 paragraphs again:
""So you should be able to create Lockable objects with commands* like
Lockable("front door", "in the foyer", house_key, False, True)
(returning an object that starts out closed and locked), or
Lockable("diary", "under Sam's bed", tiny_key, True) (returning an
object that starts out open and unlocked), or Lockable("ancient treasure
chest", "at the bottom of the sea", rusty_key) (returning an object that
starts out closed and unlocked).
*Assuming that the variables house_key, tiny_key, and rusty_key already
exist and refer to instances of Things.
"""
It gives """Lockable("diary", "under Sam's bed", tiny_key, True)""" as
an _example_ of how it would be used.
The final sentence is also important.
Try defining 'tiny_key' before testing the example.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Merging multiple sorted sequences.
On 12Apr2017 23:15, Erik wrote: I need to be able to lazily merge a variable number of already-sorted(*) variable-length sequences into a single sorted sequence. The merge should continue until the longest sequence has been exhausted. (*) They may in practice be a lazy source of data known to only ever be generated in an order that's "sorted" from the POV of this function. I have the following - can anyone think of any improvements (other than indentation style on the try/excepts ;) )? This seems like the sort of thing for which there might be a built-in or recipe that I've missed. It can be improved. The big cost in yours is notionally the sort, which you do on every yield. For comparison, here's mine: https://bitbucket.org/cameron_simpson/css/src/tip/lib/python/cs/seq.py?fileviewer=file-view-default#seq.py-131 It keeps a heap (see the "heapq" standard module) containing tuples of the latest item from each source and the source iterable i.e. (item, iterable). That way the lowest item is always first on the heap, so you pop it off, which gets you (item, iterable). Yield the item. Fetch the next item from iterable. If that gets StopIteration, that is exhausted. Otherwise insert the new item and the iterable back into the heap. Repeat until the heap is empty. In this way you discard exhausted iterables and never need to re-examine them, and the sorting overhead is just heap insertion which is O(log n) for the heap size. Your method is O(n log n) for each item (sorting the collection of head items). The heap is faster because it makes a much weaker ordering guarentee, and for us the feature is that the front of the heap is the lowest item; the rest of the heap is partially ordered, not fully ordered. Insert and pop preserve that criterion. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Command Line Arguments
On Thursday, April 13, 2017 at 12:38:48 PM UTC+10, MRAB wrote:
> On 2017-04-13 02:59, ian.steg...@gmail.com wrote:
> > I have this code which I got from
> > https://www.tutorialspoint.com/python/python_command_line_arguments.htm The
> > example works fine but when I modify it to what I need, it only half works.
> > The problem is the try/except. If you don't specify an input/output, they
> > are blank at the end but it shouldn't be.
> >
> >
> > import getopt
> > import sys
> >
> > def main(argv):
> > inputfile = ''
> > outputfile = ''
> > try:
> >opts, args = getopt.getopt(argv,"hi:o:",["ifile=","ofile="])
> > except getopt.GetoptError:
> >inputfile = 'Input'
> >outputfile = 'Output'
> > if inputfile == '':
> >for opt, arg in opts:
> > if opt == '-h':
> > print ('Usage: Encrypt.py -i -o ')
> > sys.exit()
> > elif opt in ("-i", "--ifile"):
> > inputfile = arg
> > elif opt in ("-o", "--ofile"):
> > outputfile = arg
> > else:
> >''
> >
> > print 'In: ' + inputfile
> > print 'Out: ' + outputfile
> >
> > if __name__ == "__main__":
> > main(sys.argv[1:])
> >
> You'll get the GetoptError exception if an option that requires an
> argument doesn't have one. That's not the same as omitting the option
> entirely.
>
> For example:
>
> # No -i option.
> foo
>
> # Option -i present but without its required argument.
> foo -i
WOW. Thanks for that.
--
https://mail.python.org/mailman/listinfo/python-list
Re: closing image automatically in for loop , python
> On Apr 12, 2017, at 7:18 AM, Masoud Afshari wrote:
>
> Dear all
>
> I have several *.sfd files which created by a simulation code. I wrote a
> program containing a for Loop which reads each time one .sfd file and plot
> the requested Parameters. I have two request:
>
> 1- my Problem is that for Showing successive Images in for Loop I have to
> Close the Image MANAULLY each time to read next sdf file. can anyone please
> tell me which command do I have to use so the code Close the Images
> automatically.
>
I normally run matplolib in interactive mode, so this may not be quite correct,
BUT I think you only need to add a call to:
close()
After your call to plt.show()
Bill
> 2- more over, can anyone please tell me how can I create a movie with this
> code.
>
> in the following you can see my code
>
>
> #
> # in this program, PYTHON reads the reduced files and plot the variables .
>
>
> import sys
> import sdf
> import numpy as np
> import matplotlib.pyplot as plt
> from matplotlib.font_manager import FontProperties
> fp = FontProperties('Symbola')
>
> # information from EPOCH input.deck
> nx,ny= 1200, 1600
>
> xmin=-100e-6
> xmax = 50e-6
> ymin = -100e-6
> ymax = 100e-6
>
> X =np.linspace(xmin,xmax,nx) #Generate linearly spaced vector. The spacing
> between the points is (x2-x1)/(n-1).
> Y =np.linspace(ymin,ymax,ny)
>
> #
> for n in range(0,27):
> nstr = str(n)#.zfill(4)
> #print nstr
>
> ##
> fig = plt.figure() #plot several figures simultaneously
>
> . reading Ex
>
> filename ="Ex_resample" +'_sdf_'+ str(n)+'.dat'
> with open(filename, 'rb') as f: #read binary file
> data = np.fromfile(f, dtype='float64', count=nx*ny) #float64 for Double
> precision float numbers
> Ex = np.reshape(data, [ny, nx], order='F')
> #print Ex.max()
>
> #Display image with scaled colors:
> plt.subplot(222)
> fig1=plt.imshow(Ex, extent=[X.min()*1e6, X.max()*1e6, Y.min()*1e6,
> Y.max()*1e6], vmin=0, vmax=2e12, cmap='brg', aspect='auto') #cmap='jet',
> 'nipy_spectral','hot','gist_ncar'
> #plt.suptitle('Ex')
> plt.title('sdf '+ str(n)+ '; Time= ' +str(n*50)+ 'ps',color='green',
> fontsize=15)
> plt.xlabel('x($\mu$m)')
> plt.ylabel('y($\mu$m)')
> plt.text(40,80,'Ex',color='red', fontsize=15)
> plt.colorbar()
> plt.show()
> #fig.savefig('test.jpg')
> sys.exit()
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
Brecht Machiels writes: > However, rinohtype is located in a very different niche and it would > greatly benefit a lot from a speed boost. Rendering the Sphinx > documentation (311 pages) takes almost 10 minutes on my i7 Yikes... > As for moving to a compiled language (Nim or Rust would be interesting > choices, IMO), it doesn't make much sense. Have you tried PyPy? Thought about Lisp? Lisp is easily extensible and goes well with the DSL idea. Or if most of the time is used in some hot loop, maybe a small C extension is the simplest fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
Marko Rauhamaa writes: > Traditionally, disk access in Linux has been considered nonblocking. > There is AIO, but that hasn't been used much. AIO is asynchronous but it's for dealing with already-opened files. There doesn't seem to be a way to asynchronously OPEN a file. > I believe the lack of asynchronous disk I/O is related to the grand > Solaris idea which Linux adopted: all memory is on a disk and RAM is > merely a cache. And I thought Solaris's heritage involved NFS, with its notorious infinite hard hangs if something happened on the server end. > As swapping is no longer considered normal on modern computers, the > memory-disk duality doesn't seem all that practical anymore. Rather, > you'd like to treat the disk analogously to network access and keep RAM > access separate. Yep. But opening disk files that way seems to require threads or extra processes. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
Michael Torrie writes: > Equivalent to the JNI and Lisp FFI is the CFFI [1]. The JNI, the FFI, > and the CFFI, are all for calling native code from within their > respective languages, if I understand correctly. They don't define a > standard way for native code to call into these languages. They often do, and at least the JNI does. Some general issues are discussed here: http://autocad.xarch.at/lisp/ffis.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Merging multiple sorted sequences.
Erik writes: > I need to be able to lazily merge a variable number of > already-sorted(*) variable-length sequences If the number of sequences is large, the traditional way is with the heapq module. -- https://mail.python.org/mailman/listinfo/python-list
Visit All URLs with selenium python
browser.get('https://www.google.co.uk/search?q=Rashmi&oq=Rashmi&aqs=chrome..69i57j69i60l3.6857j0j1&sourceid=chrome&ie=UTF-8#q=Rashmi+Custom+Tailors')
time.sleep(5)
try:
p_links = browser.find_elements_by_css_selector('div > h3 > a')
url_list = []
for urls in p_links:
if "Rashmi Custom Tailors" in urls.text:
url = urls.get_attribute("href")
url_list.append(url)
for url in url_list:
browser.get(url)
time.sleep(4)
it just visit first url not all .. Can anybody help how to fix that..
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
bart4...@gmail.com writes: > On Wednesday, 12 April 2017 16:50:01 UTC+1, Jussi Piitulainen wrote: >> bart4...@gmail.com writes: >> >> > On Wednesday, 12 April 2017 12:56:32 UTC+1, Jussi Piitulainen wrote: >> >> bartc writes: >> >> >> > >> >> > These are straightforward language enhancements. >> >> >> >> FYI, the question is not how to optimize the code but how to prevent >> >> the programmer from writing stupid code in the first place. Someone >> >> suggested that a language should do that. >> > >> > The 'stupid code' thing is a red herring. I assume the code people >> > write is there for a reason. >> >> So you walked in to a conversation about something that does not >> interest you and simply started talking about your own thing. >> >> Because of course you did. >> >> I get confused when you do that. > > Huh? The subject is making Python faster. It's generally agreed that > being very dynamic makes that harder, everything else being equal. Amazingly, the references in this part of the thread work all the way back to the point were you joined in. Let me quote extensively from the message to which you originally followed up. I lay it out so that I can add some commentary where I point out that the topic of the discussion at that point is whether a programming language should prevent people from writing bad code. [Rick Johnson, quoted by Steven D'Aprano] | high level languages like Python should make it difficult, if not | impossible, to write sub-optimal code (at least in the blatantly | obvious cases). That's the topic of the discussion at that point: whether it should be difficult to *write* bad code in the language. I don't know what else Rick may have said in his message, but Steven chose that topic for that message. Not whether a language should be such that the compiler could produce efficient code, or whether the compiler should be such that it could produce efficient code even if the language makes it a challenge, but whether it should be difficult to write blatantly sub-optimal code. [Steven D'Aprano, in response] | You mean that Python should make it impossible to write: | |near_limit = [] |near_limit.append(1) |near_limit = len(near_limit) | | instead of: | |near_limit = 1 | | ? I look forward to seeing your version of RickPython that can | enforce that rule. You snipped that. Steven asks whether Rick really thinks that Python should prevent that code from being written. Steven also pointed out that this example came from some actual code :) [*I* snipped that.] It's not a question how to produce efficient code for that, or how Python prevents the compiler from producing optimal code. It's a question of the compiler rejecting the code. Traceback (most recent call last): File "/dev/fd/63", line 37, in SanityClauseException: code is blatantly sub-optimal As far as I know, no language does that. Because reasons? [Steven D'Aprano, in response] | Here's another example: | |answer = 0 |for i in range(10): | answer += 1 | | instead of | |answer = 10 | | So... how exactly does the compiler prohibit stupid code? That was Steven's second example, which Steven again used to ask Rick whether or how he really thinks the compiler should prohibit such code. (I have no idea whether that discussion has continued in other branches of the thread, or whether Rick really thinks that, but he seemed to be saying something like that.) You chose to comment on that example, but I think you chose to ignore the question of prohibition altogether, even though that was the question in this particular exchange between Rick and Steven. You went on to address the actual compilation challenges instead. It's a valid topic but it's a different topic. It fits under the subject line, but not in response to that particular message. Those example snippets were intended as a *different kind of challenge*. That's why your original response had me confused, briefly, and then irritated, slightly. That's all. -- https://mail.python.org/mailman/listinfo/python-list
RE: Visit All URLs with selenium python
Nicole wrote, on Wednesday, April 12, 2017 9:49 PM
>
> browser.get('https://www.google.co.uk/search?q=Rashmi&oq=Rashm
> i&aqs=chrome..69i57j69i60l3.6857j0j1&sourceid=chrome&ie=UTF-8#
q=Rashmi+Custom+Tailors')
> time.sleep(5)
>
> try:
> p_links =
> browser.find_elements_by_css_selector('div > h3 > a')
> url_list = []
> for urls in p_links:
> if "Rashmi Custom Tailors" in urls.text:
>
> url = urls.get_attribute("href")
> url_list.append(url)
> for url in url_list:
> browser.get(url)
> time.sleep(4)
>
>
> it just visit first url not all .. Can anybody help how to fix that..
You don't say what module you're using and it would help to see the
"import ..." statement.
But there are a couple things I can think of that could be causing the
problem:
There's only one result with the exact phrase "Rashmi Custom
Tailors" on
the page.
or
The css_selector('div > h3 > a') only occurs for the first
result and
selectors for subsequent results are different. I've seen that
before. If
the div extends all the way down the list until after the last
result,
the results after the first one might have css_selector('h3 >
a'), but
I'm just guessing about how they might be different.
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
Calling dunder methods manually
Should you call dunder methods (Double leading and trailing UNDERscores) manually? For example: my_number.__add__(another_number) The short answer is: NO! In general, you shouldn't do it. Guido recently commented: I agree that one shouldn't call __init__ manually (and in fact Python always reserves the right to have "undefined" behavior when you define or use dunder names other than documented). so unless documented as safe to use manually, you should assume that it is not. https://github.com/python/typing/issues/241#issuecomment-292694838 This-Public-Service-Announcement-Brought-To-You-By-MyPy-ly y'rs, -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Visit All URLs with selenium python
from selenium.webdriver.firefox.firefox_profile import FirefoxProfile import random from selenium import webdriver from selenium.webdriver.common.keys import Keys -- https://mail.python.org/mailman/listinfo/python-list
Re: Visit All URLs with selenium python
Hi Deborah, I checked again selecting css there found 11 URLS and I printed it is printing all urls but it visits the first url not all.. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
bart4...@gmail.com wrote: (Although I think Python would have difficulty in turning x+=1 into a single opcode, if using normal object references and a shared object model.) The ADD_ONE opcode would have to be defined to have the same effect as the sequence emitted for x+=1, including all the dynamic lookups, so the only speed advantage would be eliminating a few trips around the bytecode fetch-decode-execute loop. Which could still be worthwhile, if experience with the wordcode interpreter is anything to go by. There was also a project that attempted to find frequently used sequences of opcodes and create specialised opcodes for them, which reportedly had some success as well. The logic behind these approaches is that unpredictable branches, such as the opcode switch in the ceval loop, are expensive on modern architectures, so eliminating as many of them as possible can be a win. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Calling dunder methods manually
On Thursday, April 13, 2017 at 11:00:03 AM UTC+5:30, Steven D'Aprano wrote: > Should you call dunder methods (Double leading and trailing UNDERscores) > manually? For example: > > > my_number.__add__(another_number) > > > The short answer is: > > NO! In general, you shouldn't do it. > > > Guido recently commented: > > I agree that one shouldn't call __init__ manually (and in fact Python > always reserves the right to have "undefined" behavior when you > define or use dunder names other than documented). > > > so unless documented as safe to use manually, you should assume that it > is not. > > > https://github.com/python/typing/issues/241#issuecomment-292694838 > > > > This-Public-Service-Announcement-Brought-To-You-By-MyPy-ly y'rs, > > > > > -- > Steve I believe it was ChrisA who gave a pithy summary of the situation: Dont CALL dunders But its fine to DEFINE them -- https://mail.python.org/mailman/listinfo/python-list
Re: Merging multiple sorted sequences.
Erik wrote:
> Hi Peter,
>
> On 12/04/17 23:42, Peter Otten wrote:
>> Erik wrote:
>>
>>> I need to be able to lazily merge a variable number of already-sorted(*)
>>> variable-length sequences into a single sorted sequence.
>>
>> https://docs.python.org/dev/library/heapq.html#heapq.merge
>
> AFAICT (looking at the Python 3.5 heapq implementation, albeit very
> briefly), it seems like that is a greedy algorithm. Am I missing
> something?
>
> Thanks, E.
Watching it at work:
>>> import heapq
>>> def noisy(items, source):
... for item in items:
... print("fetching", item, "from", source)
... yield item
...
>>> a = noisy(range(0, 10, 2), "a")
>>> b = noisy(range(1, 10, 2), "b")
>>> c = noisy([3.5, 3.6, 5.5], "c")
>>> abc = heapq.merge(a, b, c)
>>> next(abc)
fetching 0 from a
fetching 1 from b
fetching 3.5 from c
0
>>> next(abc)
fetching 2 from a
1
>>> next(abc)
fetching 3 from b
2
>>> next(abc)
fetching 4 from a
3
>>> next(abc)
fetching 5 from b
3.5
>>> next(abc)
fetching 3.6 from c
3.6
Verdict: not greedy ;)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Visit All URLs with selenium python
Here you can see now
from selenium.webdriver.firefox.firefox_profile import FirefoxProfile
import random
from selenium import webdriver
from selenium.webdriver.common.keys import Keys
browser.get('https://www.google.co.uk/search?q=Rashmi&oq=Rashmi&aqs=chrome..69i57j69i60l3.6857j0j1&sourceid=chrome&ie=UTF-8#q=Mobiles+in+london')
time.sleep(5)
try:
p_links = browser.find_elements_by_css_selector(' div > h3 > a')
url_list = []
for urls in p_links:
if "London" in urls.text:
urls.get_attribute("href")
url_list.append(urls)
for links in url_list:
browser.get(links)
time.sleep(4)
except:
browser.close()
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
Jussi Piitulainen wrote: Traceback (most recent call last): File "/dev/fd/63", line 37, in SanityClauseException: code is blatantly sub-optimal As far as I know, no language does that. Because reasons? Because the problem of making a compiler do that is probably AI-complete! -- Greg -- https://mail.python.org/mailman/listinfo/python-list
RE: Visit All URLs with selenium python
Nicole wrote, on Wednesday, April 12, 2017 11:03 PM > > from selenium.webdriver.firefox.firefox_profile import > FirefoxProfile import random from selenium import webdriver > from selenium.webdriver.common.keys import Keys Ok, that gives us a clue what you're working with, which will probably help with something. Since your code works, I'm guessing your use of selenium is probably ok. I'd be looking for structural issues in the HTML for reasons why you're not getting what you want to get. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wed, 12 Apr 2017 14:38:52 +0100, Ben Bacarisse wrote: > Steve D'Aprano writes: > >> On Wed, 12 Apr 2017 03:39 am, Paul Rubin wrote: >> >>> I still do my everyday stuff in Python and I'd like to get more >>> conversant with stuff like numpy, but it feels like an old-fashioned >>> language these days. >> >> "Old fashioned"? With await/async just added to the language, and type >> annotations? And comprehensions and iterators? >> >> Admittedly type annotations are mostly of interest to large projects >> with many developers and a huge code base. But the rest? >> >> Comprehensions may have been around for a decade or two in Haskell, but >> most older languages don't have them. I'm pretty sure Java doesn't. >> Does Javascript? Comprehensions feel like a fancy new language feature >> to me. > > They've been in in Haskell for nearly three decades, but they were > around before that. Miranda had them, as did Miranda's immediate > predecessor, KRC. KRC dates from about 1980, so if you've been using > that lineage of languages, list comprehensions have been a standard > feature for 37 years. I've been using them almost my entire programming > life. Indeed, and this is a very common phenomenon: features which "ordinary" programmers imagine are "trendy" and new end up having their roots in some functional language dating back to the 1980s, or 70s, or in extreme cases the 1950s and Lisp. That's what I meant: even though Haskell has had comprehensions for decades, they haven't hit "mainstream" procedural languages (Java, Javascript, C) at all or until recently. Python's had them for a decade or more (how time flies...) but they still to this day get reactions from many Python programmers like "I don't get these fancy new list comprehensions, what's wrong with an old-fashioned for-loop?" (not quoting anyone in particular, although Bart did specifically mention he didn't grok comprehensions). > It seems odd that ECMAScript (the JavaScript standard) does not have > them, but then JS seems to hide its function nature under an imperative > bushel. > > Just another perspective... Thanks. I knew comprehensions have been around for a while, I didn't realise they went back to Miranda and even older. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Deborah Swanson wrote: > It's a small point, but I suspect getattr(record, label) would still > fail, even if label's value is 'label' and only 'label', but what's the > point of having a variable if it will only ever have just one value? You are misunderstanding. Your getattr() call fails because you have label = "label" burried somewhere in your code. As soon as you change that to label = the error will go away. -- https://mail.python.org/mailman/listinfo/python-list
RE: Visit All URLs with selenium python
Nicole wrote, on Wednesday, April 12, 2017 11:05 PM > > Hi Deborah, >I checked again selecting css there found 11 URLS and I > printed it is printing all urls but it visits the first url not all.. I'm just guessing again, but time.sleep(4) could be too long a time to sleep, especially if you're on a fast network and you don't have many browser windows open before you run your code. It might be opening the first url and printing all the others and exiting the for loop before time.sleep(4) expires. -- https://mail.python.org/mailman/listinfo/python-list
RE: Visit All URLs with selenium python
Nicole wrote, on Wednesday, April 12, 2017 11:05 PM > > Hi Deborah, >I checked again selecting css there found 11 URLS and I > printed it is printing all urls but it visits the first url not all.. Hmm. Sounds like you've changed your code in some way. Either changing the web page you're pointing to, changing the css selector or something I can't guess, because in your last msg yo said you were seeing just the opposite. -- https://mail.python.org/mailman/listinfo/python-list
