Re: Shall I worry about python2/3 compatibility when using library?

[Thomas Jollans]

On 31/08/18 04:27, Stone Zhong wrote:

Hi there,

I think the fact is:
- There are still considerable amount of people still using python2
- Python2 user will eventually upgrade to python3

So any library not written in a compatible way will either break now for 
python2 user, or will break in the future for python3 user. So I suppose all 
library developer are writing compatible code, is that a fair assumption?

Thanks,
Stone


See https://python3statement.org/

Some older libraries that used to maintain a compatible codebase have 
already dropped Python 2 support, and other have moved to supporting new 
features on Python 3 only. Many will drop Python 2 support no later than 
2020.



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

Re: Shall I worry about python2/3 compatibility when using library?

[Mark Lawrence]

On 31/08/18 06:33, Stone Zhong wrote:

On Thursday, August 30, 2018 at 10:19:34 PM UTC-7, Terry Reedy wrote:

On 8/30/2018 10:27 PM, Stone Zhong wrote:

Hi there,

I think the fact is:
- There are still considerable amount of people still using python2
- Python2 user will eventually upgrade to python3

So any library not written in a compatible way will either break now for 
python2 user, or will break in the future for python3 user. So I suppose all 
library developer are writing compatible code, is that a fair assumption?


No.  Many people write new libraries only for recent version of Python
3.  Many people who have written Python 2 and 3 compatible libraries, or
Python 2 and Python 3 versions of of their library, have or will drop
Python 2 support for enhancements and even bugfixes for their library.

That said, some people will continue to use existing python 2 code for a
decade or more.

--
Terry Jan Reedy


Thanks for the reply Terry. Got it.

So some people main separate libraries for python2 and python3 (although this 
way it may have extra cost), and may eventually drop support for python2 lib or 
may not even have library for python2.

Thanks,
Stone



Not really as many libraries dropped support for Python 2 some years 
back.  Just one example is the extremely popular plotting library 
matplotlib which has just put out release candidates for version 3.0.0. 
This only supports Python 3.5+.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

EuroPython 2018: Videos for Thursday available

[M.-A. Lemburg]

We are pleased to announce the second batch of cut videos from
EuroPython 2018 in Edinburgh, Scotland, UK.


 * EuroPython 2018 YouTube Playlist *

https://www.youtube.com/watch?v=scum5a_mqBc&t=0s&index=84&list=PL8uoeex94UhFrNUV2m5MigREebUms39U5


In this batch, we have included all videos for Thursday, July 26 2018,
the second conference day.

Next week we will publish videos for the final conference day. In
total, we will have more than 130 videos available for you to watch.

All EuroPython videos, including the ones from previous conferences,
are available on our EuroPython YouTube Channel.

http://europython.tv/


Help spread the word


Please help us spread this message by sharing it on your social
networks as widely as possible. Thank you !

Link to the blog post:

https://blog.europython.eu/post/177582893492/europython-2018-videos-for-thursday-available

Tweet:

https://twitter.com/europython/status/1035471566606397440


Enjoy,
--
EuroPython 2018 Team
https://ep2018.europython.eu/
https://www.europython-society.org/

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

Re: Shall I worry about python2/3 compatibility when using library?

[Grant Edwards]

On 2018-08-31, Terry Reedy  wrote:

> That said, some people will continue to use existing python 2 code for a 
> decade or more.

People like me.  I do a lot of serial and network protocol handling in
Python, and the changes to the handling of bytes vs. strings in Python
3 means that sort of thing is less work in Python 2.

-- 
Grant Edwards   grant.b.edwardsYow! Wait ... is this a FUN
  at   THING or the END of LIFE in
  gmail.comPetticoat Junction??

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

Verifying the integrity/lineage of a file

[Malcolm Greene]

I have use case where I need to distribute binary files to customers and
want to provide a way for our customers to verify the
"integrity/lineage" (I know there's a better description, but can't
think of it) of these files, eg. to give them the confidence that the
files in question are from me and haven't been altered.
Here's the methods I can think of using Python:

1. Use hashlib to hash each file (SHA256)+ and send the hashes
   separately for verification2. Use hmac to sign each file
3. Use a 3rd party crypto library to sign each file and use a set of
   public/private SSH keys for verification
Any suggestions on techniques and/or libraries appreciated. 

Thank you,
Malcolm
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Verifying the integrity/lineage of a file

[Thomas Jollans]

On 2018-08-31 16:36, Malcolm Greene wrote:
> I have use case where I need to distribute binary files to customers and
> want to provide a way for our customers to verify the
> "integrity/lineage" (I know there's a better description, but can't
> think of it) of these files, eg. to give them the confidence that the
> files in question are from me and haven't been altered.
> Here's the methods I can think of using Python:
> 
> 1. Use hashlib to hash each file (SHA256)+ and send the hashes
>separately for verification2. Use hmac to sign each file
> 3. Use a 3rd party crypto library to sign each file and use a set of
>public/private SSH keys for verification
> Any suggestions on techniques and/or libraries appreciated. 
> 
> Thank you,
> Malcolm
> 

The two most common methods used in open source projects are checksums
(that you could generate with hashlib) and GPG signatures. Often (e.g.
[1]) these are combined: provide a signed list of checksums.

[1] http://cdimage.ubuntu.com/ubuntu/releases/bionic/release/

What you're describing sounds like a good use of GPG/PGP signatures.
Just sending hashes leaves open the question of the integrity of the
message containing the hashes, but it's certainly the simplest solution.
I'm not qualified to comment on HMAC.
-- 
https://mail.python.org/mailman/listinfo/python-list

bytes() or .encode() for encoding str's as bytes?

[Malcolm Greene]

Is there a benefit to using one of these techniques over the other?
Is one approach more Pythonic and preferred over the other for
style reasons?
message = message.encode('UTF-8')
message = bytes(message, 'UTF-8')

Thank you,
Malcolm
-- 
https://mail.python.org/mailman/listinfo/python-list

training materials and learning environment for teaching kids python available

[Kent Tong]

Hi all,

This is a set of training materials I used to successfully teach Python to kids 
as little as 10 years old. It was a success because the kids didn't just finish 
the course, they independently completed most of the coding challenges by 
applying the knowledge they had learned.

The first four lessons (Lesson 1, Lesson 2, Lesson 3, Lesson 4) and a lite 
version of the learning environment are freely available at:
https://www.istudycenter.org/yes-kids-can-learn-python

Let me know if you like it.

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

Re: Verifying the integrity/lineage of a file

[Peter Pearson]

On Fri, 31 Aug 2018 08:36:52 -0600, Malcolm Greene  wrote:
> I have use case where I need to distribute binary files to customers and
> want to provide a way for our customers to verify the
> "integrity/lineage" (I know there's a better description, but can't
> think of it) of these files, eg. to give them the confidence that the
> files in question are from me and haven't been altered.
[snip]

This is exactly what digital signatures are for.  GPG is free, and will
serve as well as anything.  Generate a public/private key pair, email
the public key to the customer, and phone the customer to compare key
"fingerprints" to verify that the key hasn't been altered in transit
(very unlikely, but cryptologists are a cautious bunch).

Just using HMAC requires sharing a secret with the customer, which
means that you have to trust the customer not to forge authentications.
A real digital signature avoids this problem by separating the signing
key (your private key) from the verifying key (the public key).

-- 
To email me, substitute nowhere->runbox, invalid->com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Broken pip

[Michael F. Stemper]

On 2018-08-29 16:02, Thomas Jollans wrote:
> On 08/29/2018 09:05 PM, Michael F. Stemper wrote:

>>> Also, PLEASE use Python 3. Still using Python 2 today is like still
>>> using Windows XP in early 2013.
>> I'm using the default version for the current release of my
>> OS (Ubuntu 16.04 LTS):

>> My understanding is that when I get around to upgrading to 18.04 LTS,
>> python3 will be the default.
>>
>> Since I don't hard-code a version in any of my programs, but simply
>> write "#!/usr/bin/python", all of my programs will automatically change
>> to the new version then.
> 
> No, actually.
> 
> As I understand it, Ubuntu 18.04 LTS uses python2 a lot less, and I
> don't think it's included in the default install. However, it's still in
> main, the name of the package is still "python", and it's still required
> by some common software... (including the recommended personal backup
> tool, duplicity :-/)

Interesting. I based my statement on
, which says:
"Python 3 only on the default installs for desktop, server, [...]"

Since this says "plans", not "accomplishments", I searched further
and found

where they say: "Python 2 is no longer installed by default."

I'm having trouble parsing this. If it's not in the default
installation, I'm not sure how it can be required. Conversely, if
it's required, I'm not sure how it can be left out of the default
installation.

> In any case, as per PEP 394, /usr/bin/python continues to point to
> Python 2.7 (if installed), it it will likely remain that way for the
> foreseeable future. (including, presumably, Ubuntu 20.04 LTS)
> 
> PEP 394: https://www.python.org/dev/peps/pep-0394/

Boy, that led me down any number of rabbit holes. :-> I spent most of
yesterday following where it led me. I'm not yet persuaded, but at least
I'm better aware of some of the issues.

>> If I was to change all of my programs to say "#!/usr/bin/python3", I'd
>> have a slight head-start. However, then I'd need to change them all
>> again when python 4 came out. And python 5.
>>
>> I prefer to maintain version independence, or at least to avoid
>> implementing version dependence.
> 
> You should know that there were some (deliberate) incompatible changes
> (vastly for the better) in Python 3.0 (almost ten years ago). It's
> normally easy to port your code, and not too hard to write code that
> runs on both Python 2 and Python 3 if required, but in any case you have
> to do this consciously,

I definitely do that. I use "//" for integer division, I never use
either "print" or "print()". I'm not sophisticated enough to do version
sniffing or binary files or non-ASCII text.

Every time I change one of my modules, I run the test code under both
python and python3.

By PEP 394:

"One exception to this is scripts that are deliberately written to be
source compatible with both Python 2.x and 3.x. Such scripts may
continue to use python on their shebang line."

> As for the "Python 4 problem" – at the moment nobody knows whether there
> will even /be/ a Python 4.

For what it's worth,

says:
"The problem with this code is what happens when Python 4 comes out?"


Anyhow, you've given me a lot to think about, for which I thank you.

-- 
Michael F. Stemper
Exodus 22:21
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: bytes() or .encode() for encoding str's as bytes?

[Marko Rauhamaa]

Malcolm Greene :
> Is there a benefit to using one of these techniques over the other?
> Is one approach more Pythonic and preferred over the other for
> style reasons?
> message = message.encode('UTF-8')
> message = bytes(message, 'UTF-8')

I always use the former. I wonder why that is. I guess the aesthetic
rule is something along the lines: use a dot if you can.


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

Re: Verifying the integrity/lineage of a file

[Malcolm Greene]

Thanks for the replies! I'm going to investigate the use of python-gnupg  [1] 
which is a Python wrapper for the GPG command line utility. This library is 
based on gpg.py written by Andrew Kuchling.  I'm all ears if f anyone has any 
alternative recommendations or python-gnupg tips to share. BTW: Target clients 
are running under Windows and Linux.

[1] https://pythonhosted.org/python-gnupg/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: bytes() or .encode() for encoding str's as bytes?

[Cameron Simpson]

On 31Aug2018 21:44, Marko Rauhamaa  wrote:

Malcolm Greene :

Is there a benefit to using one of these techniques over the other?
Is one approach more Pythonic and preferred over the other for
style reasons?
message = message.encode('UTF-8')
message = bytes(message, 'UTF-8')


I always use the former. I wonder why that is. I guess the aesthetic
rule is something along the lines: use a dot if you can.


I also use the former.

You could give any class an encode method; the latter works only for strings.  
Of course, an encode method accepting a Unicode encoding name is pretty string 
specific, but imagine:


 f.write(message.encode('UTF-8'))
 f.write(something.encode('big-endian'))

etc. A little more symmetric.

And I confess to not knowing of the "bytes(str, encoding)" form until now.

The flip side is that you can give classes a __bytes__ method, and go:

 f.write(bytes(something))

I've got a class which works that way, should the user want it.

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

Looking for someone proficient in Python to update a website.

[Stacy Brewer]

Hello! I’m not sure if this is the right forum, but I am looking for someone 
proficient in Python software to update a website. 

I will pay well, and work in the Kansas City area. If this is not the correct 
way to find someone who can help, do you have any contacts in the Kansas City 
area who can assist? 

Please respond via email to st...@greaterozarksbowling.com

Sent from my iPhone

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

Re: Question about floating point

[Steven D'Aprano]

On Fri, 31 Aug 2018 18:45:16 +1200, Gregory Ewing wrote:

> Steven D'Aprano wrote:
>> The right way is to
>> set the rounding mode at the start of your application, and then let
>> the Decimal type round each calculation that needs rounding.
> 
> It's not clear what you mean by "rounding mode" here. If you mean
> whether it's up/down/even/whatever, then yes, you can probably set that
> as a default and leave it.

I mean the rounding mode :-)

https://docs.python.org/3/library/decimal.html#rounding-modes


> However, as far as I can see, Decimal doesn't provide a way of setting a
> default number of decimal places to which results are rounded. You can
> set a default *precision*, but that's not the same thing.

Indeed it is not. That's a very good point, and I had completely 
forgotten about it! Thank you.

The quantize method is intended for the use-case we are discussing, to 
round values to a fixed number of decimal places. The Decimal FAQs 
mention that:

https://docs.python.org/3/library/decimal.html#decimal-faq

I think this is a good use-case for subclassing Decimal as a Money class.

[...]
> I don't think this is a bad thing, because often you don't want to use
> the same number of places for everything, For example, people dealing
> with high-volume low-value goods often calculate with unit prices having
> more than 2 decimal places. In those kinds of situations, you need to
> know exactly what you're doing every step of the way.

As opposed to anyone else calculating with money?




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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