Mailman 3 June 2018 - Python-ideas

Allow mutable builtin types (optionally)
by Eloi Gaudry June 26, 2018

June 26, 2018

Hi, I'd like to bring back this discussion (from 2005, by Greg): https://bugs.python.org/issue1229239 Briefly, non-heap types cannot have their attributes changed by Python code. This makes sense for python builtin types, but not for the types defined in extension/modules. As we have been using this patch for the very same reasons and for more than 10 years, I think it might make sense to reconsider the discussion that Greg started. The main question at that time was "why not using a heap … [View More]

4 9

datetime.timedelta literals
by Pål Grønås Drange June 26, 2018

June 26, 2018

Elevator pitch: (2.5h - 14min + 9300ms).total_seconds() # 8169.3 from datetime import datetime as dt start = dt.now() end = dt.now() (end-start) < 5s # True chrono::duration: In C++ 14 the std::chrono::duration was introduced which corresponds somewhat to datetime.timedelta. C++ 14 introduced so-called chrono literals[1], which are literals specified as [number][h|min|s|ms|us|ns], e.g. * 2.5h * 14min * 9300ms These literals should correspond to * datetime.timedelta(0, 9000) # 2.5h =… [View More]

13 29

Re: [Python-ideas] [issue33865] [EASY] Missing code page aliases: "unknown encoding: 874"
by Steven D'Aprano June 25, 2018

June 25, 2018

> It is easy to test it. Encoding/decoding with '874' should give the > same result as with 'cp874'. I know it is too late to remove that feature, but why do we support digit-only IDs for encodings? They can be ambiguous. If Wikipedia is correct, cp874 (also known as ibm874) and Windows-874 (also known as cp1162) are different: https://en.wikipedia.org/wiki/ISO/IEC_8859-11#Code_page_874 https://en.wikipedia.org/wiki/ISO/IEC_8859-11#Code_page_1162 -- Steve

4 8

Secure string disposal (maybe other inmutable seq types too?)
by Ezequiel Brizuela [aka EHB or qlixed] June 24, 2018

June 24, 2018

As all the string in python are immutable, is impossible to overwrite the value or to make a "secure disposal" (overwrite-then-free) of a string using something like: >>> a = "something to hide" >>> a = "x"*len(a) This will lead on the process memory "something to hide" and "x" repeated len(a) times. - Who cares? Why is this relevant? Well if you handle some sensitive information like CC numbers, Passwords, PINs, or other kind of information you wanna minimize the chance … [View More]of leaking any of it. - How this "leak" can happen? If you get a core/memory dump of an app handling sensitive information you will get all the information on that core exposed! - Well, so what we can do about this? I propose to make the required changes on the string objects to add an option to overwrite the underlying buffer. To do so: * Add a wiped as an attribute that is read-only to be set when the string is overwrited. * Add a wipe() method that overwrite the internal string buffer. So this will work like this: >>> pwd =getpass.getpass('Set your password:') # could be other sensitive data. >>> encrypted_pwd = crypt.crypt(pwd) # crypt() just as example. >>> pwd.wiped # Check if pwd was wiped. False >>> pwd.wipe() # Overwrite the underlying buffer >>> pwd.wiped # Check if pwd was wiped. True >>> print(pwd) # Print noise (or empty str?) >>> del pwd # Now is in hands of the GC. The wipe method immediately overwrite the underlying string buffer, setting wiped as True for reference so if the string is further used this can be checked to confirm that the change was made by a wipe and not by another procedure. Also initially the idea is to use unicode NULL datapoint to overwrite the string, but this could be change to let the user parametrize it over wipe() method. An alternative to this is to add a new exception "WipedError" that could be throw where the string is accessed again, but I found this method too disruptive to implement for a normal/standard string workflow usage. Quick & Dirty FAQ: - You do it wrong!, the correct code to do that in a secure way is: >>> pwd = crypt.crypt(getpass.getpass('Set your password')) Don't you know that fool? Well no, the code still generate a temporary string in memory to pass to crypt. But now this string is lying there and can't be accessed for an overwrite with wipe() - Why not create a new type like in C# or Java? I see that this tend to disrupt the usual workflow of string usage. Also the idea here is not to offer secure storage of string in memory because there is already a few mechanism to achieve with the current Python base. I just want to have the hability to overwrite the buffer. - Why don't use one of the standard algorithms to overwrite like DoD5220 or MIL-STD-414? This kind of standard usually are oriented for usage on persistent storage, specially on magnetic media for where the data could be "easily" recoverd. But this could ve an option that could be implemented adding the option to plug a function that do the overwrite work inside the wipe method. - This is far beyond of the almost implementation-agnostic definition of the python lang. How about to you make a module with this functionality and left the lang as is? Well I already do it: https://github.com/qlixed/python-memwiper/ But i hit a lot of problems in the road, I was working on me free time over the last year on this and make it "almost" work, but that is not relevant to the proposal. I think that this kind of security things needs to be tackled from within the language itself specially when the lang have GC. I firmly believe that the security and protections needs to be part of the "with batteries" offer of Python. And I think that this is one little thing that could help a lot to secure our apps. Let me know what do you think! ~ Ezequiel (Ezekiel) Brizuela [ aka Qlixed ] ~ [View Less]

14 30

Replacing Infinite while Loops with an Iterator: async edition
by jab＠math.brown.edu June 24, 2018

June 24, 2018

I first learned the ``for chunk in iter(lambda: sock.recv(N), b'')`` trick from page 138 of Dave Beazley’s fantastic Python Cookbook (“4.16. Replacing Infinite while Loops with an Iterator”), and never looked back. When I started to play with consuming sockets asynchronously, it occurred to me that it would be nice if we could write an async version of this, as in ``async for chunk in aiter(...)``. Is anyone working on adding that to Python, or at least interested too? Thanks, Josh

3 3

Fwd: Trigonometry in degrees
by Robert Vanden Eynde June 23, 2018

June 23, 2018

I agree that a big python library is more close to the standard python lib than matlab. However, helping transition from matlab is a great concern in the python scientific community, because matlab is used is a lot of engineering classes at University. That's a tough call hmmm. I'll look at the implementation of scipy.special.sindg and friends to see if/how they have optimisations for exact values. Le dim. 10 juin 2018 à 16:44, Stephan Houben <stephanh42(a)gmail.com<mailto:stephanh42@… [View More]gmail.com>> a écrit : 2018-06-09 8:18 GMT+02:00 Robert Vanden Eynde <robertvandeneynde(a)hotmail.com<mailto:robertvandeneynde@hotmail.com>>: For the naming convention, scipy using sindg (therefore Nor sind nor sindeg) will make the sind choice less obvious. However if Matlab and Julia chooses sind that's a good path to go, Matlab is pretty popular, as other pointed out, with Universities giving "free" licences and stuff. With that regards, scipy wanting to "be a replacement to Matlab in python and open source" it's interesting they chose sindg and not the Matlab name sind. I would suggest that compatibility with a major Python library such as SciPy is more important than compatibility with other programming languages. I would go even further and argue that scipy.special.sindg and its friends cosdg and tandg can serve as the reference implementation for this proposal. Stephan For the "d" as suffix that would mean "d" as "double" like in opengl. Well, let's remember that in Python there's only One floating type, that's a double, and it's called float... So python programmers will not think "sind means it uses a python float and not a python float32 that C99 sinf would". Python programmers would be like "sin takes float in radians, sind takes float in degrees or int, because int can be converted to float when there's no overflow". Le sam. 9 juin 2018 à 04:09, Wes Turner <wes.turner(a)gmail.com<mailto:wes.turner@gmail.com>> a écrit : # Python, NumPy, SymPy, mpmath, sage trigonometric functions https://en.wikipedia.org/wiki/Trigonometric_functions ## Python math module https://docs.python.org/3/library/math.html#trigonometric-functions - degrees(radians): Float degrees - radians(degrees): Float degrees ## NumPy https://docs.scipy.org/doc/numpy/reference/routines.math.html#trigonometric… - degrees(radians) : List[float] degrees - rad2deg(radians): List[float] degrees - radians(degrees) : List[float] radians - deg2rad(degrees): List[float] radians https://docs.scipy.org/doc/numpy/reference/generated/numpy.sin.html ## SymPy http://docs.sympy.org/latest/modules/functions/elementary.html#sympy-functi… http://docs.sympy.org/latest/modules/functions/elementary.html#trionometric… - sympy.mpmath.degrees(radians): Float degrees - sympy.mpmath.radians(degrees): Float radians - https://stackoverflow.com/questions/31072815/cosd-and-sind-with-sympy - cosd, sind - https://stackoverflow.com/questions/31072815/cosd-and-sind-with-sympy#comme… > Let x, theta, phi, etc. be Symbols representing quantities in radians. Keep a list of these symbols: angles = [x, theta, phi]. Then, at the very end, use y.subs([(angle, angle*pi/180) for angle in angles]) to change the meaning of the symbols to degrees" ## mpmath http://mpmath.org/doc/current/functions/trigonometric.html - sympy.mpmath.degrees(radians): Float degrees - sympy.mpmath.radians(degrees): Float radians ## Sage https://doc.sagemath.org/html/en/reference/functions/sage/functions/trig.ht… On Friday, June 8, 2018, Robert Vanden Eynde <robertvandeneynde(a)hotmail.com<mailto:robertvandeneynde@hotmail.com>> wrote: - Thanks for pointing out a language (Julia) that already had a name convention. Interestingly they don't have a atan2d function. Choosing the same convention as another language is a big plus. - Adding trig function using floats between 0 and 1 is nice, currently one needs to do sin(tau * t) which is not so bad (from math import tau, tau sounds like turn). - Julia has sinpi for sin(pi*x), one could have sintau(x) for sin(tau*x) or sinturn(x). Grads are in the idea of turns but with more problems, as you guys said, grads are used by noone, but turns are more useful. sin(tau * t) For The Win. - Even though people mentionned 1/6 not being exact, so that advantage over radians isn't that obvious ? from math import sin, tau from fractions import Fraction sin(Fraction(1,6) * tau) sindeg(Fraction(1,6) * 360) These already work today by the way. - As you guys pointed out, using radians implies knowing a little bit about floating point arithmetic and its limitations. Integer are more simple and less error prone. Of course it's useful to know about floats but in many case it's not necessary to learn about it right away, young students just want their player in the game move in a straight line when angle = 90. - sin(pi/2) == 1 but cos(pi/2) != 0 and sin(3*pi/2) != 1 so sin(pi/2) is kind of an exception. Le ven. 8 juin 2018 à 09:11, Steven D'Aprano <steve(a)pearwood.info<mailto:steve@pearwood.info>> a écrit : On Fri, Jun 08, 2018 at 03:55:34PM +1000, Chris Angelico wrote: > On Fri, Jun 8, 2018 at 3:45 PM, Steven D'Aprano <steve(a)pearwood.info<mailto:steve@pearwood.info>> wrote: > > Although personally I prefer the look of d as a prefix: > > > > dsin, dcos, dtan > > > > That's more obviously pronounced "d(egrees) sin" etc rather than "sined" > > "tanned" etc. > > Having it as a suffix does have one advantage. The math module would > need a hyperbolic sine function which accepts an argument in; and > then, like Charles Napier [1], Python would finally be able to say "I > have sindh". Ha ha, nice pun, but no, the hyperbolic trig functions never take arguments in degrees. Or radians for that matter. They are "hyperbolic angles", which some electrical engineering text books refer to as "hyperbolic radians", but all the maths text books I've seen don't call them anything other than a real number. (Or sometimes a complex number.) But for what it's worth, there is a correspondence of a sort between the hyperbolic angle and circular angles. The circular angle going between 0 to 45° corresponds to the hyperbolic angle going from 0 to infinity. https://en.wikipedia.org/wiki/Hyperbolic_angle https://en.wikipedia.org/wiki/Hyperbolic_function > [1] Apocryphally, alas. Don't ruin a good story with facts ;-) -- Steve _______________________________________________ Python-ideas mailing list Python-ideas(a)python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas(a)python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas(a)python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas(a)python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ [View Less]

17 47

Re: [Python-ideas] staticmethod and classmethod should be callable
by Jeroen Demeyer June 22, 2018

June 22, 2018

On 2018-06-21 10:33, Serhiy Storchaka wrote: > Status quo wins. Well, I'm already planning to make changes to staticmethod/classmethod (not right now, but it's on my post-PEP-580 roadmap). So the "status quo" argument doesn't apply. My question is really: assuming that we redesign staticmethod/classmethod anyway, should we make them callable?

3 2

String and bytes bitwise operations
by Ken Hilton June 22, 2018

June 22, 2018

Hi all, We all know the bitwise operators: & (and), | (or), ^ (xor), and ~ (not). We know how they work with numbers: 420 ^ 502 110100100 111110110 == XOR == 001010010 = 82 But it might be useful in some cases to (let's say) xor a string (or bytestring): HELLO ^ world 01001000 01000101 01001100 01001100 01001111 01110111 01101111 01110010 01101100 01100100 =================== XOR ==================== 00111111 00101010 00111110 00100000 00101011 = ?*> + Currently, that's done with … [View More]

14 22

staticmethod and classmethod should be callable
by Jeroen Demeyer June 22, 2018

June 22, 2018

While working on PEP 579 and friends, I noticed one oddity with classmethods: for Python classes, the object stored in the class __dict__ is of type "classmethod". For extension types, the type is "classmethod_descriptor". In turns out that the latter is callable itself, unlike staticmethod or classmethod instances: >>> fromhex = float.__dict__["fromhex"] >>> type(fromhex) <class 'classmethod_descriptor'> >>> fromhex(float, "0xff") 255.0 >>> @… [View More]

5 10

Re: [Python-ideas] staticmethod and classmethod should be callable
by Jeroen Demeyer June 21, 2018

June 21, 2018

On 2018-06-20 19:33, Serhiy Storchaka wrote: > 20.06.18 12:56, Jeroen Demeyer пише: >> Are there any reasons to *not* make staticmethod and classmethod callable? > > There were no reasons to make staticmethod and classmethod callable. You have to compare the advantages of making them callable vs. the advantages of *not* making them callable. I think that consistency *is* good to have, so I consider that one reason to make them callable. Are there any reasons for *not* making them callable?

3 2