ay to figured out the seeds by rows comparison
and show the bi-groupe results
Many Thanks
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, Jun 23, 2021 at 5:34 AM Dan Stromberg wrote:
>
> I put together a little python runtime comparison, with an embarallel,
> cpu-heavy threading microbenchmark.
>
> It turns out that the performance-oriented Python implementations, Pypy3
> and Nuitka3, are both poor a
I put together a little python runtime comparison, with an embarallel,
cpu-heavy threading microbenchmark.
It turns out that the performance-oriented Python implementations, Pypy3
and Nuitka3, are both poor at threading, as is CPython of course.
On the plus side for CPython, adding cpu-heavy
Sayth Renshaw writes:
>>
>> That actually creates another error.
>>
>> A value is trying to be set on a copy of a slice from a DataFrame.
>> Try using .loc[row_indexer,col_indexer] = value instead
>>
>> See the caveats in the documentation:
>> http://pandas.pydata.org/pandas-docs/stable/indexi
On Tuesday, 10 September 2019 12:56:36 UTC+10, Sayth Renshaw wrote:
> On Friday, 6 September 2019 07:52:56 UTC+10, Piet van Oostrum wrote:
> > Piet van Oostrum <> writes:
> >
> > > That would select ROWS 0,1,5,6,7, not columns.
> > > To select columns 0,1,5,6,7, use two-dimensional indexes
> > >
On Friday, 6 September 2019 07:52:56 UTC+10, Piet van Oostrum wrote:
> Piet van Oostrum <> writes:
>
> > That would select ROWS 0,1,5,6,7, not columns.
> > To select columns 0,1,5,6,7, use two-dimensional indexes
> >
> > df1 = df.iloc[:, [0,1,5,6,7]]
> >
> > : selects all rows.
>
> And that also
That is actually consistent with Excel row, column. Can see why it works that
way then.
Thanks
--
https://mail.python.org/mailman/listinfo/python-list
Piet van Oostrum writes:
> That would select ROWS 0,1,5,6,7, not columns.
> To select columns 0,1,5,6,7, use two-dimensional indexes
>
> df1 = df.iloc[:, [0,1,5,6,7]]
>
> : selects all rows.
And that also solves your original problem.
This statement:
df1['Difference'] = df1.loc['Current Team']
Sayth Renshaw writes:
> On Sunday, 1 September 2019 10:48:54 UTC+10, Sayth Renshaw wrote:
>> I've created a share doc same structure anon data from my google drive.
>>
>> https://drive.google.com/file/d/0B28JfFTPNr_lckxQRnFTRF9UTEFYRUVqRWxCNVd1VEZhcVNr/view?usp=sharing
>>
>> Sayth
>
> I tried
On Sunday, 1 September 2019 10:48:54 UTC+10, Sayth Renshaw wrote:
> I've created a share doc same structure anon data from my google drive.
>
> https://drive.google.com/file/d/0B28JfFTPNr_lckxQRnFTRF9UTEFYRUVqRWxCNVd1VEZhcVNr/view?usp=sharing
>
> Sayth
I tried creating the df1 dataframe by usin
I've created a share doc same structure anon data from my google drive.
https://drive.google.com/file/d/0B28JfFTPNr_lckxQRnFTRF9UTEFYRUVqRWxCNVd1VEZhcVNr/view?usp=sharing
Sayth
--
https://mail.python.org/mailman/listinfo/python-list
On Sunday, 1 September 2019 05:19:34 UTC+10, Piet van Oostrum wrote:
> Sayth Renshaw writes:
>
> > But on both occasions I receive this error.
> >
> > # KeyError: 'the label [Current Team] is not in the [index]'
> >
> > if I test df1 before trying to create the new column it works just fine.
> >
Sayth Renshaw writes:
> But on both occasions I receive this error.
>
> # KeyError: 'the label [Current Team] is not in the [index]'
>
> if I test df1 before trying to create the new column it works just fine.
>
What do you mean by testing df1?
And could it be that 'Current Team' is spelled diff
Sayth Renshaw writes:
>
> I have tried both
>
> df1 = df.loc[:, ('UID','Name','New Leader','Current Team', 'New Team')]
> df1['Difference'] = df1.loc['Current Team'].str.lower().str.strip() ==
> df1.loc['New Team'].str.lower().str.strip()
>
> and
>
> df1 = df[['UID','Name','New Leader','Current
On Friday, 30 August 2019 00:49:32 UTC+10, Piet van Oostrum wrote:
> Piet van Oostrum writes:
>
> > So the correct way to do this is to make df1 a copy rather than a view.
> >
> > df1 = df.loc[:, ('UID','Name','New Leader','Current Team', 'New Team')]
>
> Or maybe even make an explicit copy:
>
On Friday, 30 August 2019 00:49:32 UTC+10, Piet van Oostrum wrote:
> Piet van Oostrum
>
> > So the correct way to do this is to make df1 a copy rather than a view.
> >
> > df1 = df.loc[:, ('UID','Name','New Leader','Current Team', 'New Team')]
>
> Or maybe even make an explicit copy:
>
> df1 =
Piet van Oostrum writes:
> So the correct way to do this is to make df1 a copy rather than a view.
>
> df1 = df.loc[:, ('UID','Name','New Leader','Current Team', 'New Team')]
Or maybe even make an explicit copy:
df1 = df[['UID','Name','New Leader','Current Team', 'New Team']].copy()
--
Piet va
Sayth Renshaw writes:
> Hi
>
> I am importing 4 columns into a dataframe from a spreadsheet.
>
> My goal is to create a 5th column with TRUE or False if column 4 (str)
> matches column 3.
>
> Trying to leverage this answer https://stackoverflow.com/a/35940955/461887
>
> This is my code
>
> impo
Hi
I am importing 4 columns into a dataframe from a spreadsheet.
My goal is to create a 5th column with TRUE or False if column 4 (str) matches
column 3.
Trying to leverage this answer https://stackoverflow.com/a/35940955/461887
This is my code
import pandas as pd
xls = pd.ExcelFile("Melb
On 29/07/2019 12.56, Rob Gaddi wrote:
> On 7/29/19 10:44 AM, Michael F. Stemper wrote:
>> On 28/07/2019 19.04, Chris Angelico wrote:
>>> On Mon, Jul 29, 2019 at 9:48 AM Michael Torrie
>>> wrote:
Yet the recommended solution to the problem of wanting a default
argument of an empty list i
On 7/29/19 10:44 AM, Michael F. Stemper wrote:
On 28/07/2019 19.04, Chris Angelico wrote:
On Mon, Jul 29, 2019 at 9:48 AM Michael Torrie wrote:
On 7/28/19 5:55 AM, Jonathan Moules wrote:
But this appears to be explicitly called out as being "Worse" in PEP8:
"""
Don't compare boolean values
On Tue, Jul 30, 2019 at 3:46 AM Michael F. Stemper
wrote:
>
> On 28/07/2019 19.04, Chris Angelico wrote:
> > On Mon, Jul 29, 2019 at 9:48 AM Michael Torrie wrote:
> >>
> >> On 7/28/19 5:55 AM, Jonathan Moules wrote:
> >>> But this appears to be explicitly called out as being "Worse" in PEP8:
> >>
On 28/07/2019 19.04, Chris Angelico wrote:
> On Mon, Jul 29, 2019 at 9:48 AM Michael Torrie wrote:
>>
>> On 7/28/19 5:55 AM, Jonathan Moules wrote:
>>> But this appears to be explicitly called out as being "Worse" in PEP8:
>>>
>>> """
>>> Don't compare boolean values to True or False using ==.
>>>
On Tue, Jul 30, 2019 at 12:04 AM David Raymond wrote:
> if shell:
> #wait, "shell" is not really a statement or an instruction. "If shell"...
> what? "I need to shell"? Is this whether we want to use a shell, or if we
> discovered that we're already in one? Or is "shell" not really a boolean
On 7/29/19 10:02 AM, David Raymond wrote:
> I think the other part of the discussion to be had here is: how do you
> name your booleans?
Yep.
> ... To me the name of a boolean variable should be obvious that it's a
> boolean ...
Well, yeah, maybe. If it's really only a boolean, and its value
On 2019-07-29, Michael Torrie wrote:
> On 7/28/19 6:04 PM, Chris Angelico wrote:
>> This is a fairly unusual case, though. More commonly, the default
>> would be None, not False, and "if bar is None:" is extremely well
>> known and idiomatic.
>
> Ahh yes, true.
No... None.
;)
--
Grant Edwards
oes anyone else have examples?
-Original Message-
From: Python-list On
Behalf Of Jonathan Moules
Sent: Sunday, July 28, 2019 7:56 AM
To: python-list@python.org
Subject: Boolean comparison & PEP8
Hi List,
Lets say I want to know if the value of `x` is bool(True).
My preferred way t
On 7/28/2019 7:55 AM, Jonathan Moules wrote:
Lets say I want to know if the value of `x` is bool(True).
My preferred way to do it is:
if x is True:
pass
If you know that expression x is boolean, and one usually knows or
should know whether is it or is not, '= True' and 'is True' and
si
On 7/28/19 6:04 PM, Chris Angelico wrote:
> This is a fairly unusual case, though. More commonly, the default
> would be None, not False, and "if bar is None:" is extremely well
> known and idiomatic.
Ahh yes, true.
> This analysis is correct, but the situations where you *actually* want
> to kno
On 7/28/19 8:46 PM, Chris Angelico wrote:
> On Mon, Jul 29, 2019 at 10:43 AM Richard Damon
> wrote:
>> On 7/28/19 8:25 PM, Chris Angelico wrote:
>>> Of course, if the third value can be simplified away (eg None means
>>> "use the global default"), then you can still just use "if verbose is
>>> No
On 2019-07-29, Richard Damon wrote:
> On 7/28/19 7:46 PM, Michael Torrie wrote:
>> Yet the recommended solution to the problem of wanting a default
>> argument of an empty list is something like this:
>>
>> def foo(bar=False);
>> if bar is False:
>> bar = []
>>
>>
>
> I thoug
On Mon, Jul 29, 2019 at 10:43 AM Richard Damon wrote:
>
> On 7/28/19 8:25 PM, Chris Angelico wrote:
> > Of course, if the third value can be simplified away (eg None means
> > "use the global default"), then you can still just use "if verbose is
> > None:" and then reassign it. But this is a legit
On 7/28/19 8:25 PM, Chris Angelico wrote:
> On Mon, Jul 29, 2019 at 10:15 AM Richard Damon
> wrote:
>> On 7/28/19 7:46 PM, Michael Torrie wrote:
>>> On 7/28/19 5:55 AM, Jonathan Moules wrote:
But this appears to be explicitly called out as being "Worse" in PEP8:
"""
Don't comp
On Mon, Jul 29, 2019 at 10:15 AM Richard Damon wrote:
>
> On 7/28/19 7:46 PM, Michael Torrie wrote:
> > On 7/28/19 5:55 AM, Jonathan Moules wrote:
> >> But this appears to be explicitly called out as being "Worse" in PEP8:
> >>
> >> """
> >> Don't compare boolean values to True or False using ==.
On 7/28/19 7:46 PM, Michael Torrie wrote:
> On 7/28/19 5:55 AM, Jonathan Moules wrote:
>> But this appears to be explicitly called out as being "Worse" in PEP8:
>>
>> """
>> Don't compare boolean values to True or False using ==.
>>
>> Yes: if greeting:
>> No: if greeting == True:
>> Worse: if
On Mon, Jul 29, 2019 at 9:48 AM Michael Torrie wrote:
>
> On 7/28/19 5:55 AM, Jonathan Moules wrote:
> > But this appears to be explicitly called out as being "Worse" in PEP8:
> >
> > """
> > Don't compare boolean values to True or False using ==.
> >
> > Yes: if greeting:
> > No:if greeting
On 7/28/19 5:55 AM, Jonathan Moules wrote:
> But this appears to be explicitly called out as being "Worse" in PEP8:
>
> """
> Don't compare boolean values to True or False using ==.
>
> Yes: if greeting:
> No: if greeting == True:
> Worse: if greeting is True:
> """
Yet the recommended solu
Jonathan Moules :
> Lets say I want to know if the value of `x` is bool(True).
> My preferred way to do it is:
>
> if x is True:
> [...]
>
> But this appears to be explicitly called out as being "Worse" in PEP8:
>
> [...]
>
> Why?
It has primarily to do with the naturalness of expression. In Engl
equate to True:
if x:
pass
The PEP for boolean type (285 -
https://www.python.org/dev/peps/pep-0285/) doesn't mention the "is"
comparison keyword at all as far as I can tell.
What am I missing?
Thanks
--
https://mail.python.org/mailman/listinfo/python-list
stem B to System A in the commentary fields.
It seems as though I may have to use different text similarity (comparison
between System A and System B text) or search techniques for one or more of the
three items.
I was thinking that Cosine Similarity Computation (CSC) would perhaps be
useful, but
Anthony Flury via Python-list schrieb am 21.12.18 um 09:06:
> I thought I would look at a side by side comparison of CPython, nuitka and
> PyPy
Interesting choice. Why nuitka?
> *The functionality under test*
>
> I have a library (called primelib) which implements a Sieve of E
I thought I would look at a side by side comparison of CPython, nuitka
and PyPy
*The functionality under test**
*
I have a library (called primelib) which implements a Sieve of
Erathoneses in pure Python - it was orginally written as part of my
project Euler attempts
Not only does it build
On 02/08/2018 08:20, Steven D'Aprano wrote:
On Wed, 01 Aug 2018 22:14:54 +0300, Serhiy Storchaka wrote:
...
Not always. If your code supported Python 2 in the past, or third-party
dependencies supports or supported Python 2, this warning can expose a
real bug. Even if all your and thir
On 01/08/2018 18:19, Peter Otten wrote:
I've looked into the actual code which has
# paraparser.py
f = isPy3 and asBytes or asUnicode
K = list(known_entities.keys())
for k in K:
known_entities[f(k)] = known_entities[k]
It looks like known_entities starts out with the default stri
On Wed, 01 Aug 2018 22:14:54 +0300, Serhiy Storchaka wrote:
> 01.08.18 21:03, Chris Angelico пише:
>> And in any code that does not and cannot run on Python 2, the warning
>> about bytes and text comparing unequal is nothing more than a false
>> positive.
>
> Not always. If your code supported Py
On Wed, 01 Aug 2018 19:00:27 +0100, Paul Moore wrote:
[...]
> My point was that it's a *warning*, and as such it's perfectly possible
> for a warning to *not* need addressing (other than to suppress or ignore
> it once you're happy that doing so is the right approach).
And my point was that ignor
01.08.18 21:03, Chris Angelico пише:
And in any code that does not and cannot run on Python
2, the warning about bytes and text comparing unequal is nothing more
than a false positive.
Not always. If your code supported Python 2 in the past, or third-party
dependencies supports or supported Py
On Thu, Aug 2, 2018 at 3:37 AM, Steven D'Aprano
wrote:
> In another post, Chris says:
>
> I suspect that there may be a bit of non-thinking-C-mentality
> creeping in: "if I can turn on warnings, I should, and any
> warning is a problem". That simply isn't the case in Python.
>
> I stro
n2 and Python3. He's
> getting a warning that the behaviour has changed between the two, and
> there's a dubious comparison being made between bytes and strings.
> Consequently, there's a very real chance that he has a dicts which have
> one key in Python 2 but two in Pyt
On Wed, 01 Aug 2018 16:22:16 +0100, Paul Moore wrote:
> On Wed, 1 Aug 2018 at 16:10, Robin Becker wrote:
>>
>> On 01/08/2018 14:38, Chris Angelico wrote:
>> > t's a warning designed to help people port code from Py2 to Py3. It's
>> > not meant to catc
Paul Moore wrote:
> On Wed, 1 Aug 2018 at 16:10, Robin Becker wrote:
>>
>> On 01/08/2018 14:38, Chris Angelico wrote:
>> > t's a warning designed to help people port code from Py2 to Py3. It's
>> > not meant to catch every possible comparison. Unless
On Thu, Aug 2, 2018 at 1:22 AM, Paul Moore wrote:
> On Wed, 1 Aug 2018 at 16:10, Robin Becker wrote:
>>
>> On 01/08/2018 14:38, Chris Angelico wrote:
>> > t's a warning designed to help people port code from Py2 to Py3. It's
>> > not meant to catc
On Wed, 1 Aug 2018 at 16:10, Robin Becker wrote:
>
> On 01/08/2018 14:38, Chris Angelico wrote:
> > t's a warning designed to help people port code from Py2 to Py3. It's
> > not meant to catch every possible comparison. Unless you are actually
> > porting Py2 c
On 01/08/2018 14:38, Chris Angelico wrote:
t's a warning designed to help people port code from Py2 to Py3. It's
not meant to catch every possible comparison. Unless you are actually
porting Py2 code and are worried that you'll be accidentally comparing
bytes and text, just*d
7;a'] = d[b'a']
> print(d)
>
>
>
>> C:\code\hg-repos\reportlab\tmp>\python37\python -b tb1.py
>> {'a': 1, b'a': 1}
>> {b'a': 1, 'a': 1}
>
>
> I expected one of the assignme
messing with bytes I discover that this doesn't warn with python -b
if __name__=='__main__':
class nbytes(bytes):
def __eq__(self,other):
return bytes.__eq__(self,other) if isinstance(other,bytes) else
False
def __hash__(self):
On Wed, Aug 1, 2018 at 9:56 PM, Richard Damon wrote:
>> it says explicitly that numeric keys will use numeric comparison, but
>> no mention is made of strings/bytes etc etc and there's an implication
>> that object identity is used rather than comparison. In python 3.x
>
ething for Python's bug tracker, I think!
>>
>> It's a warning specifically requested by the -b option. The two keys
>> in question have the same hash, which means they have to be compared
>> directly; they will compare unequal, but because of the -b flag, the
>&
..
Nope, that would be the effect of "and", not "or".
"a" is b"b" and "fallback"
False
"a" is b"b" or "fallback"
'fallback'
You seem to be caught in your wrong mental model. I recommend that you let
the matter rest for a day or so, and then look at it with a fresh eye.
..
my b
;>
>>> it says explicitly that numeric keys will use numeric comparison, but no
>
> .
>>>
>>>
>>
>> Technically, the comparison used is:
>>
>> a is b or a == b
>>
>> in other words, identity will match, but mainly, equality
Robin Becker wrote:
> On 01/08/2018 09:52, Chris Angelico wrote:
>> On Wed, Aug 1, 2018 at 6:36 PM, Robin Becker wrote:
>>> On 31/07/2018 16:52, Chris Angelico wrote:
>>..
>>>
>>> it says explicitly that numeric keys will use numeric comparison,
On 01/08/2018 09:52, Chris Angelico wrote:
On Wed, Aug 1, 2018 at 6:36 PM, Robin Becker wrote:
On 31/07/2018 16:52, Chris Angelico wrote:
..
it says explicitly that numeric keys will use numeric comparison, but no
.
Technically, the comparison used is:
a is b or a == b
>> they are distinct and can co-exist.
>>>
>>> Something for Python's bug tracker, I think!
>>
>>
>> It's a warning specifically requested by the -b option. The two keys
>> in question have the same hash, which means they have to be compa
they will compare unequal, but because of the -b flag, the
comparison triggers a warning. If that warning is spurious, *don't use
the -b option*.
ChrisA
I looked at the language documentation for 3.7 mappings
These represent finite sets of objects indexed by nearly arbitrary values. The
#
>> C:\code\hg-repos\reportlab\tmp>cat tb.py
>> if __name__=='__main__':
>> d={'a':1}
>> d[b'a'] = d['a']
>> ######
>>
>>
>> C:\code\hg-repos\reportlab\tmp>\python36\python -Wall -b tb.py
&g
1}
d[b'a'] = d['a']
##
C:\code\hg-repos\reportlab\tmp>\python36\python -Wall -b tb.py
tb.py:3: BytesWarning: Comparison between bytes and string
d[b'a'] = d['a']
I had always assumed that dicts didn't care about the type of keys
Robin Becker wrote:
> On 31/07/2018 09:16, Paul Moore wrote:
>> On 31 July 2018 at 08:40, Robin Becker wrote:
>>> A bitbucket user complains that python 3.6.6 with -Wall -b prints
>>> warnings for some reportlab code; the
>>> example boils down to the following
>>>
>>> ##
>>> C:\code\hg-r
On 31 July 2018 at 09:32, Robin Becker wrote:
> On 31/07/2018 09:16, Paul Moore wrote:
>>
>> On 31 July 2018 at 08:40, Robin Becker wrote:
>>>
>>> A bitbucket user complains that python 3.6.6 with -Wall -b prints
>>> warnings
>>> for some reportlab code; the
>>> example boils down to the followin
On 31/07/2018 09:16, Paul Moore wrote:
On 31 July 2018 at 08:40, Robin Becker wrote:
A bitbucket user complains that python 3.6.6 with -Wall -b prints warnings
for some reportlab code; the
example boils down to the following
##
C:\code\hg-repos\reportlab\tmp>cat tb.py
if __name__=='__m
x27;__main__':
> d={'a':1}
> d[b'a'] = d['a']
> ##
>
>
> C:\code\hg-repos\reportlab\tmp>\python36\python -Wall -b tb.py
> tb.py:3: BytesWarning: Comparison between bytes and string
> d[b'a'] = d['a']
>
##
C:\code\hg-repos\reportlab\tmp>\python36\python -Wall -b tb.py
tb.py:3: BytesWarning: Comparison between bytes and string
d[b'a'] = d['a']
I had always assumed that dicts didn't care about the type of keys although some types might cause issue with hashabi
On Thu, 17 Aug 2017 12:53 am, Steve D'Aprano wrote:
[...]
> Are there language implementations which evaluate the result of map() (or its
> equivalent) in some order other than the obvious left-to-right first-to-last
> sequential order? Is that order guaranteed by the language, or is it an
> imple
Op 2017-08-16, Steve D'Aprano schreef :
> Are there language implementations which evaluate the result of map()
> (or its equivalent) in some order other than the obvious left-to-right
> first-to-last sequential order? Is that order guaranteed by the
> language, or is it an implementation detail?
>
On Thu, 17 Aug 2017 03:54 pm, Pavol Lisy wrote:
> Is it guaranteed in python? Or future version could implement map with
> something like subscriptability "propagation"?
>
range(1_000_000_000_000_000_000)[-1]
>
>
map(lambda a:a+1,range(1_000_000_000_000_000_000))[-1]
>
On Thu, Aug 17, 2017 at 3:54 PM, Pavol Lisy wrote:
> On 8/16/17, Steve D'Aprano wrote:
>> Over in another thread, we've been talking about comprehensions and their
>> similarities and differences from the functional map() operation.
>>
>> Reminder:
>>
>> map(chr, [65, 66, 67, 68])
>>
>> will retu
On 8/16/17, Steve D'Aprano wrote:
> Over in another thread, we've been talking about comprehensions and their
> similarities and differences from the functional map() operation.
>
> Reminder:
>
> map(chr, [65, 66, 67, 68])
>
> will return ['A', 'B', 'C'].
>
> My questions for those who know langua
Steve D'Aprano writes:
> Are there language implementations which evaluate the result of map()
> (or its equivalent) in some order other than the obvious left-to-right
> first-to-last sequential order? Is that order guaranteed by the
> language, or is it an implementation detail?
Haskell just giv
On 8/16/2017 10:53 AM, Steve D'Aprano wrote:
Over in another thread, we've been talking about comprehensions and their
similarities and differences from the functional map() operation.
Reminder:
map(chr, [65, 66, 67, 68])
will return ['A', 'B', 'C'].
The comprehension 'while' proposal is for fu
On Wednesday, August 16, 2017 at 8:24:46 PM UTC+5:30, Steve D'Aprano wrote:
> Over in another thread, we've been talking about comprehensions and their
> similarities and differences from the functional map() operation.
>
> Reminder:
>
> map(chr, [65, 66, 67, 68])
>
> will return ['A', 'B', 'C']
On Thu, 17 Aug 2017 12:53 am, Steve D'Aprano wrote:
> map(chr, [65, 66, 67, 68])
>
> will return ['A', 'B', 'C'].
Of course I meant ['A', 'B', 'C', 'D'].
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org
Over in another thread, we've been talking about comprehensions and their
similarities and differences from the functional map() operation.
Reminder:
map(chr, [65, 66, 67, 68])
will return ['A', 'B', 'C'].
My questions for those who know languages apart from Python:
Are there language implemen
On Wednesday, September 21, 2016 at 8:26:37 PM UTC-5, Steve D'Aprano wrote:
> On Thu, 22 Sep 2016 01:55 am, Andrew Clark wrote:
>
> > I reinstalled paramiko and now i'm getting a slighty different error but
> > still says no cryptography.
>
> [...]
>
> > ImportError: No module named 'cryptograph
On Thu, 22 Sep 2016 01:55 am, Andrew Clark wrote:
> I reinstalled paramiko and now i'm getting a slighty different error but
> still says no cryptography.
[...]
> ImportError: No module named 'cryptography'
You appear to be missing a dependency of paramiko. You need to identify
which "cryptogr
On 2016-09-21 08:55, Andrew Clark wrote:
> I reinstalled paramiko and now i'm getting a slighty different error but
> still says no cryptography.
>
> Traceback (most recent call last):
> File "C:\Users\ac40935\workspace\AutoCompare\filecmp.py", line 6, in
>
> from paramiko import SSHConfi
I reinstalled paramiko and now i'm getting a slighty different error but still
says no cryptography.
Traceback (most recent call last):
File "C:\Users\ac40935\workspace\AutoCompare\filecmp.py", line 6, in
from paramiko import SSHConfig, SSHClient
File
"C:\Python35-32\lib\site-packages\p
On Tuesday, September 20, 2016 at 7:48:20 PM UTC-5, Steve D'Aprano wrote:
> On Wed, 21 Sep 2016 07:20 am, Andrew Clark wrote:
>
> > I've restarted my code so many times i no longer have a working version of
> > anything.
>
>
> *Restarting* your code doesn't change it and cannot possibly stop it
On Wednesday, September 21, 2016 at 12:14:54 PM UTC+12, Bill Deegan wrote:
> Use Git... at least you get can back what used to work..
That has become such a matter of programming habit, taken so much for granted
that, to me, it’s like saying “don’t forget to breathe”. :)
--
https://mail.python.o
On Wed, 21 Sep 2016 07:20 am, Andrew Clark wrote:
> I've restarted my code so many times i no longer have a working version of
> anything.
*Restarting* your code doesn't change it and cannot possibly stop it from
working. My guess is that you actually mean that you've made so many random
edits t
Use Git... at least you get can back what used to work..
On Tue, Sep 20, 2016 at 2:20 PM, Andrew Clark wrote:
> On Tuesday, September 20, 2016 at 3:25:11 PM UTC-5, Lawrence D’Oliveiro
> wrote:
> > On Wednesday, September 21, 2016 at 7:44:22 AM UTC+12, Andrew Clark
> wrote:
> > > If anyone can he
On Tuesday, September 20, 2016 at 3:25:11 PM UTC-5, Lawrence D’Oliveiro wrote:
> On Wednesday, September 21, 2016 at 7:44:22 AM UTC+12, Andrew Clark wrote:
> > If anyone can help me out with sudo code or set me in the right direction
> > would be nice.
>
> You know What Aesop said: “the gods* help
On Wednesday, September 21, 2016 at 7:44:22 AM UTC+12, Andrew Clark wrote:
> If anyone can help me out with sudo code or set me in the right direction
> would be nice.
You know What Aesop said: “the gods* help those who help themselves”. Start by
posting an initial stab at your code for solving,
I'm trying to develop a tool in python that will allow me to compare two file.
I know this sounds like it's been done before but there is a catch.
Files are stored on a remote server.
There are three separate directories.
StartupConfig, RunningConfig, and ArchiveConfig
I need to have the python
On Saturday, March 21, 2015 at 11:58:43 AM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :
>
> > However I am talking some historical facts, viz: Because some nuts did
> > the 20th century equivalent of: "Break each others' heads about how
> > many angels can dance on the head of a pin" therefore
Rustom Mody :
> However I am talking some historical facts, viz: Because some nuts did
> the 20th century equivalent of: "Break each others' heads about how
> many angels can dance on the head of a pin" therefore much of the
> world around us exists as it does (for better or worse) including my
>
On Friday, March 20, 2015 at 7:40:31 PM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody:
>
> > In all fairness to Chris, there have been notable mathematicians in
> > the last 100 years who have said more or less exactly what Chris is
> > saying: "The set ℝ is nonsense."
>
> Intuitionism is nonsens
Rustom Mody :
> In all fairness to Chris, there have been notable mathematicians in
> the last 100 years who have said more or less exactly what Chris is
> saying: "The set ℝ is nonsense."
Intuitionism is nonsense.
> In fact these fights are the very reason that CS came into existence.
I trace
On Friday, March 20, 2015 at 12:06:00 PM UTC+5:30, Steven D'Aprano wrote:
> On Friday 20 March 2015 14:47, Rustom Mody wrote:
> > Not too many people are interested in float independent of ℝ except
> > perhaps hardware designers who need to design respecting the IEEE
> > standard.
>
> I don't unde
On Friday, March 20, 2015 at 10:39:48 AM UTC+5:30, Ben Finney wrote:
> Chris Angelico writes:
>
> > Real numbers, yes […] but not IEEE floating point. Be careful of that
> > distinction; we're talking about computers here, not mythical numbers.
>
> So real numbers are mythical? IEEE floating poi
In article <550bbfc1$0$13010$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> I cannot remember the details, and I don't have my copy of the Apple
> Standard Numerics manual here to look it up
Amongst the details you don't remember is the correct name :-) It was
Standard Apple N
On Friday 20 March 2015 14:47, Rustom Mody wrote:
> On Friday, March 20, 2015 at 9:05:19 AM UTC+5:30, Chris Angelico wrote:
>> On Fri, Mar 20, 2015 at 2:27 PM, Rustom Mody wrote:
>> > Numbers (not complex) satisfy the trichotomy law: ie for any 2 numbers
>> > x,y: x < y or x > y o x = y
>>
>> Re
1 - 100 of 1162 matches
Mail list logo
