pyz and concurrent.futures
I have two apps, one GUI one console, both using PySide2 bindings to Qt 5. Both use concurrent.futures and a processing pool to spread their work over multiple CPUs. I've written my own deployment script (since I can't get a successfull deploy with cx-freeze, py2exe, or pyinstaller) which creates this structure: myapp/ myapp/python/ # copy of Python 3.6 i.e., WinPython's python-3.6.7 dir myapp/myapp.pyz myapp/*.DLL # some custom and commercial DLLs the apps depend on I create the .pyz by copying myapp's .py files, running python3 -m compileall -b on the copied dir, then deleting all the original .py files, then renaming myapp.py as __main__.py and then zipping it all up as myapp.pyz. I can then run the programs using .bat files like this: Console app: "%~dp0\python\python.exe" "%~dp0\myapp.pyz" %* GUI app: "%~dp0\python\pythonw.exe" "%~dp0\myapp.pyz" %* The GUI app works fine. One significant difference is that the GUI app has two threads, the main thread running the GUI and a worker thread in which the calls to concurrent.futures process pool are made. Whereas the console app uses a single thread. Another difference is that the GUI app has an event loop and the console app doesn't. The console app works fine in the dev dir, but silently fails when run as a pyz. And it fails executing the same code as the GUI app (they share many modules). Has anyone encountered this issue before and have a solution? I plan to try to use two threads for the console app to see if that helps; but I'd still like to understand what is causing the problem. -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.10rc1 and Python 3.5.7rc1 are now available
On behalf of the Python development community, I'm chuffed to announce the availability of Python 3.4.10rc1 and Python 3.5.7rc1. Both Python 3.4 and 3.5 are in "security fixes only" mode. Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only. The "final" releases on both these branches should be out in about two weeks. Of particular note: that release of Python 3.4, Python 3.4.10 final, will be the final release ever in the Python 3.4 series. After 3.4.10, the branch will be closed for good and I'll retire as Python 3.4 Release Manager. I'll still be the Python 3.5 Release Manager until 3.5 similarly concludes, approximately eighteen months from now. You can find Python 3.4.10rc1 here: https://www.python.org/downloads/release/python-3410rc1/ And you can find Python 3.5.7rc1 here: https://www.python.org/downloads/release/python-357rc1/ Best wishes, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
Re: pyz and concurrent.futures
I've now just tried with Python 3.7.1 and the same problem persists, so I'll now try to use a second thread for the console app. PS For these CPU-intensive apps which use multiprocessing to use all the CPUs, compared with Python 3.4, 3.6 is 13% faster, and 3.7 is 33% faster! -- https://mail.python.org/mailman/listinfo/python-list
"How to package additional files under site-packages "
Hello,
I have a setup.py that has this:
package_data = { 'tests': [ '*.png', '*.jpg']}
data_files = [ ('', ['./README.md']),
('', ['./CHANGES']),
('', ['./LICENSE']) ]
setup( name= PACKAGE,
version = VERSION,
.
.
packages = find_packages(),
package_data = package_data,
data_files = data_files,
include_package_data = True,
.
)
This setup is copying README.md, CHANGES and LICENSE files under python-install
path/Lib
e.g:
/Library/Frameworks/Python.framework/Versions/3.7/CHANGES
/Library/Frameworks/Python.framework/Versions/3.7/LICENSE
/Library/Frameworks/Python.framework/Versions/3.7/README.md
And my package is installed under :
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/ibm_db.cpython-37m-darwin.so
I want data_files to be copied under my package install path.
How do I achieve this?
Thanks in advance!
Saba.
Saba Kauser
Db2 Connect development and support.
Rocket Software Development India Pvt Ltd
Karle Town Centre - SEZ,
HUB 1 building, 4th Floor (North West Wing),
100 ft. Kempapura road, adjacent to Nagawara lake,
Nagawara, Bangalore - 560 045
E: skau...@rocketsoftware.com
-
Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ?
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support:
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences -
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
This communication and any attachments may contain confidential information of
Rocket Software, Inc. All unauthorized use, disclosure or distribution is
prohibited. If you are not the intended recipient, please notify Rocket
Software immediately and destroy all copies of this communication. Thank you.
--
https://mail.python.org/mailman/listinfo/python-list
Decodificar base64 en Odoo 12
Hola a todos, tengo un problema al decodificar el contenido de una variable base64. De esta manera lo hago: cfdi = base64.b64decode(inv.l10n_mx_edi_cfdi) Al momento de decodificar el resultado que me envía es esto: b'\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n' Alguien que me pueda decir que estoy haciendo mal, lo cheque en la consola Python3 y todo va bien, pero dentro de Odoo no lo decodifica. -- https://mail.python.org/mailman/listinfo/python-list
Re: Decodificar base64 en Odoo 12
Angie GL wrote: > Hola a todos, tengo un problema al decodificar el contenido de una > variable base64. > > De esta manera lo hago: > > cfdi = base64.b64decode(inv.l10n_mx_edi_cfdi) > > > > Al momento de decodificar el resultado que me envía es esto: > > b'\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n' > > Alguien que me pueda decir que estoy haciendo mal, lo cheque en la consola > Python3 y todo va bien, pero dentro de Odoo no lo decodifica. What result did you expect? What is the value of inv.l10n_mx_edi_cfdi? For b'CgogCiAKIAogCiAKIAogCiAKIAogCiAKIAogCiAKIAogCgo=' you see the correct result: >>> base64.b64decode(b'CgogCiAKIAogCiAKIAogCiAKIAogCiAKIAogCiAKIAogCgo=') b'\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n' -- https://mail.python.org/mailman/listinfo/python-list
about types.new_class and module
Hello,
I'm looking for an explanation where live classes created by
types.new_class() :
py> import types
py> types.new_class('A')
types.A
py> types.A
AttributeError: module 'types' has no attribute 'A'
py> _.__module__
'types'
The new class comes from `types` module without being inside.
That's annoying to me for my use case :
I'm trying to create dataclasses on the fly using make_dataclass (which
uses types.new_class). For new created classes, I have a cache to not
recreate twice the same class.
But I want to be sure not to override an existing class somewhere in the
namespace which is already 'types.MyNewclass'. but how to check it if
it's not in types ?
To be clear :
make_dataclass('Bla', {}) should raise an error if something named
'types.Bla' already exists.
I hope I'm clear enough.
Jimmy
--
https://mail.python.org/mailman/listinfo/python-list
Re: about types.new_class and module
On 2019-03-04 18:02, Jimmy Girardet wrote:
Hello,
I'm looking for an explanation where live classes created by
types.new_class() :
py> import types
py> types.new_class('A')
types.A
py> types.A
AttributeError: module 'types' has no attribute 'A'
py> _.__module__
'types'
The new class comes from `types` module without being inside.
That's annoying to me for my use case :
I'm trying to create dataclasses on the fly using make_dataclass (which
uses types.new_class). For new created classes, I have a cache to not
recreate twice the same class.
But I want to be sure not to override an existing class somewhere in the
namespace which is already 'types.MyNewclass'. but how to check it if
it's not in types ?
To be clear :
make_dataclass('Bla', {}) should raise an error if something named
'types.Bla' already exists.
I hope I'm clear enough.
'new_class' creates a new class with the given name and returns a
reference to it.
The class doesn't 'live' anywhere.
Although you might /think/ that an object lives in a certain namespace,
it's just that there's a name there that's bound to the object.
You can, in fact, create 2 classes with the same name.
>>> import types
>>> t1 = types.new_class('A')
>>> t2 = types.new_class('A')
>>> t1 is t2
False
--
https://mail.python.org/mailman/listinfo/python-list
Totally Legit Signing Key?
For once I tried to verify a download from python.org, following the steps outlined at https://www.python.org/downloads/#pubkeys """ You can import the release manager public keys by either downloading the public key file from here and then running gpg --import pubkeys.txt """ When I ran the command above I saw $ gpg --import pubkeys.txt gpg: Schlüssel 6F5E1540: "Ned Deily " 2 neue Signaturen gpg: Schlüssel 6A45C816: "Anthony Baxter " nicht geändert gpg: Schlüssel 36580288: "Georg Brandl (Python release signing key) " 2 neue Signaturen gpg: Schlüssel 7D9DC8D2: "Martin v. Löwis " nicht geändert gpg: Schlüssel 18ADD4FF: "Benjamin Peterson " 3 neue Signaturen gpg: Schlüssel A4135B38: "Benjamin Peterson " 1 neue Signatur gpg: Schlüssel A74B06BF: "Barry Warsaw " 138 neue Signaturen gpg: Schlüssel EA5BBD71: "Barry A. Warsaw " 6 neue Signaturen gpg: Schlüssel E6DF025C: "Ronald Oussoren " nicht geändert gpg: Schlüssel F73C700D: "Larry Hastings " 2 neue Signaturen gpg: Schlüssel AA65421D: "Ned Deily (Python release signing key) " 1 neue User-ID gpg: Schlüssel AA65421D: "Ned Deily (Python release signing key) " 20 neue Signaturen gpg: Schlüssel 487034E5: "Steve Dower (Python Release Signing) " 8 neue Signaturen gpg: Schlüssel 10250568: Öffentlicher Schlüssel "Łukasz Langa (GPG langa.pl) " importiert gpg: Schlüssel 487034E5: Öffentlicher Schlüssel "Totally Legit Signing Key " importiert gpg: Schlüssel F73C700D: Öffentlicher Schlüssel "Totally Legit Signing Key " importiert gpg: Schlüssel 6F5E1540: Öffentlicher Schlüssel "Totally Legit Signing Key " importiert gpg: Schlüssel AA65421D: Öffentlicher Schlüssel "Totally Legit Signing Key " importiert gpg: Schlüssel E6DF025C: Öffentlicher Schlüssel "Totally Legit Signing Key " importiert gpg: Schlüssel EA5BBD71: Öffentlicher Schlüssel "Totally Legit Signing Key " importiert [...] Now "totally legit" does sound like anything but "totally legit". Is there a problem with my machine, or python.org, or is this all "totally legit"? Advice or pointers welcome. -- https://mail.python.org/mailman/listinfo/python-list
Re: about types.new_class and module
Thank you for the clarification.
I thought everything was bounded to anything.
Shouldn't the name be changed from `types.A` to `unbound.A` to be less
confusing ?
Le 04/03/2019 à 20:31, MRAB a écrit :
'new_class' creates a new class with the given name and returns a
reference to it.
The class doesn't 'live' anywhere.
Although you might /think/ that an object lives in a certain
namespace, it's just that there's a name there that's bound to the
object.
You can, in fact, create 2 classes with the same name.
>>> import types
>>> t1 = types.new_class('A')
>>> t2 = types.new_class('A')
>>> t1 is t2
False
--
https://mail.python.org/mailman/listinfo/python-list
Re: about types.new_class and module
MRAB wrote:
> On 2019-03-04 18:02, Jimmy Girardet wrote:
>> Hello,
>>
>> I'm looking for an explanation where live classes created by
>> types.new_class() :
>>
>> py> import types
>>
>> py> types.new_class('A')
>>
>> types.A
>>
>> py> types.A
>>
>> AttributeError: module 'types' has no attribute 'A'
>>
>> py> _.__module__
>>
>> 'types'
>>
>>
>> The new class comes from `types` module without being inside.
>>
>> That's annoying to me for my use case :
>>
>> I'm trying to create dataclasses on the fly using make_dataclass (which
>> uses types.new_class). For new created classes, I have a cache to not
>> recreate twice the same class.
>>
>> But I want to be sure not to override an existing class somewhere in the
>> namespace which is already 'types.MyNewclass'. but how to check it if
>> it's not in types ?
>>
>> To be clear :
>>
>> make_dataclass('Bla', {}) should raise an error if something named
>> 'types.Bla' already exists.
>>
>> I hope I'm clear enough.
>>
> 'new_class' creates a new class with the given name and returns a
> reference to it.
>
> The class doesn't 'live' anywhere.
>
> Although you might /think/ that an object lives in a certain namespace,
> it's just that there's a name there that's bound to the object.
>
> You can, in fact, create 2 classes with the same name.
>
> >>> import types
> >>> t1 = types.new_class('A')
> >>> t2 = types.new_class('A')
> >>> t1 is t2
> False
However, the underlying type() call assumes that you are going to inject the
class into the current module -- which is why the OP's class appears to be
part of the types module
>>> types.new_class("Foo")
and
>>> type("Foo", (), {})
appears to be in __main__. This is correct in the majority of cases where
the class is defined with
class A:
pass
which can be thought of as syntactic sugar for
A = type("A", (), {})
In the case of types.new_class() it is rather confusing -- perhaps the
function should follow the example of collections.namedtuple and set the
__module__ attribute to the caller's namespace.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Totally Legit Signing Key?
Peter Otten <__pete...@web.de> writes: > $ gpg --import pubkeys.txt > […] > gpg: Schlüssel 487034E5: "Steve Dower (Python Release Signing) > " 8 neue Signaturen > gpg: Schlüssel 10250568: Öffentlicher Schlüssel "Łukasz Langa (GPG langa.pl) > " importiert > gpg: Schlüssel 487034E5: Öffentlicher Schlüssel "Totally Legit Signing Key > " importiert > gpg: Schlüssel F73C700D: Öffentlicher Schlüssel "Totally Legit Signing Key > " importiert > gpg: Schlüssel 6F5E1540: Öffentlicher Schlüssel "Totally Legit Signing Key > " importiert > gpg: Schlüssel AA65421D: Öffentlicher Schlüssel "Totally Legit Signing Key > " importiert > gpg: Schlüssel E6DF025C: Öffentlicher Schlüssel "Totally Legit Signing Key > " importiert > gpg: Schlüssel EA5BBD71: Öffentlicher Schlüssel "Totally Legit Signing Key > " importiert > [...] > > Now "totally legit" does sound like anything but "totally legit". Another clue is in the email address for that key: the ‘example.org’ domain is guaranteed to never resolve to any machine on the internet. There's nothing stopping anyone putting a fake email address, and any description they like, into a GnuPG userid. This was an inexpensive way to discover that :-) > Is there a problem with my machine, or python.org, or is this all > "totally legit"? Your computer, and your GnuPG program, are working as intended. Those specific signatures are made with a key that is bogus (and has been constructed to look as fake as it in fact is), and so you can ignore them. > Advice or pointers welcome. Cryptographic signatures should be trusted no more than you trust the provenance of the key that made the signature. -- \“Human reason is snatching everything to itself, leaving | `\ nothing for faith.” —Bernard of Clairvaux, 1090–1153 CE | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Totally Legit Signing Key?
On Tue, Mar 5, 2019 at 9:06 AM Ben Finney wrote: > > Peter Otten <__pete...@web.de> writes: > > > $ gpg --import pubkeys.txt > > […] > > gpg: Schlüssel 487034E5: "Steve Dower (Python Release Signing) > > " 8 neue Signaturen > > gpg: Schlüssel 10250568: Öffentlicher Schlüssel "Łukasz Langa (GPG > > langa.pl) " importiert > > gpg: Schlüssel 487034E5: Öffentlicher Schlüssel "Totally Legit Signing Key > > " importiert > > gpg: Schlüssel F73C700D: Öffentlicher Schlüssel "Totally Legit Signing Key > > " importiert > > gpg: Schlüssel 6F5E1540: Öffentlicher Schlüssel "Totally Legit Signing Key > > " importiert > > gpg: Schlüssel AA65421D: Öffentlicher Schlüssel "Totally Legit Signing Key > > " importiert > > gpg: Schlüssel E6DF025C: Öffentlicher Schlüssel "Totally Legit Signing Key > > " importiert > > gpg: Schlüssel EA5BBD71: Öffentlicher Schlüssel "Totally Legit Signing Key > > " importiert > > [...] > > > > Now "totally legit" does sound like anything but "totally legit". > > Another clue is in the email address for that key: the ‘example.org’ > domain is guaranteed to never resolve to any machine on the internet. (More or less - that domain DOES resolve (and has an explanatory web site running on both HTTP and HTTPS), but it's guaranteed never to be anything more significant than an example.) Also of note is that the user portion of the address is "Mallory", a well-known member of the "Alice and Bob" set of names. https://en.wikipedia.org/wiki/Alice_and_Bob#Cast_of_characters So I would expect these keys to be used for example malicious messages or mis-signed content, to test the recognition of legit signatures. If those keys are included in the pubkeys.txt download, it's minorly wasteful, but not a major problem. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Totally Legit Signing Key?
On 04/03/2019 20:37, Peter Otten wrote: > For once I tried to verify a download from python.org, following the steps > outlined at > > https://www.python.org/downloads/#pubkeys > > """ > You can import the release manager public keys by either downloading the > public key file from here and then running > > gpg --import pubkeys.txt > """ > > When I ran the command above I saw > > $ gpg --import pubkeys.txt > gpg: Schlüssel 6F5E1540: "Ned Deily " 2 neue Signaturen > gpg: Schlüssel 6A45C816: "Anthony Baxter " nicht > geändert > gpg: Schlüssel 36580288: "Georg Brandl (Python release signing key) > " 2 neue Signaturen > gpg: Schlüssel 7D9DC8D2: "Martin v. Löwis " nicht geändert > gpg: Schlüssel 18ADD4FF: "Benjamin Peterson " 3 neue > Signaturen > gpg: Schlüssel A4135B38: "Benjamin Peterson " 1 neue > Signatur > gpg: Schlüssel A74B06BF: "Barry Warsaw " 138 neue Signaturen > gpg: Schlüssel EA5BBD71: "Barry A. Warsaw " 6 neue Signaturen > gpg: Schlüssel E6DF025C: "Ronald Oussoren " nicht > geändert > gpg: Schlüssel F73C700D: "Larry Hastings " 2 neue > Signaturen > gpg: Schlüssel AA65421D: "Ned Deily (Python release signing key) > " 1 neue User-ID > gpg: Schlüssel AA65421D: "Ned Deily (Python release signing key) > " 20 neue Signaturen > gpg: Schlüssel 487034E5: "Steve Dower (Python Release Signing) > " 8 neue Signaturen > gpg: Schlüssel 10250568: Öffentlicher Schlüssel "Łukasz Langa (GPG langa.pl) > " importiert > gpg: Schlüssel 487034E5: Öffentlicher Schlüssel "Totally Legit Signing Key > " importiert > gpg: Schlüssel F73C700D: Öffentlicher Schlüssel "Totally Legit Signing Key > " importiert > gpg: Schlüssel 6F5E1540: Öffentlicher Schlüssel "Totally Legit Signing Key > " importiert > gpg: Schlüssel AA65421D: Öffentlicher Schlüssel "Totally Legit Signing Key > " importiert > gpg: Schlüssel E6DF025C: Öffentlicher Schlüssel "Totally Legit Signing Key > " importiert > gpg: Schlüssel EA5BBD71: Öffentlicher Schlüssel "Totally Legit Signing Key > " importiert > [...] Everything's working fine on your end. If you have a closer look, you'll see that all of the "Totally Legit" keys have key IDs that are identical to key IDs of actual Python release managers. e.g. in the last line, EA5BBD71 refers to the key pub rsa1024 2015-05-22 [C] 801BD5AE93D392E22DDC6C7AFEA3DC6DEA5BBD71 uid [ unknown] Totally Legit Signing Key but it ALSO refers to the key pub dsa1024 2005-11-24 [SC] DBBF2EEBF925FAADCF1F3FFFD9866941EA5BBD71 uid [ unknown] Barry A. Warsaw uid [ unknown] Barry A. Warsaw uid [ unknown] Barry A. Warsaw uid [ unknown] Barry A. Warsaw uid [ unknown] Barry Warsaw (GNU Mailman) uid [ unknown] Barry A. Warsaw sub elg2048 2005-11-24 [E] The thing is that 32-bit key IDs are not secure and can easily be cloned. [1] I imagine that Barry at least knows this, seeing as he apparently cloned his own old (compromised) key: pub rsa1024 2014-06-16 [SCEA] [revoked: 2016-08-16] 2C7E264D238159CB07A3C350192720F7EA5BBD71 uid [ revoked] Barry A. Warsaw What I imagine happened here is that whoever exported the pubkeys.txt file did so on the basis of 32-bit key IDs. This is not ideal, as it pulled in bogus keys, but there's no real harm done. For good measure, I've put this on bpo (36191) -- Thomas [1] https://evil32.com/ > > Now "totally legit" does sound like anything but "totally legit". Is there a > problem with my machine, or python.org, or is this all "totally legit"? > > Advice or pointers welcome. > > -- https://mail.python.org/mailman/listinfo/python-list
Re: Decodificar base64 en Odoo 12
El lunes, 4 de marzo de 2019, 11:07:40 (UTC-6), Peter Otten escribió: > Angie GL wrote: > > > Hola a todos, tengo un problema al decodificar el contenido de una > > variable base64. > > > > De esta manera lo hago: > > > > cfdi = base64.b64decode(inv.l10n_mx_edi_cfdi) > > > > > > > > Al momento de decodificar el resultado que me envía es esto: > > > > b'\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n' > > > > Alguien que me pueda decir que estoy haciendo mal, lo cheque en la consola > > Python3 y todo va bien, pero dentro de Odoo no lo decodifica. > > What result did you expect? > > What is the value of inv.l10n_mx_edi_cfdi? For > > b'CgogCiAKIAogCiAKIAogCiAKIAogCiAKIAogCiAKIAogCgo=' > > you see the correct result: > > >>> base64.b64decode(b'CgogCiAKIAogCiAKIAogCiAKIAogCiAKIAogCiAKIAogCgo=') > b'\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n' El valor de la variable inv.l10n_mx_edi_cfdi es una factura en formato base64, el resultado que espero es que decodifique la factura para posteriormente mostrarlo. PERO NO LO DECODIFICA,ya verifique el valor de la variable pero no lo hace. -- https://mail.python.org/mailman/listinfo/python-list
Re: "How to package additional files under site-packages "
Saba Kauser writes: > ... > I want data_files to be copied under my package install path. > How do I achieve this? You could look at one of my packages (i.e. "dm.*", e.g. "dm.pdb"). Essentially, I have the data files besides the Python sources and let "setuptools" determine the relevant files (sources and data) as those managed via a source code control system (=SCCS). For the latter to work, your Python must have installed the integration module for your SCCS. -- https://mail.python.org/mailman/listinfo/python-list
