Re: [Python-Dev] len(chr(i)) = 2?
Glyph Lefkowitz writes: But I don't think that anyone is filling up main memory with gigantic piles of character indexes and need to squeeze out that extra couple of bytes of memory on such a tiny object. How do you think editors and browsers represent the regions that they highlight, then? How do you think that structure-oriented editors represent the structures that they work with, then? In a detailed analysis of a C or Java file, it's easy to end up with almost 1:2 positions to characters ratio. Note that *buffer* characters are typically smaller than a platform word, so saving one word in the representation of a position mean a 100% or more increase in the character count of the buffer. Even in the case of UCS-4 on a 32-bit platform, that's a 50% increase in the maximum usable size of a buffer before a parser starts raising OOM errors. There are two plausible ways to represent these structures that I can think of offhand. The first is to do it the way Emacs does, by reading the text into a buffer and using position offsets to map to display or structure attributes. The second is to use a hierarchical document model, and render the display by traversing the document hierarchy. It's not obvious to me that forcing use of the second representation is a good idea for performance in an editor, and I would think that they have similar memory requirements. Plus, this would allow such a user to stop copying the character data itself just to decode it, and on mostly-ascii UTF-8 text (a common use-case) this is a 2x savings right off the bat. Which only matters if you're a server in the business of shoveling octets really fast but are CPU bound (seems unlikely to me, but I'm no expert; WDYT?), and even then is only that big a savings if you can push off the issue of validating the purported UTF-8 text on others. If you're not validating, you may as well acknowledge that you're processing binary data, not text.[1] But we're talking about text. And of course, if you copy mostly-Han UTF-8 text (a common use-case) to UCS-2, this is a 1.5x memory savings right off the bat, and a 3x time savings when iterating in most architectures (one increment operation per character instead of three). As I've already said, I don't think this is an argument in favor of either representation. Sometimes one wins, sometimes the other. I don't think supplying both is a great idea, although I've proposed it myself for XEmacs (but made as opaque as possible). In Python it's true that markers can use the same data structure as integers and simply provide different methods, and it's arguable that Python's design is better. But if you use bytes internally, then you have problems. No, you just have design questions. Call them what you like, they're as yet unanswered. In any given editing scenario, I'd concede that it's a SMOD. But if you're designing a language for text processing, it's a restriction that I believe to be a hindrance to applications. Many applications may prefer to use a straightforward array implementation of text and focus their design efforts on the real problems of their use cases. Do you expose that byte value to the user? If so, what do you do if the user specifies a byte value that points into a multibyte character? Go to the beginning of the multibyte character. Report that position; if the user then asks the requested marker object for its position, it will report that byte offset, not the originally-requested one. (Obviously, do the same thing for surrogate pair code points.) I will guarantee that some use cases will prefer that you go to the beginning of the *next* character. For an obvious example, your algorithm will infloop if you iterate pos += 1. (And the opposite problem appears for beginning of next character combined with pos -= 1.) Of course this trivial example is easily addressed by saying the user should be using the character iterator API here, but I expect the issue can arise where that is not an easy answer. Either the API becomes complex, or the user/developers will have to do complex bookkeeping that should be done by the text implementation. Nor is it obvious that surrogate pairs will be present in a UCS-2 representation. Specifically, they can be encoded to single private space characters in almost all applications, at a very small cost in performance. What if the user wants to specify position by number of characters? Part of the point that we are trying to make here is that nobody really cares about that use-case. In order to know anything useful about a position in a text, you have to have traversed to that location in the text. Binary search of an ordered text is useful. Granted, this particular example can be addressed usefully in terms of byte positions (viz. your example of less), but your basic premise is falsified. You can remember interesting things like the offsets of starts of
Re: [Python-Dev] constant/enum type in stdlib
On Thu, Nov 25, 2010 at 3:41 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
Can you explain what you see as the difference?
I'm not particularly interested in type validation but I like the fact that
typical enum APIs allow you to group constants: the generated constant class
acts as a namespace for all the defined constants.
The problem with blessing one particular enum API is that people
have so many different ideas as to what an enum API should look like.
However, the one thing they all have in common is the ability to take
a value and give it a name, then present *both* of those in debugging
information.
Are you just suggesting something along the lines of:
class NamedConstant(int):
def __new__(cls, name, val):
return int.__new__(cls, val)
def __init__(self, name, val):
self._name = name
def __repr__(self):
return 'NamedConstant %s' % self._name
FOO = NamedConstant('FOO', 3)
In general the less features the better, but I'd like a few more features
than that. :-)
Not quite. I'm suggesting a factory function that works for any value,
and derives the parent class from the type of the supplied value.
However, what you wrote is still the essence of the idea - we would be
primarily providing a building block that makes it easier for people
to *create* enum APIs if they want to, but for simple use cases (where
all they really wanted was the enhanced debugging information) they
wouldn't need to bother. In the standard library, wherever we do
enum-like things we would switch to using named values where it
makes sense to do so.
Doing so may actually make sense for more than just constants - it may
make sense for significant mutable globals as well.
==
# Implementation (more than just a sketch, since it handles some
interesting corner cases)
import functools
@functools.lru_cache()
def _make_named_value_type(base_type):
class _NamedValueType(base_type):
def __new__(cls, name, value):
return base_type.__new__(cls, value)
def __init__(self, name, value):
self.__name = name
super().__init__(value)
@property
def _name(self):
return self.__name
def _raw(self):
return base_type(self)
def __repr__(self):
return {}={}.format(self._name, super().__repr__())
if base_type.__str__ is object.__str__:
__str__ = base_type.__repr__
_NamedValueType.__name__ = Named{}.format(base_type.__name__)
return _NamedValueType
def named_value(name, value):
return _make_named_value_type(type(value))(name, value)
def set_named_values(namespace, **kwds):
for k, v in kwds.items():
namespace[k] = named_value(k, v)
x = named_value(FOO, 1)
y = named_value(BAR, Hello World!)
z = named_value(BAZ, dict(a=1, b=2, c=3))
print(x, y, z, sep=\n)
print(\n.join(map(repr, (x, y, z
print(\n.join(map(str, map(type, (x, y, z)
set_named_values(globals(), foo=x._raw(), bar=y._raw(), baz=z._raw())
print(\n.join(map(repr, (foo, bar, baz
print(type(x) is type(foo), type(y) is type(bar), type(z) is type(baz))
==
# Session output for the last 6 lines
print(x, y, z, sep=\n)
1
Hello World!
{'a': 1, 'c': 3, 'b': 2}
print(\n.join(map(repr, (x, y, z
FOO=1
BAR='Hello World!'
BAZ={'a': 1, 'c': 3, 'b': 2}
print(\n.join(map(str, map(type, (x, y, z)
class '__main__.Namedint'
class '__main__.Namedstr'
class '__main__.Nameddict'
set_named_values(globals(), foo=x._raw(), bar=y._raw(), baz=z._raw())
print(\n.join(map(repr, (foo, bar, baz
foo=1
bar='Hello World!'
baz={'a': 1, 'c': 3, 'b': 2}
print(type(x) is type(foo), type(y) is type(bar), type(z) is type(baz))
True True True
For normal use, such objects would look like ordinary instances of
their class. They would only behave differently when their
representation is printed (prepending their name), or when their type
is interrogated (being an instance of the named subclass rather than
the ordinary type).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Preview] Comments and change proposals on documentation
On Thu, Nov 25, 2010 at 6:24 AM, Georg Brandl g.bra...@gmx.net wrote: Hi, at http://dpo.gbrandl.de/contents, you can look at a version of the 3.2 docs that has the upcoming commenting feature. JavaScript is mandatory. Very nice! I'm not sure what to do about the discoverability of the comment bubbles as the end of each paragraph. I initially thought commenting wasn't available on What's New or the Using Python docs until seeing where the blue comment bubbles appeared in the math module docs. A discreet notice at the bottom of the sidebar and/or an explanation at the Report a Bug page may cover it I guess. Please test on a smaller page, such as http://dpo.gbrandl.de/library/math, there is currently a speed issue with larger pages. (Helpful tips from JS experts are welcome.) I gave the JS a fair few comments on the first paragraph to digest. I also put my detailed UI comments there as well (I needed something to write about while testing, so I figured I may as well make it useful to you!) Other things I have to do before this can go live: * reuse existing logins from either wiki or tracker? Tracker sounds like the best bet to me. Any feedback is appreciated (I'd suggest mailing it to doc-SIG only, to avoid cluttering up python-dev). My comments may on the math module may give you a chance to see how easy it is to get text out of comments into a form suitable for sending to a mailing list or posting to a tracker issue for further discussion :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86745 - in python/branches/py3k: Doc/library/difflib.rst Lib/difflib.py Lib/test/test_difflib.py Misc/NEWS
On Thu, Nov 25, 2010 at 4:12 PM, terry.reedy python-check...@python.org wrote: The :class:`SequenceMatcher` class has this constructor: -.. class:: SequenceMatcher(isjunk=None, a='', b='') +.. class:: SequenceMatcher(isjunk=None, a='', b='', autojunk=True) Optional argument *isjunk* must be ``None`` (the default) or a one-argument function that takes a sequence element and returns true if and only if the @@ -340,6 +349,9 @@ The optional arguments *a* and *b* are sequences to be compared; both default to empty strings. The elements of both sequences must be :term:`hashable`. + The optional argument *autojunk* can be used to disable the automatic junk + heuristic. + Catching up on checkins traffic, so a later checkin may already fix this, but there should be a versionchanged tag in the docs to note when the autojunk parameter was added. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86750 - python/branches/py3k/Demo/curses/life.py
On Fri, Nov 26, 2010 at 12:15 PM, Senthil Kumaran orsent...@gmail.com wrote: Re: “colour”: the rest of the file use US English, as do the function names (see for example curses.has_color). It’s good to use one dialect consistently in one file. Good catch. Did not realize it because, we write it as colour too. Changing it. I just resign myself to having to spell words like colour and serialise wrong when I'm working on Python. Compared to the adjustments the non-native English speakers have to make, I figure I'm getting off lightly ;) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86750 - python/branches/py3k/Demo/curses/life.py
On 27/11/2010 12:22, Nick Coghlan wrote: On Fri, Nov 26, 2010 at 12:15 PM, Senthil Kumaranorsent...@gmail.com wrote: Re: “colour”: the rest of the file use US English, as do the function names (see for example curses.has_color). It’s good to use one dialect consistently in one file. Good catch. Did not realize it because, we write it as colour too. Changing it. I just resign myself to having to spell words like colour and serialise wrong when I'm working on Python. Compared to the adjustments the non-native English speakers have to make, I figure I'm getting off lightly ;) I *thought* that the Python policy was that English speakers wrote documentation in English and American speakers wrote documentation in American and that we *don't* insist on US spellings in the Python documentation? Michael Cheers, Nick. -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86745 - in python/branches/py3k: Doc/library/difflib.rst Lib/difflib.py Lib/test/test_difflib.py Misc/NEWS
On Sat, Nov 27, 2010 at 14:17, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Nov 25, 2010 at 4:12 PM, terry.reedy python-check...@python.org wrote: The :class:`SequenceMatcher` class has this constructor: -.. class:: SequenceMatcher(isjunk=None, a='', b='') +.. class:: SequenceMatcher(isjunk=None, a='', b='', autojunk=True) Optional argument *isjunk* must be ``None`` (the default) or a one-argument function that takes a sequence element and returns true if and only if the @@ -340,6 +349,9 @@ The optional arguments *a* and *b* are sequences to be compared; both default to empty strings. The elements of both sequences must be :term:`hashable`. + The optional argument *autojunk* can be used to disable the automatic junk + heuristic. + Catching up on checkins traffic, so a later checkin may already fix this, but there should be a versionchanged tag in the docs to note when the autojunk parameter was added. Hi Nick, Since autojunk was added in 2.7.1 (the docs of which do indicate this is the versionchanged tag), I think Terry may have left the tag in 3.2 out on purpose. That said, personally I don't know what the policy is regarding features added just in 3.2 and 2.7 (and didn't exist in 3.1) in this respect. Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86745 - in python/branches/py3k: Doc/library/difflib.rst Lib/difflib.py Lib/test/test_difflib.py Misc/NEWS
On 27/11/2010 13:00, Eli Bendersky wrote: On Sat, Nov 27, 2010 at 14:17, Nick Coghlan ncogh...@gmail.com mailto:ncogh...@gmail.com wrote: On Thu, Nov 25, 2010 at 4:12 PM, terry.reedy python-check...@python.org mailto:python-check...@python.org wrote: The :class:`SequenceMatcher` class has this constructor: -.. class:: SequenceMatcher(isjunk=None, a='', b='') +.. class:: SequenceMatcher(isjunk=None, a='', b='', autojunk=True) Optional argument *isjunk* must be ``None`` (the default) or a one-argument function that takes a sequence element and returns true if and only if the @@ -340,6 +349,9 @@ The optional arguments *a* and *b* are sequences to be compared; both default to empty strings. The elements of both sequences must be :term:`hashable`. + The optional argument *autojunk* can be used to disable the automatic junk + heuristic. + Catching up on checkins traffic, so a later checkin may already fix this, but there should be a versionchanged tag in the docs to note when the autojunk parameter was added. Hi Nick, Since autojunk was added in 2.7.1 (the docs of which do indicate this is the versionchanged tag), I think Terry may have left the tag in 3.2 out on purpose. That said, personally I don't know what the policy is regarding features added just in 3.2 and 2.7 (and didn't exist in 3.1) in this respect. Features new in Python 3.2 that didn't exist in 3.1 should have a versionadded:: 3.2 tag. Michael Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (BOGUS AGREEMENTS) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] constant/enum type in stdlib
On 27/11/2010 10:51, Nick Coghlan wrote:
On Thu, Nov 25, 2010 at 3:41 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
Can you explain what you see as the difference?
I'm not particularly interested in type validation but I like the fact that
typical enum APIs allow you to group constants: the generated constant class
acts as a namespace for all the defined constants.
The problem with blessing one particular enum API is that people
have so many different ideas as to what an enum API should look like.
There actually seemed to be quite a bit of agreement around basic
functionality though.
However, the one thing they all have in common is the ability to take
a value and give it a name, then present *both* of those in debugging
information.
And this is the most important functionality. I would say that the
grouping (namespacing) of constants is also useful, provided by *most*
Python enum APIs and easy to implement without over complexifying the API.
(Note that there is no *particular* hurry to get this into 3.2 - the
beta is due imminently. I wouldn't object to it )
Are you just suggesting something along the lines of:
class NamedConstant(int):
def __new__(cls, name, val):
return int.__new__(cls, val)
def __init__(self, name, val):
self._name = name
def __repr__(self):
return 'NamedConstant %s' % self._name
FOO = NamedConstant('FOO', 3)
In general the less features the better, but I'd like a few more features
than that. :-)
Not quite. I'm suggesting a factory function that works for any value,
and derives the parent class from the type of the supplied value.
However, what you wrote is still the essence of the idea - we would be
primarily providing a building block that makes it easier for people
to *create* enum APIs if they want to, but for simple use cases (where
all they really wanted was the enhanced debugging information) they
wouldn't need to bother. In the standard library, wherever we do
enum-like things we would switch to using named values where it
makes sense to do so.
Doing so may actually make sense for more than just constants - it may
make sense for significant mutable globals as well.
Very interesting proposal (typed named values rather than just named
constants). It doesn't handle flag values, which I would still like, but
that only really makes sense for integers (sets can be OR'd but their
representation is already understandable). Perhaps the integer named
type could be special cased for that.
Without the grouping functionality (associating a bunch of names
together) you lose the 'from_name' functionality. Guido was in favour of
this, and it is an obvious feature where you have grouping:
http://mail.python.org/pipermail/python-dev/2010-November/105912.html
I expect that the API to convert between enums and bare ints should be
i = int(e) and e = enumclass(i). It would be nice if s = str(e) and
e = enumclass(s) would work too.
This wouldn't work with your suggested implementation (as it is).
Grouping and mutable named values could be inefficient and have issues
around identity / equality. Maybe restrict the API to the immutable
primitives.
All the best,
Michael
==
# Implementation (more than just a sketch, since it handles some
interesting corner cases)
import functools
@functools.lru_cache()
def _make_named_value_type(base_type):
class _NamedValueType(base_type):
def __new__(cls, name, value):
return base_type.__new__(cls, value)
def __init__(self, name, value):
self.__name = name
super().__init__(value)
@property
def _name(self):
return self.__name
def _raw(self):
return base_type(self)
def __repr__(self):
return {}={}.format(self._name, super().__repr__())
if base_type.__str__ is object.__str__:
__str__ = base_type.__repr__
_NamedValueType.__name__ = Named{}.format(base_type.__name__)
return _NamedValueType
def named_value(name, value):
return _make_named_value_type(type(value))(name, value)
def set_named_values(namespace, **kwds):
for k, v in kwds.items():
namespace[k] = named_value(k, v)
x = named_value(FOO, 1)
y = named_value(BAR, Hello World!)
z = named_value(BAZ, dict(a=1, b=2, c=3))
print(x, y, z, sep=\n)
print(\n.join(map(repr, (x, y, z
print(\n.join(map(str, map(type, (x, y, z)
set_named_values(globals(), foo=x._raw(), bar=y._raw(), baz=z._raw())
print(\n.join(map(repr, (foo, bar, baz
print(type(x) is type(foo), type(y) is type(bar), type(z) is type(baz))
==
# Session output for the last 6 lines
print(x, y, z, sep=\n)
1
Hello World!
{'a': 1, 'c': 3, 'b': 2}
print(\n.join(map(repr, (x, y, z
FOO=1
BAR='Hello World!'
BAZ={'a': 1, 'c': 3, 'b': 2}
print(\n.join(map(str,
Re: [Python-Dev] constant/enum type in stdlib
On Sun, Nov 28, 2010 at 12:01 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
Very interesting proposal (typed named values rather than just named
constants). It doesn't handle flag values, which I would still like, but
that only really makes sense for integers (sets can be OR'd but their
representation is already understandable). Perhaps the integer named type
could be special cased for that.
Without the grouping functionality (associating a bunch of names together)
you lose the 'from_name' functionality. Guido was in favour of this, and it
is an obvious feature where you have grouping:
http://mail.python.org/pipermail/python-dev/2010-November/105912.html
I expect that the API to convert between enums and bare ints should be
i = int(e) and e = enumclass(i). It would be nice if s = str(e) and
e = enumclass(s) would work too.
Note that the i = int(e) and s = str(e) parts of Guido's
expectation do work (they are, in fact, the underling implementation
of the _raw() method), so an enum class would only be needed to
provide the other half of the equation. The named values have no
opinion on equivalence at all (they just defer to the parent class),
but change the rules for identity (which are always murky anyway,
since caching is optional even for immutable types).
This wouldn't work with your suggested implementation (as it is). Grouping
and mutable named values could be inefficient and have issues around
identity / equality. Maybe restrict the API to the immutable primitives.
My proposal doesn't say anything about grouping at all - it's just an
idea for here's a standard way to associate a canonical name with a
particular object, independent of the namespaces that happen to
reference that object.
Now, a particular *grouping* API may want to restrict itself in
various ways, but that's my point. We should be looking at a standard
solution for the ground level problem (i.e. the idea named_value
attempts to solve) and then let various 3rd party enum/name grouping
implementations flourish on top of that, rather than trying to create
an all-singing all-dancing value grouping API (which is going to be
far more intrusive than a simple API for here's a way to give your
constants and important data structures names that show up in their
representations).
For example, using named_value as a primitive, you can fairly easily do:
class Namegroup:
# Missing lots of niceties of a real enum class, but shows the idea
# as to how a real implementation could leverage named_value
def __init__(self, _groupname, **kwds):
self._groupname = _groupname
pattern = _groupname + .{}
self._value_map = {}
for k, v in kwds.items():
attr = named_value(pattern.format(k), v)
setattr(self, k, attr)
self._value_map[v] = attr
@classmethod
def from_names(cls, groupname, *args):
kwds = dict(zip(args, range(len(args
return cls(groupname, **kwds)
def __call__(self, arg):
return self._value_map[arg]
silly = Namegroup.from_names(Silly, FOO, BAR, BAZ)
silly.FOO
Silly.FOO=0
int(silly.FOO)
0
silly(0)
Silly.FOO=0
named_value deals with all the stuff to do with pretending to be the
original type of object (only with an associated name), leaving the
grouping API to deal with issues of creating groups of names and
mapping between them and the original values in various ways.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86750 - python/branches/py3k/Demo/curses/life.py
On Sat, Nov 27, 2010 at 10:52 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: I just resign myself to having to spell words like colour and serialise wrong when I'm working on Python. Compared to the adjustments the non-native English speakers have to make, I figure I'm getting off lightly ;) I *thought* that the Python policy was that English speakers wrote documentation in English and American speakers wrote documentation in American and that we *don't* insist on US spellings in the Python documentation? If we're just talking about those things in generally, then that's a reasonable rule. But when in close proximity to an actual API that uses the American spelling, or modifying a file that uses the relevant word a lot, following the prevailing style is a definite courtesy to the reader. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86750 - python/branches/py3k/Demo/curses/life.py
On 27/11/2010 15:04, Nick Coghlan wrote: On Sat, Nov 27, 2010 at 10:52 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: I just resign myself to having to spell words like colour and serialise wrong when I'm working on Python. Compared to the adjustments the non-native English speakers have to make, I figure I'm getting off lightly ;) I *thought* that the Python policy was that English speakers wrote documentation in English and American speakers wrote documentation in American and that we *don't* insist on US spellings in the Python documentation? If we're just talking about those things in generally, then that's a reasonable rule. But when in close proximity to an actual API that uses the American spelling, or modifying a file that uses the relevant word a lot, following the prevailing style is a definite courtesy to the reader. Ok, thanks. Sounds like a good guideline. Michael Cheers, Nick. -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86745 - in python/branches/py3k: Doc/library/difflib.rst Lib/difflib.py Lib/test/test_difflib.py Misc/NEWS
On Sat, Nov 27, 2010 at 11:02 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: Features new in Python 3.2 that didn't exist in 3.1 should have a versionadded:: 3.2 tag. As Michael said, from a docs point of view, the version flow is independent: 2.6 - 2.7 and 3.1 - 3.2. The issue has really only come up with this release, since there was no intervening 2.x release between 3.0 and 3.1. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] constant/enum type in stdlib
On Nov 27, 2010, at 02:01 PM, Michael Foord wrote: (Note that there is no *particular* hurry to get this into 3.2 - the beta is due imminently. I wouldn't object to it ) Indeed. I don't think the time is right to try to get this into 3.2. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python make fails with error Fatal Python error: Interpreter not initialized (version mismatch?)
Hi All, During the make step of python, I am encountering a weird error. This is on AIX 5.3 using gcc as the compiler. My configuration options are as follows ./configure --enable-shared --disable-ipv6 --with-gcc=gcc CPPFLAGS=-I /opt/freeware/include -I /opt/freeware/include/readline -I /opt/freeware/include/ncurses LDFLAGS=-L. -L/usr/local/lib Below is the transcript from the make step. ++ running build running build_ext ldd: /lib/libreadline.a: File is an archive. INFO: Can't locate Tcl/Tk libs and/or headers building '_struct' extension gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/u01/home/apli/wm/GDD/Python-2.6.6/./Include -I. -IInclude -I./Include -I/opt/freeware/include -I/opt/freeware/include/readline -I/opt/freeware/include/ncurses -I/usr/local/include -I/u01/home/apli/wm/GDD/Python-2.6.6/Include -I/u01/home/apli/wm/GDD/Python-2.6.6 -c /u01/home/apli/wm/GDD/Python-2.6.6/Modules/_struct.c -o build/temp.aix-5.3-2.6/u01/home/apli/wm/GDD/Python-2.6.6/Modules/_struct.o ./Modules/ld_so_aix gcc -pthread -bI:Modules/python.exp -L. -L/usr/local/lib build/temp.aix-5.3-2.6/u01/home/apli/wm/GDD/Python-2.6.6/Modules/_struct.o -L. -L/usr/local/lib -lpython2.6 -o build/lib.aix-5.3-2.6/_struct.so *Fatal Python error: Interpreter not initialized (version mismatch?)* *make: 1254-059 The signal code from the last command is 6.* ++ The last command that i see above (ld_so_aix) seems to have completed as the file _struct.so exists after this command and hence I am not sure which step is failing. There is no other Python version on my machine. Please guide. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86745 - in python/branches/py3k: Doc/library/difflib.rst Lib/difflib.py Lib/test/test_difflib.py Misc/NEWS
On 11/27/2010 7:17 AM, Nick Coghlan wrote: On Thu, Nov 25, 2010 at 4:12 PM, terry.reedypython-check...@python.org wrote: The :class:`SequenceMatcher` class has this constructor: -.. class:: SequenceMatcher(isjunk=None, a='', b='') +.. class:: SequenceMatcher(isjunk=None, a='', b='', autojunk=True) Optional argument *isjunk* must be ``None`` (the default) or a one-argument function that takes a sequence element and returns true if and only if the @@ -340,6 +349,9 @@ The optional arguments *a* and *b* are sequences to be compared; both default to empty strings. The elements of both sequences must be :term:`hashable`. + The optional argument *autojunk* can be used to disable the automatic junk + heuristic. + Catching up on checkins traffic, so a later checkin may already fix this, but there should be a versionchanged tag in the docs to note when the autojunk parameter was added. Right. When S.C. forward-ported the 2.7 patch. he must have thought it not needed and I missed the difference between the diffs. Will add note in both places needed immediately. Terry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] constant/enum type in stdlib
On 11/27/2010 2:51 AM, Nick Coghlan wrote: Not quite. I'm suggesting a factory function that works for any value, and derives the parent class from the type of the supplied value. Nick, thanks for the much better implementation than I achieved; you seem to have the same goals as my implementation. I learned a bit making mine, and more understanding yours to some degree. What I still don't understand about your implementation, is that when adding one additional line to your file, it fails: w = named_value(ABC, z ) Now I can understand why it might not be a good thing to make a named value of a named value (confusing, at least), but I was surprised, and still do not understand, that it failed reporting the __new__() takes exactly 3 arguments (2 given). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Preview] Comments and change proposals on documentation
Nick Coghlan wrote: On Thu, Nov 25, 2010 at 6:24 AM, Georg Brandl g.bra...@gmx.net wrote: Hi, at http://dpo.gbrandl.de/contents, you can look at a version of the 3.2 docs that has the upcoming commenting feature. JavaScript is mandatory. Very nice! I'm not sure what to do about the discoverability of the comment bubbles as the end of each paragraph. I initially thought commenting wasn't available on What's New or the Using Python docs until seeing where the blue comment bubbles appeared in the math module docs. I wonder what the point of the comment bubbles is? This isn't a graphical UI where (contrary to popular opinion) a picture is *not* worth a thousand words, but may require a help-bubble to explain. This is text. If you want to make a comment on some text, the usual practice is to add more text :) I wasn't able to find a comment bubble that contained anything, so I don't know what sort of information you expect them to contain -- every one I tried said 0 comments. But it seems to me that comments are superfluous, if not actively harmful: (1) Anything important enough to tell the reader should be included in the text, where it can be easily seen, read and printed. (2) Discovery is lousy -- not only do you need to be running Javascript, which many people do not for performance, privacy and convenience[*], but you have to carefully mouse-over the paragraph just to see the blue bubble, and THEN you have to *precisely* mouse-over the bubble itself. (3) This will be a horrible and possibly even literally painful experience for anyone with a physical disability that makes precise positioning of the mouse difficult. (4) Accessibility for the blind and those using screen readers will probably be non-existent. (5) If the information in the comment bubbles is trivial enough that we're happy to say that the blind, the disabled and those who avoid Javascript don't need it, then perhaps *nobody* needs it. [*] In my experience, websites tend to fall into two basic categories: those that don't work at all without Javascript, and those that run better, faster, and with fewer anti-features and inconveniences without Javascript. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Preview] Comments and change proposals on documentation
Am 27.11.2010 23:11, schrieb Steven D'Aprano: Nick Coghlan wrote: On Thu, Nov 25, 2010 at 6:24 AM, Georg Brandl g.bra...@gmx.net wrote: Hi, at http://dpo.gbrandl.de/contents, you can look at a version of the 3.2 docs that has the upcoming commenting feature. JavaScript is mandatory. Very nice! I'm not sure what to do about the discoverability of the comment bubbles as the end of each paragraph. I initially thought commenting wasn't available on What's New or the Using Python docs until seeing where the blue comment bubbles appeared in the math module docs. I wonder what the point of the comment bubbles is? This isn't a graphical UI where (contrary to popular opinion) a picture is *not* worth a thousand words, but may require a help-bubble to explain. This is text. If you want to make a comment on some text, the usual practice is to add more text :) Yes, I already mentioned that the bubbles could be replaced by text links if they prove too confusing. I wasn't able to find a comment bubble that contained anything, so I don't know what sort of information you expect them to contain -- every one I tried said 0 comments. Maybe you should have tried the page I recommended as a demo, and where Nick made his comments? :) But it seems to me that comments are superfluous, if not actively harmful: (I've not read anything about harmful below. Was that just FUD?) (1) Anything important enough to tell the reader should be included in the text, where it can be easily seen, read and printed. Yes. There need to be ways for the reader to feed back to the author what they want to have included. Currently, this is I'm all for removing comments with suggestions once they have been integrated in the main text. (2) Discovery is lousy -- not only do you need to be running Javascript, which many people do not for performance, privacy and convenience[*], That is not an argument nowadays, seeing how many sites/web applications require JS. (Most people who deactivate JS globally maintain a whitelist anyway, and can easily add docs.python.org to that.) These comments are an optional feature and therefore do not need to be accessible for 100% of users. but you have to carefully mouse-over the paragraph just to see the blue bubble, and THEN you have to *precisely* mouse-over the bubble itself. Bubbles are always shown for paragraphs *with* comments. (3) This will be a horrible and possibly even literally painful experience for anyone with a physical disability that makes precise positioning of the mouse difficult. You're making this point just because of the size of the bubbles? Well, these users can register on the site and there can be a user preference to display larger links instead (if we choose to keep the bubbles, anyway.) (4) Accessibility for the blind and those using screen readers will probably be non-existent. It will be the same as for other web apps using JavaScript. Since I'm not a professional user interface designer, I don't know what screen readers can and cannot do. (5) If the information in the comment bubbles is trivial enough that we're happy to say that the blind, the disabled and those who avoid Javascript don't need it, then perhaps *nobody* needs it. Sorry, but that is a nonsensical argument. Apart from the questionable notion that anything must be available to everyone to be worth anything, it also doesn't consider that the comments are not only for fellow users: as I said above, the comments are designed to be a very quick way to give feedback to *us* developers. (This is the reason for the propose a change feature, for example.) So even if only 30% of all users had access to the comments and could use that to help us improve the documentation by submitting suggestions and corrections they never would have bothered registering in the tracker for, that would be a net gain. cheers, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] constant/enum type in stdlib
On Nov 27, 2010, at 12:56 PM, Glenn Linderman wrote: On 11/27/2010 2:51 AM, Nick Coghlan wrote: Not quite. I'm suggesting a factory function that works for any value, and derives the parent class from the type of the supplied value. Nick, thanks for the much better implementation than I achieved; you seem to have the same goals as my implementation. I learned a bit making mine, and more understanding yours to some degree. What I still don't understand about your implementation, is that when adding one additional line to your file, it fails: w = named_value(ABC, z ) Now I can understand why it might not be a good thing to make a named value of a named value (confusing, at least), but I was surprised, and still do not understand, that it failed reporting the __new__() takes exactly 3 arguments (2 given). Can I suggest that an enum-maker be offered as a third-party module rather than prematurely adding it into the standard library. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Preview] Comments and change proposals on documentation
Georg Brandl wrote: Am 27.11.2010 23:11, schrieb Steven D'Aprano: I wasn't able to find a comment bubble that contained anything, so I don't know what sort of information you expect them to contain -- every one I tried said 0 comments. Maybe you should have tried the page I recommended as a demo, and where Nick made his comments? :) Aha! I never would have guessed that the bubbles are clickable -- I thought you just moused-over them and they showed static comments put there by the developers, part of the documentation itself. I didn't realise that it was for users to add spam^W comments to the page. With that perspective, I need to rethink. Yes, I failed to fully read the instructions you sent, or understand them. That's what users do -- they don't read your instructions, and they misunderstand them. If your UI isn't easily discoverable, users will not be able to use it, and will be frustrated and annoyed. The user is always right, even when they're doing it wrong *wink* But it seems to me that comments are superfluous, if not actively harmful: (I've not read anything about harmful below. Was that just FUD?) Lowering accessibility to parts of the documentation is what I was talking about when I said actively harmful. But now that I have better understanding of what the comment system is actually for, I have to rethink. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] constant/enum type in stdlib
On 11/27/2010 12:56 PM, Glenn Linderman wrote: On 11/27/2010 2:51 AM, Nick Coghlan wrote: Not quite. I'm suggesting a factory function that works for any value, and derives the parent class from the type of the supplied value. Nick, thanks for the much better implementation than I achieved; you seem to have the same goals as my implementation. I learned a bit making mine, and more understanding yours to some degree. What I still don't understand about your implementation, is that when adding one additional line to your file, it fails: w = named_value(ABC, z ) Now I can understand why it might not be a good thing to make a named value of a named value (confusing, at least), but I was surprised, and still do not understand, that it failed reporting the __new__() takes exactly 3 arguments (2 given). OK, I puzzled out the error, and here is a cure of sorts. def __new__(cls, name, value): try: return base_type.__new__(cls, value) except TypeError: return base_type.__new__(cls, name, value) def __init__(self, name, value): self.__name = name try: super().__init__(value) except TypeError: super().__init__(name, value) Probably it would be better for the except clause to raise a different type of error ( Can't recursively create named value ) or to cleverly bypass the intermediate named value, and simply apply a new name to the original value. Hmm... For this, only __new__ need be changed: def __new__(cls, name, value): try: return base_type.__new__(cls, value) except TypeError: return _make_named_value_type( type( value._raw() ))( name, value._raw() ) def __init__(self, name, value): self.__name = name super().__init__(value) Thanks for not responding too quickly, I figured out more, and learned more. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] constant/enum type in stdlib
On Sun, Nov 28, 2010 at 9:26 AM, Raymond Hettinger raymond.hettin...@gmail.com wrote: On Nov 27, 2010, at 12:56 PM, Glenn Linderman wrote: On 11/27/2010 2:51 AM, Nick Coghlan wrote: Not quite. I'm suggesting a factory function that works for any value, and derives the parent class from the type of the supplied value. Nick, thanks for the much better implementation than I achieved; you seem to have the same goals as my implementation. I learned a bit making mine, and more understanding yours to some degree. What I still don't understand about your implementation, is that when adding one additional line to your file, it fails: w = named_value(ABC, z ) Now I can understand why it might not be a good thing to make a named value of a named value (confusing, at least), but I was surprised, and still do not understand, that it failed reporting the __new__() takes exactly 3 arguments (2 given). Can I suggest that an enum-maker be offered as a third-party module rather than prematurely adding it into the standard library. Indeed. Glenn's failing example suggests to me that using a new metaclass is probably going to be a cleaner option than trying to dance around type's default behaviour within an ordinary class definition (if nothing else, a separate metaclass makes it much easier to detect when you're dealing with an instance of a named type). Regardless, I still see value in approaching this whole discussion as a two-level design problem, with named values as the more fundamental concept, and then higher level grouping APIs to get enum-style behaviour. Eventually attaining One Obvious Way for the former seems achievable to me, while the diversity of use cases for grouping APIs suggests to me that one-size-fits-all isn't going to work unless that one size is a Frankenstein API with more options than anyone could reasonably hope to keep in their head at once. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] constant/enum type in stdlib
On 11/27/2010 6:26 PM, Raymond Hettinger wrote: Can I suggest that an enum-maker be offered as a third-party module Possibly with competing versions for trial and testing ;-) rather than prematurely adding it into the standard library. I had same thought. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Preview] Comments and change proposal s on documentation
Steven D'Aprano steve at pearwood.info writes:
Aha! I never would have guessed that the bubbles are clickable -- I
thought you just moused-over them and they showed static comments put
there by the developers, part of the documentation itself. I didn't
realise that it was for users to add spam^W comments to the page. With
that perspective, I need to rethink.
Yes, I failed to fully read the instructions you sent, or understand
them. That's what users do -- they don't read your instructions, and
they misunderstand them. If your UI isn't easily discoverable, users
will not be able to use it, and will be frustrated and annoyed. The user
is always right, even when they're doing it wrong *wink*
But it seems to me that comments are superfluous, if not actively harmful:
(I've not read anything about harmful below. Was that just FUD?)
Lowering accessibility to parts of the documentation is what I was
talking about when I said actively harmful. But now that I have better
understanding of what the comment system is actually for, I have to rethink.
As an end-user, I, too, share concerns about the accessibility of the pending
(proposed?) commenting functionality.
A read-only JSON API would be great.
Up until now, Sphinx has been an incredibly helpful tool for generating
beautiful documentation from ReStructuredText, which is great for limiting the
risk of malformed input.
The new commenting feature (dynamic application functionality) requires
persistence for user-submitted content. Database persistence is currently
implemented with the -excellent- SQLAlchemy ORM.
So, this is a transition from Sphinx being an excellent publishing tool to
being
a dynamic publishing platform for user-submitted content (comments). I am
sure
this was not without due consideration, and FUD.
The Python Web Framework communities (favorite framework *here*) will be the
first to reiterate the challenges that all web application developers (and
commenting API providers) face on a daily basis:
- SQL Injection
- XSS (Cross Site Scripting)
- CSRF (Cross Site Request Forgery)
Here are a few scenarios to consider:
(1) Freeloading jackass decides that each paragraph of our documentation would
look better with 200 comments for viagara. Freeloading jackass is aware of
how
HTTP GETs work.
- What markup features are supported?
- How does the application sanitize user-supplied input?
- Is html5lib good enough?
- On docs.python.org, how are 1000 inappropriate (freeloading) comments from
1000 different IPs deleted?
- What's the roadmap for {..., Akismet, ReCaptcha, ...} support?
(2) Freeloading jackass buys a block of javascript adspace on insert-site-
here.xxx. The block of javascript surreptitiously posts helpful comments on
behalf of unwitting users.
- How does the application ensure that comments are submitted from the site
hosting the documentation?
- Which frameworks have existing, reviewed CSRF protections?
Trying to read through the new source here [1], but there aren't many
docstrings
and BB doesn't yet support inline commenting. AFAIK, there are not yet any
issues filed for these concerns. [2]
1. In the event that that kind of bug is discovered, how should the community
report the issues?
2. If we have an alternate method of encouraging documentation feedback, how
can
this feature be turned off?
Thanks again for a great publishing tool,
Don
[1] http://bitbucket.org/birkenfeld/sphinx
[2] http://bitbucket.org/birkenfeld/sphinx/issues/new
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 2.7.1
On behalf of the Python development team, I'm happy as a clam to announce the immediate availability of Python 2.7.1. 2.7 includes many features that were first released in Python 3.1. The faster io module, the new nested with statement syntax, improved float repr, set literals, dictionary views, and the memoryview object have been backported from 3.1. Other features include an ordered dictionary implementation, unittests improvements, a new sysconfig module, auto-numbering of fields in the str/unicode format method, and support for ttk Tile in Tkinter. For a more extensive list of changes in 2.7, see http://doc.python.org/dev/whatsnew/2.7.html or Misc/NEWS in the Python distribution. To download Python 2.7.1 visit: http://www.python.org/download/releases/2.7.1/ The 2.7.1 changelog is at: http://svn.python.org/projects/python/tags/r271/Misc/NEWS 2.7 documentation can be found at: http://docs.python.org/2.7/ This is a production release. Please report any bugs you find to the bug tracker: http://bugs.python.org/ Enjoy! -- Benjamin Peterson Release Manager benjamin at python.org (on behalf of the entire python-dev team and 2.7.1's contributors) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.1.3
On behalf of the Python development team, I'm happy as a lark to announce the third bugfix release for the Python 3.1 series, Python 3.1.3. This bug fix release features numerous bug fixes and documentation improvements over 3.1.2. The Python 3.1 version series focuses on the stabilization and optimization of the features and changes that Python 3.0 introduced. For example, the new I/O system has been rewritten in C for speed. File system APIs that use unicode strings now handle paths with undecodable bytes in them. Other features include an ordered dictionary implementation, a condensed syntax for nested with statements, and support for ttk Tile in Tkinter. For a more extensive list of changes in 3.1, see http://doc.python.org/3.1/whatsnew/3.1.html or Misc/NEWS in the Python distribution. This is a production release. To download Python 3.1.3 visit: http://www.python.org/download/releases/3.1.3/ A list of changes in 3.1.3 can be found here: http://svn.python.org/projects/python/tags/r313/Misc/NEWS The 3.1 documentation can be found at: http://docs.python.org/3.1 Bugs can always be reported to: http://bugs.python.org Enjoy! -- Benjamin Peterson Release Manager benjamin at python.org (on behalf of the entire python-dev team and 3.1.3's contributors) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
