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 could be really easily achieved by giving a __mul__ method for sets.
Currently trying to multiply sets gives a TypeError. Anyone got any views on
this? Or am I barking up the wrong tree and saying something stupid.

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 = {'jack': 4098, 'sape': 4139}
>>> ('jack', 4098) in tel
True
>>> ('jack', 4000) in tel
False
>>> 'jack' in tel
True
As you can see, the "in" operator would interpret the object as either a key
or a key-value pair depending on the actual types of the object, key and
value. In the key itself happens to be a tuple, then the key-value
membership test would involve a nested tuple, whose first item is a tuple
denoting the key.
Best Regards,
Karthick Sankarachary

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 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 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.
>>
>> Why base 36 rather than, say, base 64 or even base 80?
>
> Base 85 is the most efficient base to format IPv6 addresses!
>
> http://tools.ietf.org/html/rfc1924
>
> And Python doesn't provide builtin function for this base!
>
> Victor
Oops, I answered to the wrong mailing list.
Victor

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

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

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

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
unfreeze).
I've come to learn that it's a good idea to do some digging in the
list archives before posting an idea, and I'm glad I did. Apparently
there is a nearly identical PEP (351) to what I was thinking of [2].
And just my luck, it was shot down pretty hard.
So I have a couple questions. First, from what I've read so far, the
idea of frozen/immutable seems to be tied pretty closely to being
hashable. However, this wasn't applicable to the use case that I had.
Instead, I just wanted to make sure certain attributes of a class of
mine were effectively read-only. So, is being hashable necessarily
tied to being immutable?
Second, I realize that PEP 351 failed to pass muster, so I'm not
holding my breath here. Shoot, I'm not even really proposing we add
this protocol. Mostly, I found a simple model that worked for me and
seemed more broadly applicable; and I wanted to see if it would be
suitable for further research. Now, in light of PEP 351, I'm less
convinced that it's so simple. Still, I've seen some ideas come back
from the proverbial grave and wanted to see if this one is not quite
dead, sir (or if I should avenge it <wink>).
-eric
[1] http://code.activestate.com/recipes/577895/
[2] http://www.python.org/dev/peps/pep-0351/

>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 they asked me to look into the "missing data" problem for NumPy,>and I believe the work from that provides further motivation for the>PEP. Basically, the approach to allow good handling of missing data is>emulating the R programming language by introducing a new value called>NA, similar to the built-in None. For an NA with a boolean type, you get>a three-valued logic, as described>in http://en.wikipedia.org/wiki/Three-valued_logic#Kleene_logic. In the>NA I added to NumPy, this truth table cannot be satisfied because of the>issue PEP 335 addresses:
Interesting! Kinda like SQL, I think, which has True, False and Null
(similar to NA in R).
Weird to think SQL "solved" this problem 40 years ago!
--
Gerald Britton

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" problem for NumPy,
and I believe the work from that provides further motivation for the
PEP. Basically, the approach to allow good handling of missing data is
emulating the R programming language by introducing a new value called
NA, similar to the built-in None. For an NA with a boolean type, you get
a three-valued logic, as described
in http://en.wikipedia.org/wiki/Three-valued_logic#Kleene_logic. In the
NA I added to NumPy, this truth table cannot be satisfied because of the
issue PEP 335 addresses:
>>> import numpy as np
>>> if True or np.NA: print "yes"
...
yes
>>> if np.NA or True: print "yes"
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: numpy.NA represents an unknown missing value, so its
truth value cannot be determined
This can be worked around by using the bitwise operators, as mentioned
in the PEP for the array case:
>>> if True | np.NA: print "yes"
...
yes
>>> if np.NA | True: print "yes"
...
yes
Here are the documents with more information:
https://github.com/numpy/numpy/blob/master/doc/source/reference/arrays.mask…https://github.com/numpy/numpy/blob/master/doc/neps/missing-data.rst
Cheers,
Mark

Hello,
I honestly didn't know we exposed such semantics, and I'm wondering if
the functionality is worth the astonishement:
>>> "abc" in io.StringIO("abc\ndef\n")
False
>>> "abc\n" in io.StringIO("abc\ndef\n")
True
Basically, io.StringIO provides iteration (it yields lines of text) and
containment is apparently inferred from that.
Regards
Antoine.