Re: Decodificar base64 en Odoo 12

[Peter Otten]

angiielovee...@gmail.com wrote:

> 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.

If you replace the line

>> > cfdi = base64.b64decode(inv.l10n_mx_edi_cfdi)

in your script with

cfdi = inv.l10n_mx_edi_cfdi
print(type(cfdi))
print(repr(cfdi))
cfdi = base64.b64decode(cdfi)
print(repr(cfdi))

what gets printed? Use cut and paste to post the result. If there is a 
traceback post that, too. Thank you.


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

ANN: Wing Python IDE 6.1.5 released

[Wingware]

Wing Python IDE version 6.1.5 is now available for download 
.



 Changes in 6.1.5

 * Improves code intelligence for extension modules on remote hosts
   
 * Adds a debug status icon to the debug process selector, and does a
   better job truncating items in the process selection menu
 * Checks for conflicts before introducing names with refactoring
    operations, to avoid
   inadvertently reusing an existing symbol name
 * Improves support for py.exe on Windows, so that the correct Python
   version is launched

This release also makes about 30 other minor improvements. See the 
change log  for 
details.



 About Wing

Wingware's family of cross-platform Python IDEs provide powerful 
integrated editing, debugging, unit testing, and project management 
features for interactive Python development. Wing can speed development 
and improve code quality for any kind of Python project, including web, 
desktop, scientific, data analysis, embedded scripting, and other 
applications.


For more information, please visit wingware.com 

Stephan Deibel
Wing Python IDE | The Intelligent Development Environment for Python


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

Class Issue`

[Milt]

The following code gives me unusual results - base on experience with C++.

class Car:
   # carColor = None
   # mileage = None

   def __init__(self, color = None, miles = None):
  self.mileage = miles
  self.carColor = color

   def print(self):
  print(f"Color:   {self.carColor}")
  print(f"Mileage: {self.mileage}")

myCar = Car('blue', 15000)
myCar.print()

print()

myCar = Car(25000, 'orange')
myCar.print()


When executed the following results:

Color:   blue
Mileage: 15000

Color:   25000
Mileage: orange

It appears that the constructor ignores the assignment statements and 
makes the assignment based on the ordering in the __init__ declaration.

--
Regards,

Milt

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

Re: Class Issue`

[Chris Angelico]

On Wed, Mar 6, 2019 at 10:01 AM Milt  wrote:
>
> The following code gives me unusual results - base on experience with C++.
> def __init__(self, color = None, miles = None):
>self.mileage = miles
>self.carColor = color
>
> myCar = Car('blue', 15000)
> myCar = Car(25000, 'orange')
>
> It appears that the constructor ignores the assignment statements and
> makes the assignment based on the ordering in the __init__ declaration.

Based on your experience with C++, what tells the compiler that you
can pass arguments in any order? Would you write multiple constructors
taking different arguments? Because you didn't do that here.

What you CAN do is call the constructor with keyword arguments:

Car(color='blue', miles=15000)
Car(miles=25000, color='orange')

But otherwise, Python (just like C++) will pass the arguments in the
order you wrote them.

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

Re: Class Issue`

[Kevin Hu]

I believe for the correct behavior you’ll need:

myCar = Car(color=‘blue’, miles=15000)

myCar = Car(miles=25000, color=‘orange’)

In which case both objects will be initialized as the way you’d expect. 

Python is a language with very weak typing, and it’ll happily shoehorn data 
into variables even when you don’t expect it to. In this case it’ll assign 
arguments to parameters in order, which is the expected behavior.

Regards,
Kevin

> On Mar 5, 2019, at 16:39, Milt  wrote:
> 
> The following code gives me unusual results - base on experience with C++.
> 
> class Car:
># carColor = None
># mileage = None
> 
>def __init__(self, color = None, miles = None):
>   self.mileage = miles
>   self.carColor = color
> 
>def print(self):
>   print(f"Color:   {self.carColor}")
>   print(f"Mileage: {self.mileage}")
> 
> myCar = Car('blue', 15000)
> myCar.print()
> 
> print()
> 
> myCar = Car(25000, 'orange')
> myCar.print()
> 
> 
> When executed the following results:
> 
> Color:   blue
> Mileage: 15000
> 
> Color:   25000
> Mileage: orange
> 
> It appears that the constructor ignores the assignment statements and makes 
> the assignment based on the ordering in the __init__ declaration.
> -- 
> Regards,
> 
> Milt
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

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

Re: Decodificar base64 en Odoo 12

[angiielovee177]

El martes, 5 de marzo de 2019, 3:05:07 (UTC-6), Peter Otten escribió:
> angiielovee...@gmail.com wrote:
> 
> > 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.
> 
> If you replace the line
> 
> >> > cfdi = base64.b64decode(inv.l10n_mx_edi_cfdi)
> 
> in your script with
> 
> cfdi = inv.l10n_mx_edi_cfdi
> print(type(cfdi))
> print(repr(cfdi))
> cfdi = base64.b64decode(cdfi)
> print(repr(cfdi))
> 
> what gets printed? Use cut and paste to post the result. If there is a 
> traceback post that, too. Thank you.

Este es el resultado de cada linea:

> cfdi = inv.l10n_mx_edi_cfdi
> print(type(cfdi)) No imprime nada
> print(repr(cfdi)) Imprime la cadena en base64, es bastabte 
> larga.(b'PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz4KPGNmZGk6Q29tcHJvYmFudGUgeG1sbnM6Y2ZkaT0iaHR0cDovL3d3dy5zYXQuZ29iLm14L2NmZC8zIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4c2k6c2NoZW1hTG9jYXRpb249Imh0dHA6Ly93d3cuc2F0LmdvYi5teC9jZmQvMyBodHRwOi8vd3d3LnNhdC5nb2IubXgvc2l0aW9faW50ZXJuZXQvY2ZkLzMvY2ZkdjMzLnhzZCIgVmVyc2lvbj0iMy4zIiBTZWxsbz0iR1k1MVlrd1FCTC9vL2I2ZHA4aXBXcFM1MjlZcTFNSkdXV2IwN1VodW82UXFzb3I2MGJKNGZOVWZjS0t5YlVOR0tud0RCTEJ0c2tZTDVUVFU1SThLZ2MxbkxTYzZXdkl5YXcxQkVYd0hVSXdUM1pJSXBjYXhITTVadzRrMkhCZ0JraDZ3SndoOVAwZWN1Mk94bXd4dkhoMmhrUGRCbVNXcm1SUWt3NThVNWpieStqU1ltTW9SOUZacnVPVEt6NXlseTNUamJZODBwMUt0MXNOZXhJQW9rM0ZIbEQ4cmhrZmVLVDVyam10WXZ2Q2l2NmhuaVExclBPeHpYek1TY3VXY0pCZFJvQ1AxUmRGVkNmY1FxOVF1Umptb3VTRW9HZzl5N1BkSFlNa01vZnNnRXJuaGg2ZXcwRncrWUtyMFV5V1lNSHMvZ2JJckxucHJndlRXTmVnNG5RPT0iIEZlY2hhPSIyMDE5LTAzLTA0VDE1OjE3OjAyIiBGb2xpbz0iMTEiIFNlcmllPSJJTlYvMjAxOS8iIEZvcm1hUGFnbz0iMDQiIE5vQ2VydGlmaWNhZG89IjIwMDAxMDAwMDAwMzAwMDIyODE1IiBDZXJ0aWZpY2Fkbz0iTUlJRnhUQ0NBNjJnQXdJQkFnSVVNakF3TURFd01EQXdNREF6TURBd01qSTRNVFV3RFFZSktvWklodmNOQVFFTEJRQXdnZ0ZtTVNBd0hnWURWUVFEREJkQkxrTXVJRElnWkdVZ2NISjFaV0poY3lnME1EazJLVEV2TUMwR0ExVUVDZ3dtVTJWeWRtbGphVzhnWkdVZ1FXUnRhVzVwYzNSeVlXTnB3N051SUZSeWFXSjFkR0Z5YVdFeE9EQTJCZ05WQkFzTUwwRmtiV2x1YVhOMGNtRmphY096YmlCa1pTQlRaV2QxY21sa1lXUWdaR1VnYkdFZ1NXNW1iM0p0WVdOcHc3TnVNU2t3SndZSktvWklodmNOQVFrQkZocGhjMmx6Ym1WMFFIQnlkV1ZpWVhNdWMyRjBMbWR2WWk1dGVERW1NQ1FHQTFVRUNRd2RRWFl1SUVocFpHRnNaMjhnTnpjc0lFTnZiQzRnUjNWbGNuSmxjbTh4RGpBTUJnTlZCQkVNQlRBMk16QXdNUXN3Q1FZRFZRUUdFd0pOV0RFWk1CY0dBMVVFQ0F3UVJHbHpkSEpwZEc4Z1JtVmtaWEpoYkRFU01CQUdBMVVFQnd3SlEyOTViMkZqdzZGdU1SVXdFd1lEVlFRdEV3eFRRVlE1TnpBM01ERk9Uak14SVRBZkJna3Foa2lHOXcwQkNRSU1FbEpsYzNCdmJuTmhZbXhsT2lCQlEwUk5RVEFlRncweE5qRXdNalV5TVRVeU1URmFGdzB5TURFd01qVXlNVFV5TVRGYU1JR3hNUm93R0FZRFZRUURFeEZEU1U1RVJVMUZXQ0JUUVNCRVJTQkRWakVhTUJnR0ExVUVLUk1SUTBsT1JFVk5SVmdnVTBFZ1JFVWdRMVl4R2pBWUJnTlZCQW9URVVOSlRrUkZUVVZZSUZOQklFUkZJRU5XTVNVd0l3WURWUVF0RXh4TVFVNDNNREE0TVRjelVqVWdMeUJHVlVGQ056Y3dNVEUzUWxoQk1SNHdIQVlEVlFRRkV4VWdMeUJHVlVGQ056Y3dNVEUzVFVSR1VrNU9NRGt4RkRBU0JnTlZCQXNVQzFCeWRXVmlZVjlEUmtSSk1JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBZ3Z2Q2lDRkRGVmFZWDd4ZFZSaHAvMzhVTFd0by9MS0RTWnkxeXJYS3BhcUZYcUVSSldGNzhZSEtmM041R0JvWGd6d0ZQdURYKzVrdlk1d3RZTnh4L093dTJzaE5acUZGaDZFS3N5c1FNZVA1cno2a0UxZ0ZZZW5hUEVVUDl6aitoMGJMM3hSNWFxb1RzcUdGMjRtS0JMb2lhSzQ0cFhCekd6Z3N4WmlzaFZKVk02WGJ6TkpWb25FVU5iSTI1RGhnV0FkODZmMmFVM0JtT0gySzFSWng0MWR0VFQ1NlVzc3pKbHM0dFBGT0RyL2NhV3VaRXVVdkxwMU0zbmo3RHl1ODhtaEQyZisxZkEvZzdremNVLzF0Y3BGWEYvckl5OTNBUHZrVTcyand2a3JucHJ6cytTbkc4MSsvRjE2YWh1R3NiMkVaODhkS0h3cXhFa3d6aE15VGJRSURBUUFCb3gwd0d6QU1CZ05WSFJNQkFmOEVBakFBTUFzR0ExVWREd1FFQXdJR3dEQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FnRUFKL3hrTDhJK2ZwaWxaUCs5YU84bjkzKzIwWHhWb21MSmplU0wrTmcyRXJMMkdnYXRwTHVONUprbkZCa1pBaHhWSWdNYVRTMjN6emsxUkx0UmFZdkg4M2xCSDVFK00ra0VqRkdwMTRGbmUxaVYyUG0zdkw0amVMbXpIZ1kxS2Y1SG1lVnJycDRQVTdXUWcxNlZweUhhSi9lb25QTmlFQlVqY3lRMWlGZmt6Sm1uU0p2REd0ZlFLMlRpRW9sREpBcFl2ME9XZG00aXM5QnNmaTlqNmxJOS9UNk1OWisvTE0yTC90NzJWYXU0cjdtOTRKREV6YU8zQTB3SEF0UTk3ZmpCZkJpTzVNOEFFSVNBVjdlWmlkSWwzaWFKSkhrUWJCWWlpVzJnaWtyZVVaS1BVWDBIbWxuSXFxUWNCS

Re: Class Issue`

[DL Neil]

Milt,

On 6/03/19 11:39 AM, Milt wrote:

The following code gives me unusual results - base on experience with C++.
class Car:
    # carColor = None
    # mileage = None
    def __init__(self, color = None, miles = None):
   self.mileage = miles
   self.carColor = color
    def print(self):
   print(f"Color:   {self.carColor}")
   print(f"Mileage: {self.mileage}")
myCar = Car('blue', 15000)
myCar.print()
print()
myCar = Car(25000, 'orange')
myCar.print()

When executed the following results:
Color:   blue
Mileage: 15000
Color:   25000
Mileage: orange
It appears that the constructor ignores the assignment statements and 
makes the assignment based on the ordering in the __init__ declaration.



It is risky to decide that Python should behave in a certain fashion, 
just because another language does. Would you decide that the word 
"blue" may not be used because in French it is "bleu"? If all 
programming languages did look/work the same way, why would there be 
multiple languages? However, your understanding of C++ gives you a 
flying start with Python - apart from a few pesky 'gotchas'!



In the term "ignores the assignment statements", what "assignment 
statements" are being discussed?



Yes, without keywords, the positional rule applies.

myCar = Car('blue', 15000)
is the same as:
myCar = Car(color = 'blue', miles = 15000)

Instead of:
myCar = Car(25000, 'orange')
try:
myCar = Car(miles=25000, color='orange')

If you've gone to the trouble of defining keyword-arguments in the 
method, greater satisfaction will be gained from calling the method 
similarly (and cause less confusion on the part of your readers!)



Meantime I have a very low-mileage Edsel in an attractive lemon color, 
going cheap...



Jokes aside: using the __str__() and __repr__() "magic methods" is more 
'pythonic' than adding a print method to a class.


For a nicely-formatted output (albeit without mentioning that it is 
describing a "Car" or "myCar" - per print(), above):


 def __str__(self):
return f"Color:   {self.carColor}\nMileage: {self.mileage}"
...
myCar = Car(color = 'blue', miles = 15000)
print( myCar )

For extra credit, seeing we're talking about 'being pythonic': car_color 
and my_car.



Alternately, to present the output formatted as a class definition/ready 
for instantiation:


 def __repr__(self):
return f"Car( color={self.car_color}, miles={self.mileage} )"

NB if both methods appear in a class, printing the class (ie print( 
my_car ) ) will prefer __repr__() over __str__().



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

Re: Class Issue`

[eryk sun]

On 3/5/19, Kevin Hu  wrote:
>
> Python is a language with very weak typing, and it’ll happily shoehorn data
> into variables even when you don’t expect it to.

Python has strong typing, in that it doesn't implicitly coerce
unrelated types in expressions. However, it has no enforced static
typing of variables. It relies on runtime type checking and protocols.
The term "duck typing" was coined for this case.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Class Issue`

[Terry Reedy]

On 3/5/2019 6:11 PM, Kevin Hu wrote:


Python is a language with very weak typing,


Python runtime objects are strongly dynamically typed.  Their type/class 
is one of their attributes.  All classes are subclasses of class 
'object'.  Python names (variables) are untyped in a sense, or one could 
say their default type is 'object'.


and it’ll happily shoehorn data into variables

This describes C, which puts data into permanently names blocks of 
memory.  Python puts data into objects, not names.  It associates 
names/variables with objects.


it’ll assign arguments to parameters in order, which is the expected 
behavior.


Parameters are names and arguments are objects.  Yes, if the arguments 
are not named in a called, they named in order.


--
Terry Jan Reedy


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

RE: "How to package additional files under site-packages "

[Saba Kauser]

Thanks!
My package (ibm_db) has LICENSE, README.md and CHANGES files that I want to be 
available in the same location as my package is installed I.e under 
site-packages. However, with current setup.py 
https://github.com/ibmdb/python-ibmdb/blob/master/IBM_DB/ibm_db/setup.py, these 
files get installed under python install path.
e.g: C:\Users\skauser\AppData\Local\Programs\Python\Python36\LICENSE

I have specified them as:
data_files = [ ('', ['./README.md']),
   ('', ['./CHANGES']),
   ('', ['./LICENSE']) ]

Setup(
..
package_data = package_data,
   data_files   = data_files,
   include_package_data = True,
  cmdclass = cmd_class,
..)

Since the directory path is empty, these files get copied under current path of 
execution. However, I want them to be copied under the install location of my 
package.
Is there any other way I can achieve this?

Thanks!

-Original Message-
From: dieter 
Sent: Tuesday, March 5, 2019 12:04 PM
To: python-list@python.org
Subject: 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.



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

Re: "How to package additional files under site-packages "

[dieter]

Saba Kauser  writes:
> ...
> My package (ibm_db) has LICENSE, README.md and CHANGES files that I want to 
> be available in the same location as my package is installed I.e under 
> site-packages. However, with current setup.py 
> https://github.com/ibmdb/python-ibmdb/blob/master/IBM_DB/ibm_db/setup.py, 
> these files get installed under python install path.
> e.g: C:\Users\skauser\AppData\Local\Programs\Python\Python36\LICENSE
>
> I have specified them as:
> data_files = [ ('', ['./README.md']),
>('', ['./CHANGES']),
>('', ['./LICENSE']) ]
>
> Setup(
> ..
> package_data = package_data,
>data_files   = data_files,
>include_package_data = True,
>   cmdclass = cmd_class,
> ..)
>
> Since the directory path is empty, these files get copied under current path 
> of execution. However, I want them to be copied under the install location of 
> my package.
> Is there any other way I can achieve this?

As you do not want to follow my example, maybe read the
"setuptools" documentation.

There definitely is a way to achieve your goal -- other than
my approach. If necessary override parts of the "distutils/setuptools"
machinery.

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