Re: Dowloading package dependencies from locked down machine

[Mats Wichmann]

On 7/27/20 7:33 PM, Igor Korot wrote:
> Hi,

>> The issue is that the IT department thinks that installing the full
>> power of Python scripting on an Internet facing machine is inconsistent
>> with the "Cyber Essentials Plus" accreditiation that they need to win
>> Government contracts.

> Coming from experience working with the Government Contractor first hand,
> they have to have an approved list of software people can work with.
> 
> Ask to provide that list.
> Now such a list is provided by the Security Office and it does not
> come from the IT department.
> 
> You can actually go and check this list yourself. Check with your company
> FSO.
> 
> I can assure you python will definitely be on that list.
> Its possible that some python modules may not be there but the
> language/interpreter will.

US Government entities use Python extensively.  *Some* are forced to use
a special "restricted" version of Python, the mythical FIPS-Compliant
version, that removes your ability to use a few things, notably the md5
hash because it's been deemed "insecure" (even if you're not using it
for cryptographic purposes, it's just banned).




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

Re: Dowloading package dependencies from locked down machine

[Python]

Andrew McLean wrote:
At work my only Internet access is via a locked-down PC. The IT 
department are not willing to install Python on it [1]. Ideally I would 
download packages and their dependencies from PyPi using "pip download" 
at the command line. Any better solutions than downloading the package 
in a browser, finding its dependencies manually, downloading these and 
so on recursively?


You may want to give FPM a try: il allows you to build and provide most
of PyPI in a yum/apt repository. You can make all build on a separate
system then export rpm/deb packages.

https://github.com/jordansissel/fpm


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

Re: Dowloading package dependencies from locked down machine

[J. Pic]

Ideas for solutions:

- use pip install --user at home, copy over ~/.local/lib/python3.8/site-packages
- same, but with ~/.cache/pip
-- 
https://mail.python.org/mailman/listinfo/python-list

Windows and Subclassing - 'OverflowError': int too long to convert

[Eko palypse]

Hello,
I am subclassing a scintilla window and it happens every now and then
that I get an OverflowError. I've logged the message and could narrow down
that it
is a single windows message which causes this trouble. It's WM_ERASEBKGND.

Now the confusing part for me is the following.
According to MS WPARAM
 is
an UINT_PTR which is defined as

#if defined(_WIN64) typedef unsigned __int64 UINT_PTR; #else typedef
unsigned int UINT_PTR; #endif

wintypes.WPARAM is ctypes.c_ulonglong and is of size 8 on my system.
I'm on a x64 Windows - so far as good, right?

Now when I get this error the message I receive in this situation is always
like this.

hWnd=197364, msg=20, wParam=*18446744072652653190*, lParam=0

Traceback (most recent call last):
  File "_ctypes/callbacks.c", line 237, in 'calling callback function'
  File "", line 121, in new_scintilla2_proc
ctypes.ArgumentError: argument 4: : int too long to
convert

I really doubt that 18446744072652653190 is a valid device context but who
knows.
The question is, why do I even get this OverflowError?

If I do wintypes.WPARAM(18446744072652653190) I don't receive an exception
and it is a valid 64bit value, isn't it?

The code I'm using is this

user32 = ctypes.WinDLL('user32', use_last_error=True)

LRESULT = wintypes.LPARAM
WND_PROC = ctypes.WINFUNCTYPE(LRESULT,
  wintypes.HWND,
  wintypes.UINT,
  wintypes.WPARAM,
  wintypes.LPARAM)

user32.CallWindowProcW.restype = LRESULT
user32.CallWindowProcW.argtypes = [WND_PROC,
   wintypes.HWND,
   wintypes.UINT,
   wintypes.WPARAM,
   wintypes.LPARAM]


Any idea what might have caused this?

Thank you for reading
Eren
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Dowloading package dependencies from locked down machine

[dn via Python-list]

On 29/07/2020 07:29, J. Pic wrote:

Ideas for solutions:

- use pip install --user at home, copy over ~/.local/lib/python3.8/site-packages
- same, but with ~/.cache/pip



...or even building an entire parallel Python environment on an 
Internet-connected machine (even a VM), from which the PYTHONPATH dirs 
could be copied/mirrored to the 'difficult machine'.


However, if the machine is 'locked-down', am slightly puzzled that 'the 
man' would allow you to add proscribed software by some other 
(non-Internet, eg USB) means!

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Support both asyncio and synchronous callers

[Barry Scott]

> On 26 Jul 2020, at 02:36, Damian Johnson  wrote:
> 
> Hi. I'm the author of Stem, Tor's python library [1]. Recently we
> migrated to asyncio, but desire to still be usable by synchronous
> callers.
> 
> We wrote a mixin [2][3] that transparently makes any class usable by
> both asyncio and synchronous callers...
> 
> ==
> 
> import asyncio
> import stem.util.asyncio
> 
> class Example(stem.util.asyncio.Synchronous):
>  async def hello(self):
>return 'hello'
> 
> def sync_demo():
>  instance = Example()
>  print('%s from a synchronous context' % instance.hello())
>  instance.stop()
> 
> async def async_demo():
>  instance = Example()
>  print('%s from an asynchronous context' % await instance.hello())
>  instance.stop()
> 
> sync_demo()
> asyncio.run(async_demo())
> 
> ==
> 
> Is there a better way to approach this?
> 
> Our wider ecosystem seem to be forking networking libraries into
> sync/async variants, with requests [4] and AIOHTTP [5] as the most
> prominent. Are there any libraries out there that demonstrate good
> support for both kinds of callers without duplicating their API?

Maybe you have a sync facade that uses the async version to do
the work? That way you have one implementation and two ways to
use it.

Barry



> 
> Thanks! -Damian
> 
> PS. I apologize if this email gets duplicated. Initially I used a
> different email address which Mailman seemed to decline.
> 
> [1] https://stem.torproject.org/
> [2] https://gitweb.torproject.org/stem.git/tree/stem/util/asyncio.py
> [3] https://gitweb.torproject.org/stem.git/tree/test/unit/util/asyncio.py
> [4] https://requests.readthedocs.io/en/master/
> [5] https://docs.aiohttp.org/en/latest/index.html
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

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

RE: Local access to a file, How To ?

[Steve]

 

 

I have a python program that reads and writes to files that are all within
the folder that contains the python program.  There is now a second python
program that is to be run to compile information in said files.

 

I am having difficulty trying to call the local supporting program from
within the main program.  I would it would found easily because everything
is all in the same folder.  Apparently, I have to decipher paths to do the
task.

 

One problem is that the project is portable on a thumb drive and the path
can change based on the computer on which the program is executed.  I look
up use of path and I seem to get all absolute path instruction and not
relative.

 

Where an I steering wrongly here.

 

Steve

 

 

 

 

 

 

 

 

 

 

 

 

Footnote:

In 10 years, are these going to be the "good old times" that we are living
right now?

 

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

Re: Local access to a file, How To ?

[MRAB]

On 2020-07-28 21:56, Steve wrote:


I have a python program that reads and writes to files that are all within
the folder that contains the python program.  There is now a second python
program that is to be run to compile information in said files.

  


I am having difficulty trying to call the local supporting program from
within the main program.  I would it would found easily because everything
is all in the same folder.  Apparently, I have to decipher paths to do the
task.

  


One problem is that the project is portable on a thumb drive and the path
can change based on the computer on which the program is executed.  I look
up use of path and I seem to get all absolute path instruction and not
relative.

  


Where an I steering wrongly here.


It's easiest to work with absolute paths.

The path of the script is given by __file__, so the folder in which the 
script is running is given by os.path.dirname(__file__).


You can work from there to make the paths of the other files using 
os.path.join(...).

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

Re: Local access to a file, How To ?

[DL Neil via Python-list]

On 29/07/2020 08:56, Steve wrote:

I have a python program that reads and writes to files that are all within
the folder that contains the python program.  There is now a second python
program that is to be run to compile information in said files.

I am having difficulty trying to call the local supporting program from
within the main program.  I would it would found easily because everything
is all in the same folder.  Apparently, I have to decipher paths to do the
task.

One problem is that the project is portable on a thumb drive and the path
can change based on the computer on which the program is executed.  I look
up use of path and I seem to get all absolute path instruction and not
relative.

Where an I steering wrongly here.



Questions:
- is the second program kept in the same directory as the first, or 
somewhere else?

- by "call" do you mean "import", or...


If the program and the data files are in the same directory, then you 
will have noticed that there is no need for absolute addressing, ie


open( "file.in" )

not

open( "/home/me/Projets/this/file.in" )

The same applies to import-s. From program_A we can

import program_B

in the same directory. No need for absolute paths, anywhere!

That is to say, Python works happily with the concept of the "current 
working directory", and when no absolute-path is provided assumes 'this 
directory' - or if a non-absolute-path is provided (doesn't commence 
with "/", in the case of Posix) prefixes the path from 'this directory'. 
Yes, there are many caveats beyond such a simple explanation, but that 
should be enough to get-going. Keeping 'everything' in the single 
directory, and always executing from there, should enable migration.

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list