Re: Proper shebang for python3

[Dan Sommers]

On 7/24/19 10:24 PM, Michael Torrie wrote:

> ... In more recent times, binaries that are mostly applicable to the
> super user go there.  I don't see why you would want to merge those.
> A normal user rarely has need of much in /sbin.  Already /bin has way
> too much stuff in it (although I don't see any other way to
> practically do it without ridiculous PATHs searching all over the
> disk).

On ancient file systems (SysV?), ISTR something like 1400 files in a
directory being some sort of limit, or perhaps a major performance
issue.  Separate directories (including /usr/X11/bin) mitigated that,
too.

> Having said that, I note that on my CentOS 7 workstation, sbin seems
> to be in the path by default. So that negates my argument I suppose.
> Although I might have made that change myself.

My .shrc file has all sorts of leftovers from the old days, but my
current Linux PATH is just $HOME/bin, $HOME/local/bin, and /usr/bin.

Get Off My Lawn,
Dan
--
https://mail.python.org/mailman/listinfo/python-list

Re: Proper shebang for python3

[MRAB]

On 2019-07-25 03:57, Dan Sommers wrote:

On 7/24/19 10:24 PM, Michael Torrie wrote:

  > ... In more recent times, binaries that are mostly applicable to the
  > super user go there.  I don't see why you would want to merge those.
  > A normal user rarely has need of much in /sbin.  Already /bin has way
  > too much stuff in it (although I don't see any other way to
  > practically do it without ridiculous PATHs searching all over the
  > disk).

On ancient file systems (SysV?), ISTR something like 1400 files in a
directory being some sort of limit, or perhaps a major performance
issue.  Separate directories (including /usr/X11/bin) mitigated that,
too.


[snip]

At one time I used an MS-DOS application suite whose database component 
stored predefined queries in individual files. There were _many_ 
predefined queries, so _many_ small files.


This took up a lot of disk space, and running a predefined query was 
slow because of the need to search for the file (the FAT layout used a 
linked list).


I put all of the predefined queries into a single file and called an 
external program to look up the query on demand, copy it into a file, 
and then performed the query.


That saved a _lot_ of disk space, and, despite the overhead of calling 
an external program, was _much_ faster!

--
https://mail.python.org/mailman/listinfo/python-list

Difference between os.path.isdir and Path.is_dir

[Kirill Balunov]

 Hi all! It is expected that:
```
>>> import os
>>> from pathlib import Path
>>> dummy = " "   # or "" or " "
>>> os.path.isdir(dummy)
False
>>> Path(dummy).is_dir()
True
```

or was it overlooked?

with kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Chris Angelico]

On Fri, Jul 26, 2019 at 1:30 AM Kirill Balunov  wrote:
>
>  Hi all! It is expected that:
> ```
> >>> import os
> >>> from pathlib import Path
> >>> dummy = " "   # or "" or " "
> >>> os.path.isdir(dummy)
> False
> >>> Path(dummy).is_dir()
> True
> ```
>
> or was it overlooked?
>

Was not aware of that. A bit of digging shows that asking to convert
an empty path to an absolute one will give you the name of the current
directory (whether you use os.path or pathlib.Path), but os.path.isdir
starts by seeing if it can os.stat the given path, and if that fails,
it returns False (because if something doesn't exist, it can't be a
directory).

As a workaround, you could simply call
os.path.isdir(os.path.abspath(x)) to get consistent results. I'm not
sure if this is considered an important enough bug to actually fix, or
if it's merely a curiosity that occurs when you trigger undocumented
behaviour.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[eryk sun]

On 7/25/19, Kirill Balunov  wrote:
>
 import os
 from pathlib import Path
 dummy = " "   # or "" or " "
 os.path.isdir(dummy)
> False
 Path(dummy).is_dir()
> True

I can't reproduce the above result in either Linux or Windows. The
results should only be different for an empty path string, since
Path('') is the same as Path('.'). The results should be the same for
Path(" "), depending on whether a directory named " " exists (normally
not allowed in Windows, but Linux allows it).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Chris Angelico]

On Fri, Jul 26, 2019 at 3:28 AM eryk sun  wrote:
>
> On 7/25/19, Kirill Balunov  wrote:
> >
>  import os
>  from pathlib import Path
>  dummy = " "   # or "" or " "
>  os.path.isdir(dummy)
> > False
>  Path(dummy).is_dir()
> > True
>
> I can't reproduce the above result in either Linux or Windows. The
> results should only be different for an empty path string, since
> Path('') is the same as Path('.'). The results should be the same for
> Path(" "), depending on whether a directory named " " exists (normally
> not allowed in Windows, but Linux allows it).

Try an empty string, no spaces. To pathlib.Path, that means the
current directory. To os.path.abspath, that means the current
directory. To os.stat, it doesn't exist.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[eryk sun]

On 7/25/19, Chris Angelico  wrote:
> On Fri, Jul 26, 2019 at 3:28 AM eryk sun  wrote:
>>
>> On 7/25/19, Kirill Balunov  wrote:
>> >
>>  import os
>>  from pathlib import Path
>>  dummy = " "   # or "" or " "
>>  os.path.isdir(dummy)
>> > False
>>  Path(dummy).is_dir()
>> > True
>>
>> I can't reproduce the above result in either Linux or Windows. The
>> results should only be different for an empty path string, since
>> Path('') is the same as Path('.'). The results should be the same for
>> Path(" "), depending on whether a directory named " " exists (normally
>> not allowed in Windows, but Linux allows it).
>
> Try an empty string, no spaces. To pathlib.Path, that means the
> current directory. To os.path.abspath, that means the current
> directory. To os.stat, it doesn't exist.

That's what I said. But the OP shows os.path.isdir(" ") == False and
Path(" ").is_dir() == True, which is what I cannot reproduce and
really should not be able to reproduce, unless there's a bug
somewhere.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Chris Angelico]

On Fri, Jul 26, 2019 at 3:54 AM eryk sun  wrote:
>
> On 7/25/19, Chris Angelico  wrote:
> > On Fri, Jul 26, 2019 at 3:28 AM eryk sun  wrote:
> >>
> >> On 7/25/19, Kirill Balunov  wrote:
> >> >
> >>  import os
> >>  from pathlib import Path
> >>  dummy = " "   # or "" or " "
> >>  os.path.isdir(dummy)
> >> > False
> >>  Path(dummy).is_dir()
> >> > True
> >>
> >> I can't reproduce the above result in either Linux or Windows. The
> >> results should only be different for an empty path string, since
> >> Path('') is the same as Path('.'). The results should be the same for
> >> Path(" "), depending on whether a directory named " " exists (normally
> >> not allowed in Windows, but Linux allows it).
> >
> > Try an empty string, no spaces. To pathlib.Path, that means the
> > current directory. To os.path.abspath, that means the current
> > directory. To os.stat, it doesn't exist.
>
> That's what I said. But the OP shows os.path.isdir(" ") == False and
> Path(" ").is_dir() == True, which is what I cannot reproduce and
> really should not be able to reproduce, unless there's a bug
> somewhere.

Yeah but WHY is it different for an empty string?

I can well imagine that some OS/FS combinations will happily strip
spaces, thus devolving the " " case to the "" one.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[eryk sun]

On 7/25/19, Chris Angelico  wrote:
> On Fri, Jul 26, 2019 at 3:54 AM eryk sun  wrote:
>
>> That's what I said. But the OP shows os.path.isdir(" ") == False and
>> Path(" ").is_dir() == True, which is what I cannot reproduce and
>> really should not be able to reproduce, unless there's a bug
>> somewhere.
>
> Yeah but WHY is it different for an empty string?

Path.__fspath__ returns str(self), and Path.__str__ returns "." if the
path is empty, i.e. there's no drive, root, or parts.

I assume this is related to os.path.normpath("") == ".", which is
related to os.path.normpath("spam/..") == ".". However, an empty path
string isn't consistently handled as the current directory throughout
the os and os.path modules.

> I can well imagine that some OS/FS combinations will happily strip
> spaces, thus devolving the " " case to the "" one.

Windows trims trailing spaces and dots from the final component of a
path, unless we use a non-normalized \\?\ path.
-- 
https://mail.python.org/mailman/listinfo/python-list

Difference between os.path.isdir and Path.is_dir

[Maksim Fomin via Python-list]

‐‐‐ Original Message ‐‐‐
On Thursday, July 25, 2019 3:27 PM, Kirill Balunov  
wrote:

> Hi all! It is expected that:
>
> >>> import os
> >>> from pathlib import Path
> >>> dummy = " "   # or "" or " "
> >>> os.path.isdir(dummy)
>
> False
> >>> Path(dummy).is_dir()
>
> True
>
>
> or was it overlooked?
>
> with kind regards,
> -gdg
>
> -
>
> https://mail.python.org/mailman/listinfo/python-list

I also cannot reproduce it on linux (python 3.7.3). Which version do you use?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Kirill Balunov]

чт, 25 июл. 2019 г. в 20:28, eryk sun :

> On 7/25/19, Kirill Balunov  wrote:
> >
>  import os
>  from pathlib import Path
>  dummy = " "   # or "" or " "
>  os.path.isdir(dummy)
> > False
>  Path(dummy).is_dir()
> > True
>
> I can't reproduce the above result in either Linux or Windows. The
> results should only be different for an empty path string, since
> Path('') is the same as Path('.'). The results should be the same for
> Path(" "), depending on whether a directory named " " exists (normally
> not allowed in Windows, but Linux allows it).
>
>
Heh, something fishy is going on. I also can't reproduce that behavior
(with " " and "   ") at home comp on Windows 10 Python 3.7.4. Tomorrow I'll
check again at work and let you know. I apologize in advance. The main
problem arose огые with an empty line, but then I checked with " " and
apparently made a mistake somewhere.

with kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Kirill Balunov]

чт, 25 июл. 2019 г. в 19:16, Chris Angelico :

> On Fri, Jul 26, 2019 at 1:30 AM Kirill Balunov 
> wrote:
> >
> >  Hi all! It is expected that:
> > ```
> > >>> import os
> > >>> from pathlib import Path
> > >>> dummy = " "   # or "" or " "
> > >>> os.path.isdir(dummy)
> > False
> > >>> Path(dummy).is_dir()
> > True
> > ```
> >
> > or was it overlooked?
> >
> []
> I'm not sure if this is considered an important enough bug to actually
> fix, or
> if it's merely a curiosity that occurs when you trigger undocumented
> behaviour.
>
>
No, it's not just because of curiosity. I will try to tell the background,
and maybe I went the wrong way initially. There is a very cool project
https://github.com/3b1b/manim, it allows you to visualize math (I don’t
know how to describe it better you can see some examples here
https://www.3blue1brown.com) and it works lovely on Linux. For some reason,
I need to use it on Windows. Problems began to arise when I tried my
scripts were some latex was included in the animation.
So I installed TexLive, but it didn't produce any output :) In `manim` it
is invoked through a system call
https://github.com/3b1b/manim/blob/master/manimlib/utils/tex_file_writing.py#L40
like this:

$ latex -interaction=batchmode -halt-on-error -output-directory=...
input.tex > /dev/null

For some reason TexLive does not understand Windows relative paths of this
form -output-directory =".\Output" and  ".\Input\file.tex", but it
understands the absolute paths in Windows form like
"C:\path\to\the\input\file.tex".
I read that Windows allows also to provide paths in the usual form
"./Input/file.tex"
(maybe I'm wrong with my understanding what does it mean on Windows), I've
tested and this worked. But the problem is that Python always inserts '\'
as path separators on Windows and there is no control to set it up. I
decided to rewrite all this stuff with the help of `pathlib` module and to
use `Path`  and `.as_posix` method everywhere. Paths are set here
https://github.com/3b1b/manim/blob/c7e6d9d4742ec47098bd86a9bbb4212cc637206b/manimlib/constants.py#L10
and the author uses  `MEDIA_DIR = ""` as a default unset value, and then
checks  `if not os.path.isdir(MEDIA_DIR)`. The documentation states that
`os.path.isdir(...)` is equivalent to `Path(...).is_dir()` but it is not
true. So I wrote here.

with kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Chris Angelico]

On Fri, Jul 26, 2019 at 5:52 AM Kirill Balunov  wrote:
>
>
>
> чт, 25 июл. 2019 г. в 19:16, Chris Angelico :
>>
>> On Fri, Jul 26, 2019 at 1:30 AM Kirill Balunov  
>> wrote:
>> >
>> >  Hi all! It is expected that:
>> > ```
>> > >>> import os
>> > >>> from pathlib import Path
>> > >>> dummy = " "   # or "" or " "
>> > >>> os.path.isdir(dummy)
>> > False
>> > >>> Path(dummy).is_dir()
>> > True
>> > ```
>> >
>> > or was it overlooked?
>> >
>> []
>> I'm not sure if this is considered an important enough bug to actually fix, 
>> or
>> if it's merely a curiosity that occurs when you trigger undocumented
>> behaviour.
>>
>
> No, it's not just because of curiosity. I will try to tell the background, 
> and maybe I went the wrong way initially. There is a very cool project 
> https://github.com/3b1b/manim, it allows you to visualize math (I don’t know 
> how to describe it better you can see some examples here 
> https://www.3blue1brown.com) and it works lovely on Linux. For some reason, I 
> need to use it on Windows. Problems began to arise when I tried my scripts 
> were some latex was included in the animation.
>

Ah, I love 3b1b! Great videos. I toyed with manim once (wanting to
create new Fourier visualizations), but the open source parts weren't
enough for what I was trying to do. Very cool though.

> So I installed TexLive, but it didn't produce any output :) In `manim` it is 
> invoked through a system call 
> https://github.com/3b1b/manim/blob/master/manimlib/utils/tex_file_writing.py#L40
>  like this:
>
> $ latex -interaction=batchmode -halt-on-error -output-directory=... input.tex 
> > /dev/null
>
> For some reason TexLive does not understand Windows relative paths of this 
> form -output-directory =".\Output" and  ".\Input\file.tex", but it 
> understands the absolute paths in Windows form like 
> "C:\path\to\the\input\file.tex". I read that Windows allows also to provide 
> paths in the usual form "./Input/file.tex" (maybe I'm wrong with my 
> understanding what does it mean on Windows),
>

It means the same thing as your other relative path. The two types of
slash should basically be interchangeable.

> I've tested and this worked. But the problem is that Python always inserts 
> '\' as path separators on Windows and there is no control to set it up. I 
> decided to rewrite all this stuff with the help of `pathlib` module and to 
> use `Path`  and `.as_posix` method everywhere. Paths are set here 
> https://github.com/3b1b/manim/blob/c7e6d9d4742ec47098bd86a9bbb4212cc637206b/manimlib/constants.py#L10
>  and the author uses  `MEDIA_DIR = ""` as a default unset value, and then 
> checks  `if not os.path.isdir(MEDIA_DIR)`. The documentation states that  
> `os.path.isdir(...)` is equivalent to `Path(...).is_dir()` but it is not 
> true. So I wrote here.
>

Gotcha. It'd probably be safe to change it to "." instead; that way,
it's an actual valid directory name and can be combined normally with
other components.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Kirill Balunov]

чт, 25 июл. 2019 г. в 22:58, Chris Angelico :

> On Fri, Jul 26, 2019 at 5:52 AM Kirill Balunov 
> wrote:
> [...]
> > No, it's not just because of curiosity. I will try to tell the
> background, and maybe I went the wrong way initially. There is a very cool
> project https://github.com/3b1b/manim, it allows you to visualize math (I
> don’t know how to describe it better you can see some examples here
> https://www.3blue1brown.com) and it works lovely on Linux. For some
> reason, I need to use it on Windows. Problems began to arise when I tried
> my scripts were some latex was included in the animation.
> >
>
> Ah, I love 3b1b! Great videos. I toyed with manim once (wanting to
> create new Fourier visualizations), but the open source parts weren't
> enough for what I was trying to do. Very cool though.
>
>
If you can tell, what parts did you miss?

with kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Chris Angelico]

On Fri, Jul 26, 2019 at 6:13 AM Kirill Balunov  wrote:
>
>
>
> чт, 25 июл. 2019 г. в 22:58, Chris Angelico :
>>
>> On Fri, Jul 26, 2019 at 5:52 AM Kirill Balunov  
>> wrote:
>> [...]
>> > No, it's not just because of curiosity. I will try to tell the background, 
>> > and maybe I went the wrong way initially. There is a very cool project 
>> > https://github.com/3b1b/manim, it allows you to visualize math (I don’t 
>> > know how to describe it better you can see some examples here 
>> > https://www.3blue1brown.com) and it works lovely on Linux. For some 
>> > reason, I need to use it on Windows. Problems began to arise when I tried 
>> > my scripts were some latex was included in the animation.
>> >
>>
>> Ah, I love 3b1b! Great videos. I toyed with manim once (wanting to
>> create new Fourier visualizations), but the open source parts weren't
>> enough for what I was trying to do. Very cool though.
>>
>
> If you can tell, what parts did you miss?

Basically everything to do with Fourier transforms. I wanted to hand
the program a new SVG file and see it animate it, but (a) I didn't
understand the code very well, and (b) a lot of the code isn't part of
the freely licensed part (it's all in the same repo, but some is
MIT-licensed and isn't), which means it's not documented for public
use and isn't designed to be broadly usable.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

book on modern Python

[beliavsky--- via Python-list]

I did some basic programming in Python 2 and now use Python 3. All I know about 
Python 3 is that print is a function requiring parentheses.

What is a good book on modern Python that covers topics such as type 
annotations? I know of

Fluent Python: Clear, Concise, and Effective Programming
by Luciano Ramalho (2015)

Introducing Python: Modern Computing in Simple Packages
by Bill Lubanovic (2014)

but wonder if the language has evolved significantly since they were published. 
I see that a 2nd edition of "Introducing Python" is due this year.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proper shebang for python3

[Cameron Simpson]

On 24Jul2019 22:57, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote:

On 7/24/19 10:24 PM, Michael Torrie wrote:

... In more recent times, binaries that are mostly applicable to the
super user go there.  I don't see why you would want to merge those.
A normal user rarely has need of much in /sbin.  Already /bin has way
too much stuff in it (although I don't see any other way to
practically do it without ridiculous PATHs searching all over the
disk).


On ancient file systems (SysV?), ISTR something like 1400 files in a
directory being some sort of limit, or perhaps a major performance
issue.  Separate directories (including /usr/X11/bin) mitigated that,
too.


I don't recall there being any specific hard limit though. What does 
happen in decent modern filesystems is that directories have a hash 
table in them for lookups, making a file name access constant time 
instead of a linear search.


Also, shells like zsh keep a hash table of the available commands to 
speed invocation, avoiding a linear $PATH search.


I don't recall stuff like /usr/X11/bin being aimed at performance (but I 
would not necessarily know); it has always seemed more like partitioning 
out various software groups - in this case the X11 Window System stuff.  
If nothing else, this makes separate development easier.



Having said that, I note that on my CentOS 7 workstation, sbin seems
to be in the path by default. So that negates my argument I suppose.
Although I might have made that change myself.


My .shrc file has all sorts of leftovers from the old days, but my
current Linux PATH is just $HOME/bin, $HOME/local/bin, and /usr/bin.


Hmm. 21 componetent in my $PATH here :-)

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Cameron Simpson]

On 25Jul2019 13:40, eryk sun  wrote:

Windows trims trailing spaces and dots from the final component of a
path, unless we use a non-normalized \\?\ path.


Hoo!

Well, that explains some extremely weird NAS behaviour I encountered the 
other month with some paths ending in spaces. (My machine and I think 
also the NAS were UNIX/Linux at each end, but speaking over SMB.) 
Guessing that the NAS was doing only a half hearted implementation of 
the trailing spaces semantics.


Interesting:-)

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Cameron Simpson]

On 26Jul2019 03:43, Chris Angelico  wrote:

On Fri, Jul 26, 2019 at 3:28 AM eryk sun  wrote:

On 7/25/19, Kirill Balunov  wrote:
 import os
 from pathlib import Path
 dummy = " "   # or "" or " "
 os.path.isdir(dummy)
> False
 Path(dummy).is_dir()
> True

I can't reproduce the above result in either Linux or Windows. The
results should only be different for an empty path string, since
Path('') is the same as Path('.'). The results should be the same for
Path(" "), depending on whether a directory named " " exists (normally
not allowed in Windows, but Linux allows it).


Try an empty string, no spaces. To pathlib.Path, that means the
current directory. To os.path.abspath, that means the current
directory. To os.stat, it doesn't exist.


And for some context, on older UNIXen "" did stat successfully.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Can not execute options trade

[spawnaga]

The placeOrder command does not send the order for options trades.

I tried to submit the order for stocks and it went through but not options

# -*- coding: utf-8 -*-
"""
Created on Wed Jul 24 21:58:32 2019

@author: Alex Oraibi
"""

import time
from time import localtime, strftime
from ib.ext.Contract import Contract
from ib.ext.Order import Order
from ib.opt import ibConnection, message
import gspread
from oauth2client.service_account import ServiceAccountCredentials
def Google() :   
json_key = 'G:\IBridgeby\spreadsheet.json'
scope = ['https://spreadsheets.google.com/feeds', 
'https://www.googleapis.com/auth/drive']

credentials = ServiceAccountCredentials.from_json_keyfile_name(json_key, 
scope)

gc = gspread.authorize(credentials)
wks = gc.open("Test").sheet1
return (wks)
def error_handler(msg):
"""Handles the capturing of error messages"""
print("Server Error: %s" % msg)

def reply_handler(msg):
"""Handles of server replies"""
print("Server Response: %s, %s" % (msg.typeName, msg))
def makeStkContract(a,c):
newStkContract = Contract()
newStkContract.m_symbol = a
newStkContract.m_secType = "OPT"
newStkContract.m_strike = c
newStkContract.m_exchange = "SMART"
newStkContract.m_currency = "USD"
return newStkContract

def makeOptContract(a, b, e, c):
newOptContract = Contract()
newOptContract.m_symbol = a
newOptContract.m_secType = "OPT"
newOptContract.m_right = e
newOptContract.m_expiry = b
newOptContract.m_strike = float(c)
newOptContract.m_exchange = "SMART"
newOptContract.m_currency = "USD"
# newOptContract.m_localSymbol = ''
# newOptContract.m_primaryExch = ''
return newOptContract
def makeOptOrder(action, orderID, f):
newOptOrder = Order()
newOptOrder.m_orderId = orderID
newOptOrder.m_permid = 0
newOptOrder.m_action = 'BUY'
newOptOrder.m_lmtPrice = f
newOptOrder.m_auxPrice = 0
newOptOrder.m_tif = 'DAY'
newOptOrder.m_transmit = False
newOptOrder.m_orderType = 'LMT'
newOptOrder.m_totalQuantity = 1
newOptOrder.m_multiplier = "100"
return newOptOrder
if __name__ == "__main__":
tws_conn = ibConnection("127.0.0.1", port=749)
tws_conn.connect()

order_id = 1000
Exec_time = strftime("%H", localtime())
tickID = 36
while Exec_time != '13': 
Exec_time = strftime("%H", localtime())
if Exec_time == '13':
break
else:
hup = Google()
tic = hup.cell(2,15).value
stri = hup.cell(2,4).value
exp = hup.cell(2,3).value
rig = hup.cell(2,13).value
lim = hup.cell(2,6).value
if tic == '#VALUE!' :
tic =''
stkContract = makeStkContract(tic,stri)
optContract = makeOptContract(tic, exp, rig, stri)
print(stkContract, optContract)
tws_conn.reqMktData(1, stkContract, "", "")
tws_conn.reqMktData(tickID, optContract, "", "")
optOrder = makeOptOrder("BUY", order_id, lim)
print(tws_conn.reqMktData(tic, optContract, "", True))
tws_conn.placeOrder(order_id, optContract, optOrder)
order_id += 1
time.sleep(10)
continue
tws_conn.disconnect()
I am loading trading suggestions from an online excel sheet and submit the 
order to TWS. I have successfully loaded the information from my google sheet 
and put the code to order the security but the execution part is not going 
through. I think my makeOptContract() is the problem that is holding me back 
from executing my order. Please provide some suggestions
-- 
https://mail.python.org/mailman/listinfo/python-list

Why am I getting duplicate values in my output?

[DT]

With the following code:

import csv


class AccessPoint(object):

def __init__(self, name, ipv4, model, location):
self.name = name
self.ipv4 = ipv4
self.model = model
self.location = location
print('{0} born'.format(self.name))

def __del__(self):
print('{0} died'.format(self.name))


def main():
ap_list = []
ap_dict = {}

with open('C:\\inventory.csv', 'r') as csvfile:
csv_reader = csv.DictReader(csvfile)

for row in csv_reader:
ap = AccessPoint(row['Host Name'], row['Static IP Address'], 
row['Device Model'], row['Host Name'][0:5])

ap_dict['ap_name'] = ap.name
ap_dict['ap_ipv4'] = ap.ipv4
ap_dict['ap_model'] = ap.model
ap_dict['ap_location'] = ap.location

ap_list.append(ap_dict)

print(ap_list)


if __name__ == '__main__':
main()


When I execute print(ap_list) I get the very last row in the CSV repeated once 
for every row in the file. I would expect to see a list of ap_dicts, but I do 
not. When I add print(ap_dict) directly after the ap_list.append(ap_dict) 
inside the loop I see the correct values. Why is it that the print(ap_list) 
that happens outside of the for loop is only printing the last item on repeat?

Here is some example output data:

AP1 born
AP2 born
AP1 died
AP3 born
AP2 died
[{'ap_name': 'AP3', 'ap_ipv4': '192.168.1.1', 'ap_model': 'Linksys', 
'ap_location': 'HQ'}, {'ap_name': 'AP3', 'ap_ipv4': '192.168.1.1', 'ap_model': 
'Linksys', 'ap_location': 'HQ'}, {'ap_name': 'AP3', 'ap_ipv4': '192.168.1.1', 
'ap_model': 'Linksys', 'ap_location': 'HQ'}
AP3 died


Thanks in advance.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why am I getting duplicate values in my output?

[Chris Angelico]

On Fri, Jul 26, 2019 at 12:46 PM DT  wrote:
> def main():
> ap_list = []
> ap_dict = {}
>
> for row in csv_reader:
> ap_dict['ap_name'] = ap.name
> ap_dict['ap_ipv4'] = ap.ipv4
> ap_dict['ap_model'] = ap.model
> ap_dict['ap_location'] = ap.location
>
> ap_list.append(ap_dict)
>
> print(ap_list)
>
>
> When I execute print(ap_list) I get the very last row in the CSV repeated 
> once for every row in the file. I would expect to see a list of ap_dicts, but 
> I do not. When I add print(ap_dict) directly after the 
> ap_list.append(ap_dict) inside the loop I see the correct values. Why is it 
> that the print(ap_list) that happens outside of the for loop is only printing 
> the last item on repeat?
>

You create one dictionary, and then reuse it every time. Appending it
to a list doesn't change it, which means you keep overwriting the same
dictionary every time you go through the loop.

Try creating a new dictionary for each row; in fact, you can simplify
things significantly by using a dict literal (or, more technically,
"dict display") to create a new dictionary with the four fields
already set. You could even do that in the same operation as appending
to the list.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Python 3.7 - Reading text from Terminal window

[nir . zairi]

Hi,

I want it to wait for a specific text on the terminal window that it opens 
(putty.exe), how can i do it? 

from pywinauto.application import Application
from pynput.keyboard import Key, Controller
 
print('Configuring')
 
app = Application().start(cmd_line=u'"C:\\...putty.exe" ')
puttyconfigbox = app.PuTTYConfigBox
puttyconfigbox.wait('ready')
listbox = puttyconfigbox.ListBox
listbox.select(u'COM5')
button = puttyconfigbox[u'&Load']
button.click()
button2 = puttyconfigbox[u'&Open']
button2.click()
 
keyboard = Controller()
keyboard.press(Key.enter)
 
keyboard.type('password1')
keyboard.press(Key.enter)
keyboard.type('enable\nconf t\n')

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proper shebang for python3

[Eli the Bearded]

In comp.lang.python, Thomas 'PointedEars' Lahn   wrote:
> Michael Torrie wrote:
>> On 7/24/19 4:20 PM, Cameron Simpson wrote:
>>> That is some progress, hooray. Then there's just sbin -> bin to go.
>> I suppose in the olden days sbin was for static binaries, […]
> No, “sbin” is short for “*system* binaries” which in general only the 
> superuser should be able to execute.

I think Michael is confusing "sbin" with the statically linked utilities
some systems (particularly older ones, but also FreeBSD in /rescue/)
have for repairing the system when things start to go bad. You'd want
a shell (sh is great), a basic editor (eg, eg), and a smattering of
other tools, akin to the ones listed as "must be in /sbin" in your
linuxfoundation link.

But more than a few utilities in /sbin are useful for non-superusers.
Eg ip or ifconfig for informational purposes like identifying current
IP address and getting MAC.

> Which is why the above is a Very Bad Idea[tm].

Why? Programs that can *only* be usefully run by a privileged user
or in a system context (eg halt or getty) already *must* prevent non
privileged use. So why would it be a Very Bad Idea[tm] to have them in
a common directory like /bin/?

(Feel free to crosspost and set follow-ups to another group if you like.
But I would suggest *not* a Linux group, since this is something general
to all Unix-likes.)

> 

Elijah
--
uses both netbsd and linux regularly
-- 
https://mail.python.org/mailman/listinfo/python-list