Jeff Bone:
> Yet --- true, but only if one accepts a particular and rather
> simple-minded and overly-literal interpretation of the ***GOALS*** of
> PEP 318,
That simple-minded and overly-literal interpretation may well
be correct.
PEP 318 does not intend to change the semantics or capabilities
of the language in any way whatsoever.
The only reason to add 318 is so that a particular idiom will be
easier to understand (and perhaps more efficient).
The other goals are really damage control. If the idiom becomes
easy to use, it will get used more often. Sometimes, that will
be good, as it will replace something more byzantine.
It is true that we don't want to encourage certain types of coding,
but they're already possible, and the consensus was not to ban
them now. Discourage in a style guide, maybe, but not ban.
The arguments about syntax are because we don't want the new and
improved idiom to end up uglifying the rest of the language.
Ideally, any change will remove more clutter than it creates, so
adding new meaning to certain magic characters ... is risky.
If we put restrictions on decorators, people may just keep using
the current idiom -- and then we would have added the clutter for
no gain at all.
-jJ
Patch #935454 is a module implementing SHA-256, a variant of the
160-bit SHA algorithm supported in Python's existing sha module.
Though it's more recent than the original SHA-160, SHA-256 is just as
"standard"; both algorithms are specified by a NIST document.
The submitter comments:
The difference is that it produces a 256 bit hash value,
instead of a 160 bit hash value. SHA-256 thus has 128 bits of
resistance against birthday attacks, which makes it secure in
certain protocols where SHA-1 is questionable (e.g. digital
signatures; or RNGs or Key-Derivation Functions where you want
to produce keys for 256-bit ciphers).
A quick skim over the code doesn't turn up any issues, and the patch
includes a test suite but no documentation. I don't want to do a
detailed code review or require docs from the submitter if the module
isn't likely to be included, so do we want to add this module?
There are a bunch of other variants with different bit sizes such as
512, 384, and 224 bits. The only one likely to matter is SHA-512, so
adding sha256 might mean that down the road we need to add a sha512
module, too, but that seems unlikely.
--amk
Feedback is requested for two prospective itertools:
def count_elements(iterable):
b = {}
for elem in iterable:
b[elem] = b.get(elem, 0) + 1
return ((cnt, elem) for elem, cnt in b.iteritems())
def pairswap(iterable):
return ((b,a) for a,b in iterable)
The first is designed to provide item counts for min(), max(), sorted(),
nlargest(), and nsmallest(). It accepts any iterable including
generator expressions:
>>> from heapq import nlargest
>>> words = (word for line in open('mystory.txt') for word in
line.split())
>>> nlargest(count_elements(words), 3)
[(200, 'super'), (129, 'hero'), (103, 'villain')]
The second handles reordering of fields in tuples of length two. It
works well with dict(), enumerate(), dict.iteritems(),
itertools.starmap() and anything else that accepts or returns a series
of pairs:
>>> list(pairswap(_))
[('super', 200), ('hero', 129), ('villain', 103)]
>>> inversemap = dict(pairswap(forwardmap.iteritems()))
>>> maptoposition = dict(pairswap(enumerate(mysequence)))
Raymond
P.S. If you have naming suggestions other than pairswap() and
count_elements(), I'm all ears.
Tim,
I'm not sure this needs to be on the list. My major point, I guess,
is that the byte vectors we tend to call strings in Python have no
string-ness, as understood in the 21st century. There is no character
set associated with them, which means that there is effectively no way
to look at the "next character" in a string (you don't know how long a
character is), no way to count the number of characters, etc. The
documentation, particularly the language manual, is extremely
confusing on this point, in classifying "string" and "Unicode" objects
as the same sort of thing. And then not documenting them clearly.
"struct.pack", for instance, doesn't really return a string -- it
returns a byte vector.
Unicode is really the only kind of *string* type that's supported,
which is problematic, as it's not integrated with the file streams
support. For instance, how do I write a function that opens a file
containing text in some multi-byte format (which, we'll assume, I know
the name of -- perhaps from a content-type field), and reads the first
three characters of the text? Can't. That's because the "file"
constructor doesn't take an encoding, and "read" and "readline" don't
return Unicode objects. I could try, by reading some bytes, then
using unicode to turn it into a string, then seeing how many
characters I read, but that's pretty imprecise. I go round and round
the "codecs" module thinking that someone must have thought of this --
or maybe there's an optional argument to file() that make it return
real (Unicode) strings -- but no luck.
I find it hard to believe that I've dreamed up something that neither
you nor (especially) Martin have thought of till now. But consider
this idea.
Any file that is not explicitly opened as binary (with the 'b' flag
(and, by the way, why isn't the 'b' flag the default for file opening?
It would save a lot of grief dealing with Windows.)) should be
considered a text file, and it should have an associated "encoding"
attribute (as file objects already do), which would also be a keyword
parameter to the constructor. The default would be
sys.getdefaultencoding(). The "size" parameter to the methods "read"
and "readline" should refer to characters, not bytes, for text files.
The return values from "next", "read" and "readline" would be Unicode
objects for text files. Similarly, the methods "write" and
"writelines" should, for text files, take Unicode objects and raise an
exception if fed a "byte vector".
I'd go further. I'd introduce the notation
v = b"abc"
which means that "v" has assigned to it an 8-bit "string" byte vector.
Then, after a release or two, I'd make plain old
"foo"
mean what
u"foo"
means today, so that string literals are by default Unicode (module
PEP 263).
Bill
In the translation project, we now have two (partial) translation
of Python doc strings: for German, and for Turkish. I'd like to ship
the compiled message catalogs with Python 2.4, so that pydoc will
automatically display translated doc strings if they are available.
I would suggest to place the catalogs into Lib/messages/*.mo
(alternatively, if a "non-doc" message catalog for Python is foreseen,
Lib/doc/*.mo would also be reasonable).
What do you think?
Regards,
Martin
We often want to associate data with threads. Python
manages a dictionary per-tread for this purpose, but there's
currently no way to get to this dictionary from Python.
I propose, for 2.4, to add a get_dict method to the thread
module that will return this dictionary. This will be
implemented via a call to PyThreadState_GetDict.
Any objections?
Jim
--
Jim Fulton mailto:jim@zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.comhttp://www.zope.org
I'm planning to commit a patch (http://www.python.org/sf/983019) that makes
weak references subclassable. This includes the following changes:
- weakref.ref and weakref.ReferenceType will become aliases for each other
- weakref.ref will be a modern, new-style class with proper __new__ and
__init__ methods
- weakref.WeakValueDictionary will have a lighter memory footprint, using a
new weakref.ref subclass to associate the key with the value, allowing us to
have only a single object of overhead for each dictionary entry (currently,
there are 3 objects of overhead per entry: a weakref to the value, a weakref
to the dictionary, and a function object used as a weakref callback; the
weakref to the dictionary could be avoided without this change)
- a new macro, PyWeakref_CheckRefExact(), will be added
- PyWeakref_CheckRef() will check for subclasses of weakref.ref
- the cyclic garbage detector will be affected by the change to
PyWeakref_CheckRef(); it will potentially call issubtype() for objects in the
unreachable list that do not have finalizers (in the move_troublemakers()
function). This should only happen for weakref objects which are not of one
of the "standard" three types (ref, proxy, and callable proxy). For debug
builds, it will also affect assertions in the clear_weakerfs() and
release_weakrefs() functions.
The change to the cyclic garbage detector probably carries the most risk, and
that only because the potential for a performance penalty. Running the Zope
3 test suite did not show any clear change in performance, and a key
subsystem in Zope (zope.interface) uses weakrefs extensively.
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
Is this also intended for use as a base class? In particular, it seems
like if I have a class Foo, then I can make a thread-local version with
the following (as long as Foo doesn't rely on overriding
__getattribute__/__setattr__).
class LocalFoo(local, Foo): pass
Is that right? (I can see how it works in the Python implementation,
but don't know enough about extensions to see if that translates
directly to the c implementation.)
Actually, does local.__init__() need a call to super(self,
local).__init__() to make this work?
-Edward
I happened to look at PEP 276 and was struck by the thought that PEP 276 is
really an implementation of the well-known set-theoretic construction of the
natural numbers that defines each natural number as the set of all smaller
ones. In other words, it defines 0 as the empty set, 1 as the set whose
only element is 0, 2 as the set whose elements are 0 and 1, and so on.
Indeed, under PEP 276, sets.Set(42) would be a set with 42 elements that
would be exactly the canonical representation of 42.
Jeff Bone writes:
> IMHO, making decorators functions is a bad idea. Decorators are
> metadata about the function to which they refer.
Bob Ippolito responds:
> Uh, the WHOLE POINT we want this is to have side-effects. If it
> doesn't make the function act in a different way, it might as well live > in the doc string or something.
>
> The most wanted use cases are all function transformations, not the
> setting attributes on function objects.
And back to Jeff:
> Declarative vs. imperative. Design-time *definitional* modification of > behavior vs. runtime. I don't really think you want side-effects in
> the literal sense. E.g. "classmethod" isn't a side-effect, it's a
> definitional thing. If you really want side-effecting operations on
> functions, you've already got that given higher-order / first-class
> functions.
Just one more opinion here, but I'm with Bob on this one. Sure, many
of the uses I envision are "declarative" in the sense that they just
associate metadata with the function. But many other uses I envision
would alter the function's behavior. Yes, of COURSE it can all be
achieved by applying higher-order operations to Python's first-class
functions -- in my mind, that's what decorators ARE... a cleaner
syntax allowing easier use of higher order functions.
-- Michael Chermside
This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.
