Re: ImportError: cannot import name _remove_dead_weakref
thank you for the advice: depending on the value of PYTHONPATH (version 2.7, 3.5, or unset), tensorflow stops with 3 different error traps 2018-05-04 7:55 GMT+02:00 dieter : > Chris Angelico writes: > > ... > > Somewhere, you have a mismatch of versions. Make sure you're using the > > same Python version for everything. You have some Python 2.7 messing > > up your 3.5. > > I have had similar problems. In my case, an active "PYTHONPATH" envvar > was responsible -- "unset"ting this envar has resolved the problem for me. > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Weird side effect of default parameter
On Thu, 03 May 2018 19:47:37 +, Robert Latest via Python-list wrote: > Hello, > > I don't understand the behavior of the code below. Why does the dict > property "a" of both objects contain the same keys? This is only if > "a=dict" is in the initializer. If I put self.a = dict() into the init > function, I get two separate dicts Python function default values use *early binding*: the default parameter is evaluated, ONCE, when the function is defined, and that value is used each time it is needed. The opposite is *late binding*: the default parameter is not evaluated until it is actually needed, and then re-evaluated each time it is needed. Both approaches have their pros and cons, but early binding is better as the language supported feature, since it is easy to build late binding for yourself: def __init__(self, x, a=None): if a is None: a = dict() self.x = x self.a = a self.a[x] = x whereas if the language used late binding, it would be really difficult to build early binding on top of it. The interaction between early-binding defaults and mutable values like lists and dicts is a well-known "gotcha" (or at least, it is well-known to those of us who have come across it before). It is even a FAQ: https://docs.python.org/dev/faq/programming.html#why-are-default-values- shared-between-objects See also: http://www.effbot.org/zone/default-values.htm -- Steve -- https://mail.python.org/mailman/listinfo/python-list
itemgetter with default arguments
A re-occurring feature request is to add a default to itemgetter and
attrgetter. For example, we might say:
from operator import itemgetter
f = itemgetter(1, 6, default="spam") # proposed feature
f("Hello World!") # returns ('e', 'W')
f("Hello") # returns ('e', 'spam')
Two senior developers have rejected this feature, saying that we should
just use a lambda instead.
I might be slow today, but I cannot see how to write a clear, obvious,
efficient lambda that provides functionality equivalent to itemgetter
with a default value.
Putting aside the case where itemgetter takes multiple indexes, how about
the single index case? How could we get that functionality using a lambda
which is simple and obvious enough to use on the fly as needed, and
reasonably efficient?
Here are the specifications:
* you must use lambda, not def;
* the lambda must take a single function, the sequence you want to
extract an item from;
* you can hard-code the index in the body of the lambda;
* you can hard-code the default value in the body of the lambda;
* if sequence[index] exists, return that value;
* otherwise return the default value;
* it should support both positive and negative indices.
Example: given an index of 2 and a default of "spam":
(lambda seq: ... )("abcd") returns "c"
(lambda seq: ... )("") returns "spam"
I might be missing something horribly obvious, but I can't see how to do
this using a lambda. I tried using slicing:
seq[index:index+1]
which will return either an empty slice or a one-item slice, but that
didn't help me. I feel I'm missing something either obvious, or something
impossible, and I don't know which.
(This isn't a code-golf problem. I care more about being able to do it at
all, than about doing it in the minimum number of characters.)
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
Re: itemgetter with default arguments
On 2018-05-04 15:01, Steven D'Aprano wrote:
> A re-occurring feature request is to add a default to itemgetter and
> attrgetter. For example, we might say:
>
> from operator import itemgetter
> f = itemgetter(1, 6, default="spam") # proposed feature
> f("Hello World!") # returns ('e', 'W')
> f("Hello") # returns ('e', 'spam')
>
>
> Two senior developers have rejected this feature, saying that we should
> just use a lambda instead.
>
> I might be slow today, but I cannot see how to write a clear, obvious,
> efficient lambda that provides functionality equivalent to itemgetter
> with a default value.
>
> Putting aside the case where itemgetter takes multiple indexes, how about
> the single index case? How could we get that functionality using a lambda
> which is simple and obvious enough to use on the fly as needed, and
> reasonably efficient?
>
> Here are the specifications:
>
> * you must use lambda, not def;
>
> * the lambda must take a single function, the sequence you want to
> extract an item from;
>
> * you can hard-code the index in the body of the lambda;
>
> * you can hard-code the default value in the body of the lambda;
>
> * if sequence[index] exists, return that value;
>
> * otherwise return the default value;
>
> * it should support both positive and negative indices.
>
> Example: given an index of 2 and a default of "spam":
>
> (lambda seq: ... )("abcd") returns "c"
>
> (lambda seq: ... )("") returns "spam"
Like this?
>>> spamgetter = (lambda seq, i=2, fallback="spam":
... seq[i] if abs(i) < len(seq) or i == -len(seq)
... else fallback)
>>> spamgetter("abcd", i=-4)
'a'
>>> spamgetter("abcd")
'c'
>>> spamgetter("")
'spam'
>>>
Making this work for sequences AND dict-like objects is more difficult...
>
>
> I might be missing something horribly obvious, but I can't see how to do
> this using a lambda. I tried using slicing:
>
> seq[index:index+1]
>
> which will return either an empty slice or a one-item slice, but that
> didn't help me. I feel I'm missing something either obvious, or something
> impossible, and I don't know which.
>
> (This isn't a code-golf problem. I care more about being able to do it at
> all, than about doing it in the minimum number of characters.)
>
>
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: itemgetter with default arguments
On 04-05-18 15:01, Steven D'Aprano wrote:
> A re-occurring feature request is to add a default to itemgetter and
> attrgetter. For example, we might say:
>
> from operator import itemgetter
> f = itemgetter(1, 6, default="spam") # proposed feature
> f("Hello World!") # returns ('e', 'W')
> f("Hello") # returns ('e', 'spam')
>
>
> Two senior developers have rejected this feature, saying that we should
> just use a lambda instead.
>
> I might be slow today, but I cannot see how to write a clear, obvious,
> efficient lambda that provides functionality equivalent to itemgetter
> with a default value.
>
> Putting aside the case where itemgetter takes multiple indexes, how about
> the single index case? How could we get that functionality using a lambda
> which is simple and obvious enough to use on the fly as needed, and
> reasonably efficient?
>
> Here are the specifications:
>
> * you must use lambda, not def;
>
> * the lambda must take a single function, the sequence you want to
> extract an item from;
>
> * you can hard-code the index in the body of the lambda;
>
> * you can hard-code the default value in the body of the lambda;
>
> * if sequence[index] exists, return that value;
>
> * otherwise return the default value;
>
> * it should support both positive and negative indices.
>
> Example: given an index of 2 and a default of "spam":
>
> (lambda seq: ... )("abcd") returns "c"
>
> (lambda seq: ... )("") returns "spam"
>
>
> I might be missing something horribly obvious, but I can't see how to do
> this using a lambda. I tried using slicing:
>
> seq[index:index+1]
>
> which will return either an empty slice or a one-item slice, but that
> didn't help me. I feel I'm missing something either obvious, or something
> impossible, and I don't know which.
>
> (This isn't a code-golf problem. I care more about being able to do it at
> all, than about doing it in the minimum number of characters.)
This seems to work:
f = (lambda seq: (list(seq) + 3 * ["spam"])[2])
--
https://mail.python.org/mailman/listinfo/python-list
Re: itemgetter with default arguments
On Fri, May 4, 2018 at 7:01 AM, Steven D'Aprano
wrote:
> Here are the specifications:
>
> * you must use lambda, not def;
Why? This seems like an arbitrary constraint.
> * the lambda must take a single function, the sequence you want to
> extract an item from;
>
> * you can hard-code the index in the body of the lambda;
>
> * you can hard-code the default value in the body of the lambda;
>
> * if sequence[index] exists, return that value;
>
> * otherwise return the default value;
>
> * it should support both positive and negative indices.
>
> Example: given an index of 2 and a default of "spam":
>
> (lambda seq: ... )("abcd") returns "c"
>
> (lambda seq: ... )("") returns "spam"
def itemgetter2(*items, default):
return lambda seq: tuple(get_default(seq, item, default) for item in items)
def get_default(seq, item, default):
try:
return seq[item]
except (IndexError, KeyError):
return default
py> f = itemgetter2(1, 6, default="spam")
py> f("Hello World!")
('e', 'W')
py> f("Hello!")
('e', 'spam')
--
https://mail.python.org/mailman/listinfo/python-list
Re: itemgetter with default arguments
On Sat, May 5, 2018 at 1:17 AM, Ian Kelly wrote:
> On Fri, May 4, 2018 at 7:01 AM, Steven D'Aprano
> wrote:
>> Here are the specifications:
>>
>> * you must use lambda, not def;
>
> Why? This seems like an arbitrary constraint.
>
> def itemgetter2(*items, default):
> return lambda seq: tuple(get_default(seq, item, default) for item in
> items)
>
> def get_default(seq, item, default):
> try:
> return seq[item]
> except (IndexError, KeyError):
> return default
>
> py> f = itemgetter2(1, 6, default="spam")
> py> f("Hello World!")
> ('e', 'W')
> py> f("Hello!")
> ('e', 'spam')
PEP 463 wants to say hello.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: itemgetter with default arguments
On Fri, 04 May 2018 09:17:14 -0600, Ian Kelly wrote: > On Fri, May 4, 2018 at 7:01 AM, Steven D'Aprano > wrote: >> Here are the specifications: >> >> * you must use lambda, not def; > > Why? This seems like an arbitrary constraint. You'll have to ask the two core devs. In my post, in the part you deleted, I wrote: Two senior developers have rejected this feature, saying that we should just use a lambda instead. My guess is that they were thinking that there's no need to complicate itemgetter for this use-case when it is just as easy to write up a quick lambda to do the job. For what it's worth, your itemgetter2() is about 1600% slower on my computer than the real thing. I know I didn't specify speed as a requirement, but I mention it because on the bug tracker, the importance of keeping itemgetter fast is stressed. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Tk covering the entire screen
I have a little typing watcher (buggy as can be, nearly 20 years old): https://github.com/smontanaro/python-bits/tree/master/watch It does the trick most of the time, so I ignore the bugs for the most part. I had to drag it out last week after my wrists started flairing up again. I moved it to Py3, and was running it on Linux, but as my desktop machine at work is Windows, I think it was a bit blind to my activity in Windows-only applications. So, I revisited it on Windows. My cover window is a Tk Frame with width and height defined like so: (w, h) = (self.winfo_screenwidth(), self.winfo_screenheight()) Unfortunately, I have three screens, so should have been using (w, h) = (self.winfo_vrootwidth(), self.winfo_vrootheight()) Those calls yield the correct values for w and h (5760 x 1200), but when the watcher tells me it's time to rest, the covering frame only blanks the middle and right hand screens. The left hand screen remains uncovered. (I can't run it under Python 3 on Windows for various reasons, so am running it with 2.7.14 via an Anaconda build.) I suspect this is a Tk issue as much as anything, but this is the only place I know to ask Tk questions. Any ideas? Thx, Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Tk covering the entire screen
I forgot to mention that when running on Linux (displaying back on Windows), the Python 3 version (3.6.4, Tk 8.6) does cover all three screens. The Windows Python 2.7.14 version with Tk 8.5 has problems. -- https://mail.python.org/mailman/listinfo/python-list
Re: itemgetter with default arguments
On Fri, May 4, 2018 at 11:04 AM, Steven D'Aprano wrote: > On Fri, 04 May 2018 09:17:14 -0600, Ian Kelly wrote: > >> On Fri, May 4, 2018 at 7:01 AM, Steven D'Aprano >> wrote: >>> Here are the specifications: >>> >>> * you must use lambda, not def; >> >> Why? This seems like an arbitrary constraint. > > You'll have to ask the two core devs. In my post, in the part you > deleted, I wrote: > > Two senior developers have rejected this feature, saying > that we should just use a lambda instead. > > > My guess is that they were thinking that there's no need to complicate > itemgetter for this use-case when it is just as easy to write up a quick > lambda to do the job. I saw that. I just don't understand why the solution should require a lambda just because that was the word used by a couple of core devs. > For what it's worth, your itemgetter2() is about 1600% slower on my > computer than the real thing. I know I didn't specify speed as a > requirement, but I mention it because on the bug tracker, the importance > of keeping itemgetter fast is stressed. The real thing is written in C. -- https://mail.python.org/mailman/listinfo/python-list
Re: itemgetter with default arguments
On 04/05/18 22:38, Ian Kelly wrote: > On Fri, May 4, 2018 at 11:04 AM, Steven D'Aprano > wrote: >> On Fri, 04 May 2018 09:17:14 -0600, Ian Kelly wrote: >> >>> On Fri, May 4, 2018 at 7:01 AM, Steven D'Aprano >>> wrote: Here are the specifications: * you must use lambda, not def; >>> >>> Why? This seems like an arbitrary constraint. >> >> You'll have to ask the two core devs. In my post, in the part you >> deleted, I wrote: >> >> Two senior developers have rejected this feature, saying >> that we should just use a lambda instead. >> >> >> My guess is that they were thinking that there's no need to complicate >> itemgetter for this use-case when it is just as easy to write up a quick >> lambda to do the job. > > I saw that. I just don't understand why the solution should require a > lambda just because that was the word used by a couple of core devs. > >> For what it's worth, your itemgetter2() is about 1600% slower on my >> computer than the real thing. I know I didn't specify speed as a >> requirement, but I mention it because on the bug tracker, the importance >> of keeping itemgetter fast is stressed. > > The real thing is written in C. > Is it though? https://github.com/python/cpython/blob/a1fc949b5ab8911a803eee691e6eea55cec43eeb/Lib/operator.py#L265 -- https://mail.python.org/mailman/listinfo/python-list
Re: itemgetter with default arguments
On Fri, 04 May 2018 15:27:16 +0200, Antoon Pardon wrote: >> I might be slow today, but I cannot see how to write a clear, obvious, >> efficient lambda that provides functionality equivalent to itemgetter >> with a default value. [...] > This seems to work: > > f = (lambda seq: (list(seq) + 3 * ["spam"])[2]) Yep, I'm definitely slow today. Thanks for that. Of course, it's also pretty slow, nearly as slow as me :-) On my computer, it was about 2000% slower than itemgetter using a moderate sized list (100 items). -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: itemgetter with default arguments
On Fri, 04 May 2018 15:27:02 +0200, Thomas Jollans wrote:
spamgetter = (lambda seq, i=2, fallback="spam":
> ... seq[i] if abs(i) < len(seq) or i == -len(seq)
> ... else fallback)
spamgetter("abcd", i=-4)
> 'a'
spamgetter("abcd")
> 'c'
spamgetter("")
> 'spam'
Doh! Obvious in hindsight. Thanks.
And on my computer, it's only 125% slower than itemgetter.
> Making this work for sequences AND dict-like objects is more
> difficult...
Indeed. At least with dicts you can call .get(). I don't think it is
necessary to have the one lambda handle both sequence and dict cases.
Surely when calling it you know whether or not you are looking at a
sequence or a mapping.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
Re: itemgetter with default arguments
On Fri, 04 May 2018 14:38:54 -0600, Ian Kelly wrote: > On Fri, May 4, 2018 at 11:04 AM, Steven D'Aprano > wrote: [...] >> My guess is that they were thinking that there's no need to complicate >> itemgetter for this use-case when it is just as easy to write up a >> quick lambda to do the job. > > I saw that. I just don't understand why the solution should require a > lambda just because that was the word used by a couple of core devs. If it were up to me, the solution wouldn't require anything beyond itemgetter *wink* In practice, we don't often use itemgetter like this: f = itemgetter(2) result = f(alist) since we could just say result = alist[2] instead. I think the main use- case for itemgetter is as a sort key: alist.sort(key=itemgetter(2)) or perhaps even map (although this will be obsoleted somewhat by list comprehensions): results = map(itemgetter(2), alist) The point being, in these cases, it is inconvenient to have to define a function ahead of time. Hence, a lambda would be the right solution: alist.sort(key=lambda item: ...) rather than having to define the key function ahead of time. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Plot not working
I am new to Python and using it to learn machine learning.
Below is a sample program I am running to plot IRIS data set.
The code runs but no plot comes up. I am not sure what the issue is with the
code.
# Imports
from matplotlib import pyplot as plt
from sklearn.datasets import load_iris
import numpy as np
# load the data with load_iris from sklearn
data = load_iris()
features = data['data']
feature_names = data['feature_names']
target = data['target']
#print("features\n",features)
#print("feature names\n",feature_names)
#print("target\n",target);
#print("data\n",data)
for t,marker,c in zip(range(3),">ox","rgb"):
# plot each class on its own to get different colored markers
plt.scatter(features[target == t,0],
features[target == t,1],
marker=marker,
c=c)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Plot not working
On Friday, May 4, 2018 at 9:13:02 PM UTC-7, Sharan Basappa wrote:
> I am new to Python and using it to learn machine learning.
>
> Below is a sample program I am running to plot IRIS data set.
> The code runs but no plot comes up. I am not sure what the issue is with the
> code.
>
> # Imports
> from matplotlib import pyplot as plt
> from sklearn.datasets import load_iris
> import numpy as np
>
> # load the data with load_iris from sklearn
> data = load_iris()
> features = data['data']
> feature_names = data['feature_names']
> target = data['target']
>
> #print("features\n",features)
> #print("feature names\n",feature_names)
> #print("target\n",target);
> #print("data\n",data)
>
> for t,marker,c in zip(range(3),">ox","rgb"):
> # plot each class on its own to get different colored markers
> plt.scatter(features[target == t,0],
> features[target == t,1],
> marker=marker,
> c=c)
Try adding a call to plt.show() at the end.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Plot not working
On Saturday, 5 May 2018 10:59:13 UTC+5:30, John Ladasky wrote:
> On Friday, May 4, 2018 at 9:13:02 PM UTC-7, Sharan Basappa wrote:
> > I am new to Python and using it to learn machine learning.
> >
> > Below is a sample program I am running to plot IRIS data set.
> > The code runs but no plot comes up. I am not sure what the issue is with
> > the code.
> >
> > # Imports
> > from matplotlib import pyplot as plt
> > from sklearn.datasets import load_iris
> > import numpy as np
> >
> > # load the data with load_iris from sklearn
> > data = load_iris()
> > features = data['data']
> > feature_names = data['feature_names']
> > target = data['target']
> >
> > #print("features\n",features)
> > #print("feature names\n",feature_names)
> > #print("target\n",target);
> > #print("data\n",data)
> >
> > for t,marker,c in zip(range(3),">ox","rgb"):
> > # plot each class on its own to get different colored markers
> > plt.scatter(features[target == t,0],
> > features[target == t,1],
> > marker=marker,
> > c=c)
>
> Try adding a call to plt.show() at the end.
Thanks a lot. That was the issue
--
https://mail.python.org/mailman/listinfo/python-list
