Mailman 3 October 2011 - Python-ideas

Proporsal: Show an alert in traceback when the source file is newer than compiled code (issue8087)
by Diego Mascialino Oct. 10, 2011

Oct. 10, 2011

Hello, I opened this issue a long time ago, and Éric Araujo said that it should be discussed on this list. This is my feature request message: Example: ---------------- mod.py ---------------- def f(): a,b,c = 1,2 print b ---------------------------------------- If i do: >>> import mod >>> mod.f() I get: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "mod.py", line 2, in f a,b,c = 1,2 ValueError: need more than … [View More]

4 4

Support multiplication for sets
by Jakob Bowyer Oct. 10, 2011

Oct. 10, 2011

Looking at this from a Math background, it seems that it would be nice for the set type to support multiplication. This would allow for the multiplication of sets to produce Cartesian products giving every single permutation. This would make set usage more intuitive for example; (assuming python3) a = set(["amy", "martin"]) b = set(["smith", "jones", "john"]) c = a * b print(c) set([('john', 'jones'), ('john', 'martin'), ('jones', 'john'), ('martin', 'amy'), ....]) This … [View More]

21 39

Testing Key-Value Membership In Dictionaries
by Karthick Sankarachary Oct. 10, 2011

Oct. 10, 2011

Hello Python Ideas, Currently, to check whether a single key is in a dictionary, we use the "in" keyword. However, there is no built-in support for checking if a key-value pair belongs in a dictionary. Currently, we presuppose that the object being checked has the same type as that of the key. What if we allowed the "in" operator to accept a tuple that denotes a (mapped) key-value pair? Let us consider how that might work using the canonical example given in the tutorial: >>> tel = … [View More]

6 5

Re: [Python-ideas] [Python-Dev] PEP 3101 (Advanced string formatting) base 36 integer presentation type
by Victor Stinner Oct. 9, 2011

Oct. 9, 2011

Le 08/10/2011 17:14, Victor Stinner a écrit : > Le 08/10/2011 15:03, Antoine Pitrou a écrit : >> On Fri, 07 Oct 2011 21:14:44 -0600 >> Jeffrey<jss.bulk(a)gmail.com> wrote: >>> I would like to suggest adding an integer presentation type for base 36 >>> to PEP 3101. I can't imagine that it would be a whole lot more >>> difficult than the existing types. Python's built-in long integers >>> provide a nice way to prototype and demonstrate … [View More]

1 0

Default return values to int and float
by David Townshend Oct. 9, 2011

Oct. 9, 2011

My idea is fairly simple: add a "default" argument to int and float, allowing a return value if the conversion fails. E.g: >>> float('cannot convert this', default=0.0) 0.0 I think there are many use cases for this, every time float() or int() are called with data that cannot be guaranteed to be numeric, it has to be checked and some sort of default behaviour applied. The above example is just much cleaner than: try: return float(s) except ValueError: return 0.0 Any takers? David

23 59

back-references in comprehensions
by yoch melka Oct. 8, 2011

Oct. 8, 2011

Hi, I would like to use backreferences in list comprehensions (or other comprehensions), such as : [[elt for elt in lst if elt] for lst in matrix if \{1}] # \{1} is back-reference to filter result of the # first comprehension ([elt for elt in lst if elt]) It would be possible to do this ? Thanks

2 1

PEP 3101 (Advanced string formatting) base 36 integer presentation type
by Jeffrey Oct. 8, 2011

Oct. 8, 2011

I would like to suggest adding an integer presentation type for base 36 to PEP 3101. I can't imagine that it would be a whole lot more difficult than the existing types. Python's built-in long integers provide a nice way to prototype and demonstrate cryptographic operations, especially with asymmetric cryptography. (Alice and Bob stuff.) Built-in functions provide modular reduction, modular exponentiation, and lots of nice number theory stuff that supports a variety of protocols and … [View More]algorithms. A frequent need is to represent a message by a number. Base 36 provides a way to represent all 26 letters in a semi-standard way, and simple string transformations can efficiently make zeros into spaces or vice versa. long() can already take a radix argument of 36 to parse base 36 numbers. If a base 36 presentation type (say, 'z' or something) was available, it would be possible to base 36 numbers as a simple way to interpret a message as a number in number theoretic/asymmetric cryptographic applications. The standard answer (see, for example, the Wikipedia Base 36 article) is to code up a quick routine to loop around and generate each digit, but: - The kinds of numbers used in cryptographic applications are big, as in thousands of digits. Providing some sort of direct support would nicely facilitate computational efficiency as it would avoid going around an interpreted loop thousands of times for each conversion. - All the the examples I've seen on in a quick Google search use the horrible anti-idiom of building up a string by repeated concatenation. Obviously, doing it efficiently is not trivial. It would be nice to get it right and be done with it. - Yes, one could write his own routine to do it, but this would serve as an unnecessary distraction where the purpose of the code is to illustrate a cryptographic algorithm or protocol - Yes, one could write his own module, define his own type, and override everything, but it's a fair amount of work to cover everything off (longs are a part of the language's core syntax) and even then, you still have the clutter of manually invoking constructors to make your new type instead of the built-int type. It's also kind of a trivial thing to justify promulgating a standard module for, and without a standard module, it's one more preliminary that has to be done before you can get to the main algorithm. - "Batteries included" is kind of a nice philosophy. Is it practical to add a base36 integer presentation type (say, 'z' or 'Z' similar to hexadecimal's 'x' or 'X') to the existing integer presentation types list in PEP 3101 (or do I need to raise a brand new PEP for this near-triviality)? It would be a very parallel thing to the hexadecimal one which is doing almost all the same things. I can't imagine it breaking anything because it defines something new that previously wasn't defined as anything useful at all. Jeffrey <jss.bulk@@gmail.com <mailto:jeffrey.streifling@gmail.com>> [View Less]

4 4

A Protocol for Making an Object Immutable
by Eric Snow Oct. 7, 2011

Oct. 7, 2011

As I was working on some code today, I found myself in a situation where I wanted to "freeze" an object. This topic has come up a few times since I've been following these lists, so I figured it wasn't too crazy an idea. Really quickly I hacked out a simple bit of code that I am using for what I needed, and later I posted it as a recipe on the ActiveState cookbook[1]. The gist of it is a __freeze__/__unfreeze__ protocol, supported respectively by two ABCs and two functions (freeze and … [View More]

2 3

PEP 335: Another use case
by Gerald Britton Oct. 5, 2011

Oct. 5, 2011

>I've received the following comments concerning another>potential use case for PEP 335.>>-------- Original Message -------->Subject: PEP 335 and NumPy NA>Date: Tue, 4 Oct 2011 15:42:50 -0700>From: Mark Wiebe <mwwiebe at gmail.com>>To: Gregory Ewing <greg at cosc.canterbury.ac.nz>>>Hi Greg,>>I took a glance at the python-ideas list, and saw that you're proposing>an update to PEP 335. I recently did a short internship at Enthought>where … [View More]

3 2

PEP 335: Another use case
by Greg Ewing Oct. 5, 2011

Oct. 5, 2011

I've received the following comments concerning another potential use case for PEP 335. -------- Original Message -------- Subject: PEP 335 and NumPy NA Date: Tue, 4 Oct 2011 15:42:50 -0700 From: Mark Wiebe <mwwiebe(a)gmail.com> To: Gregory Ewing <greg(a)cosc.canterbury.ac.nz> Hi Greg, I took a glance at the python-ideas list, and saw that you're proposing an update to PEP 335. I recently did a short internship at Enthought where they asked me to look into the "missing data" … [View More]

1 0