[Python-Dev] os.access and Unicode
Apparently, os.access was forgotten when the file system encoding was introduced in Python 2.2, and then it was again forgotten in PEP 277. I've now fixed it in the trunk (posixmodule.c:2.334), and I wonder whether this is a backport candidate. People who try to invoke os.access with a non-ASCII filename on non-NT+ systems will get a UnicodeError; with the patch, the operation will succeed (assuming the characters are all supported in the file system encoding). Should this be backported? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Useful thread project for 2.5?
"Phillip J. Eby" <[EMAIL PROTECTED]> writes: > Which reminds me, btw, it would be nice while we're adding more > execution control functions to have a way to get the current trace > hook and profiling hook, Well, there's the f_trace member of frame objects, but I honestly can't remember what it's for... > not to mention ways to set them on non-current threads. You can do > these things from C of course; I mean accessible as part of the > Python API. Again, given sys._current_frames(), this shouldn't be very hard. Cheers, mwh -- And then the character-only displays went away (leading to increasingly silly graphical effects and finally to ads on web pages). -- John W. Baxter, comp.lang.python ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Re: Useful thread project for 2.5?
Greg writes:
> This is one of my top two Java features [1].
...
> [1] The other is compiler recognition of "@deprecated" in doc comments.
Hmm... what a good idea! Let's see... what exactly does "@deprecated" DO in
Java? Why it causes the compiler to emit a warning if you use the function in
question. Not a bad idea. Amusingly enough, the syntax is even the same in
Python:
= code =
import warnings
def deprecated(func):
"""This is a decorator which can be used to mark functions
as deprecated. It will result in a warning being emmitted
when the function is used."""
def newFunc(*args, **kwargs):
warnings.warn("Call to deprecated function.")
return func(*args, **kwargs)
return newFunc
= example =
>>> @deprecated
def func(x,y):
return x + y
>>> func(3,4)
Warning (from warnings module):
File "g:/Documents/Personal/Python/deprecated.py", line 10
warnings.warn("Call to deprecated function.")
UserWarning: Call to deprecated function.
7
So... shall I go add this to the cookbook?
-- Michael Chermside
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Useful thread project for 2.5?
At 10:03 AM 3/8/05 +, Michael Hudson wrote: "Phillip J. Eby" <[EMAIL PROTECTED]> writes: > Which reminds me, btw, it would be nice while we're adding more > execution control functions to have a way to get the current trace > hook and profiling hook, Well, there's the f_trace member of frame objects, but I honestly can't remember what it's for... It sets the *local* trace function, which is only active if a *global* trace function is set for the thread. The global trace function is the thing you can't get at from Python. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.access and Unicode
Martin v. Löwis wrote: Apparently, os.access was forgotten when the file system encoding was introduced in Python 2.2, and then it was again forgotten in PEP 277. I've now fixed it in the trunk (posixmodule.c:2.334), and I wonder whether this is a backport candidate. People who try to invoke os.access with a non-ASCII filename on non-NT+ systems will get a UnicodeError; with the patch, the operation will succeed (assuming the characters are all supported in the file system encoding). Should this be backported? If there was no other way to get os.access-like functionality, I would say it should be backported. But since there are other ways to figure out everything that os.access can tell you I say don't backport and amend the docs to state it is not Unicode-aware. If one was adventurous enough the docs could even include other ways to get the same info when Unicode had to be used. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.access and Unicode
Brett C. wrote: Martin v. Löwis wrote: Apparently, os.access was forgotten when the file system encoding was introduced in Python 2.2, and then it was again forgotten in PEP 277. I've now fixed it in the trunk (posixmodule.c:2.334), and I wonder whether this is a backport candidate. People who try to invoke os.access with a non-ASCII filename on non-NT+ systems will get a UnicodeError; with the patch, the operation will succeed (assuming the characters are all supported in the file system encoding). Should this be backported? +1; it's a bug, not a new feature. If there was no other way to get os.access-like functionality, I would say it should be backported. But since there are other ways to figure out everything that os.access can tell you I say don't backport and amend the docs to state it is not Unicode-aware. If one was adventurous enough the docs could even include other ways to get the same info when Unicode had to be used. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 08 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] itemgetter/attrgetter extension
Any objections to extending itemgetter() and attrgetter() to be able to
extract multiple fields at a time?
# SELECT name, rank, serialnum FROM soldierdata
map(attrgetter('name', 'rank', 'serialnum'), soldierdata)
# SELECT * FROM soldierdata ORDER BY unit, rank, proficiency
sorted(soldierdata, key=attrgetter('unit', 'rank', 'proficiency'))
Raymond Hettinger
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] @deprecated (was: Useful thread project for 2.5?)
Greg wished for:
... compiler recognition of "@deprecated" in doc comments.
Michael Chermside suggested:
= code =
import warnings
def deprecated(func):
"""This is a decorator which can be used to mark functions
as deprecated. It will result in a warning being emmitted
when the function is used."""
def newFunc(*args, **kwargs):
warnings.warn("Call to deprecated function.")
return func(*args, **kwargs)
return newFunc
= example =
...
UserWarning: Call to deprecated function.
I agree that it should go in the cookbook, but I think you should
set the category to a DeprecationWarning and give the offending
function's name. (Whether to worry about suppression of calls
to *other* deprecated functions -- I think is out of scope for a recipe.)
def newFunc(*args, **kwargs):
warnings.warn("Call to deprecated function %s" % func.__name__,
category=DeprecationWarning)
return func(*args, **kwargs)
-jJ
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] @deprecated (was: Useful thread project for 2.5?)
> Michael Chermside suggested:
> import warnings
>
> def deprecated(func):
> """This is a decorator which can be used to mark functions
> as deprecated. It will result in a warning being emmitted
> when the function is used."""
> def newFunc(*args, **kwargs):
> warnings.warn("Call to deprecated function.")
> return func(*args, **kwargs)
> return newFunc
Decorators like this should preserve information about the underlying
function:
> def deprecated(func):
> """This is a decorator which can be used to mark functions
> as deprecated. It will result in a warning being emmitted
> when the function is used."""
> def newFunc(*args, **kwargs):
> warnings.warn("Call to deprecated function.")
> return func(*args, **kwargs)
newFunc.__name__ = func.__name__
newFunc.__doc__ = func.__doc__
newFunc.__dict__.update(func.__dict__)
> return newFunc
Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] LinkedHashSet/LinkedHashMap equivalents
The perennial "how do I remove duplicates from a list" topic came up on c.l.py and in the discussion I mentioned the java 1.5 LinkedHashSet and LinkedHashMap. I'd thought about proposing these before, but couldn't think of where to put them. It was pointed out that the obvious place would be the collections module. For those who don't know, LinkedHashSet and LinkedHashMap are simply hashed sets and maps that iterate in the order that the keys were added to the set/map. I almost invariably use them for the above scenario - removing duplicates without changing order. Does anyone else think it would be worthwhile adding these to collections, or should I just make a cookbook entry? Cheers. Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
Delaney, Timothy C (Timothy) <[EMAIL PROTECTED]> wrote: > The perennial "how do I remove duplicates from a list" topic came up on > c.l.py and in the discussion I mentioned the java 1.5 LinkedHashSet and > LinkedHashMap. I'd thought about proposing these before, but couldn't > think of where to put them. It was pointed out that the obvious place > would be the collections module. > > For those who don't know, LinkedHashSet and LinkedHashMap are simply > hashed sets and maps that iterate in the order that the keys were added > to the set/map. I almost invariably use them for the above scenario - > removing duplicates without changing order. > > Does anyone else think it would be worthwhile adding these to > collections, or should I just make a cookbook entry? I guess I'm -0 on this. Though I was the one that suggested that collections is the right place to put them, I'm not really certain how much we gain by including them. I too would only ever use them for removing duplicates from a list. But if we're trying to provide a solution to this problem, I'd rather see an iterable-friendly one. See a previous thread on this issue[1] where I suggest something like: def filterdups(iterable): seen = set() for item in iterable: if item not in seen: seen.add(item) yield item Adding this to, say, itertools would cover all my use cases. And as long as you don't have too many duplicates, filterdups as above should keep memory consumption down better. On the other hand, if someone could give me a few other reasonable use cases for LinkedHashSet and LinkedHashMap, I wouldn't object to their inclusion. Steve [1] http://mail.python.org/pipermail/python-list/2005-February/264179.html -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Modules ossaudiodev.c, 1.35, 1.36
On 08 March 2005, Anthony Baxter said: > I really would like to see it reverted, please. Done. Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ I just forgot my whole philosophy of life!!! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
Steven Bethard wrote: Delaney, Timothy C (Timothy) <[EMAIL PROTECTED]> wrote: The perennial "how do I remove duplicates from a list" topic came up on c.l.py and in the discussion I mentioned the java 1.5 LinkedHashSet and LinkedHashMap. I'd thought about proposing these before, but couldn't think of where to put them. It was pointed out that the obvious place would be the collections module. For those who don't know, LinkedHashSet and LinkedHashMap are simply hashed sets and maps that iterate in the order that the keys were added to the set/map. I almost invariably use them for the above scenario - removing duplicates without changing order. Does anyone else think it would be worthwhile adding these to collections, or should I just make a cookbook entry? I guess I'm -0 on this. Though I was the one that suggested that collections is the right place to put them, I'm not really certain how much we gain by including them. I too would only ever use them for removing duplicates from a list. But if we're trying to provide a solution to this problem, I'd rather see an iterable-friendly one. See a previous thread on this issue[1] where I suggest something like: def filterdups(iterable): seen = set() for item in iterable: if item not in seen: seen.add(item) yield item Adding this to, say, itertools would cover all my use cases. And as long as you don't have too many duplicates, filterdups as above should keep memory consumption down better. I am -1 on adding LinkedHash*. While I can understand wanting to get rid of duplicates easily and wanting a good solutoin, Steven's snippet of code shows rolling your own solution is easy. Plus this can even be simplified down to a one-liner using itertools already:: itertools.ifilterfalse(lambda item, _set=set(): (item in _set) or (_set.add(item) and False), iterable) I don't think it is the prettiest solution, but it does show that coming up with one is not hard nor restricted to only a single solution that requires knowing some Python idiom (well, mine does for the default arg to the lambda, but Steven's doesn't). The last thing I want to happen is for Python's stdlib to grow every possible data structure out there like Java seems to have. I don't ever want to have to think about what *variant* of a data structure I should use, only what *type* of data structure (and no, I don't count collections.deque and Queue.Queue an overlap since the latter is meant more for thread communication, at least in my mind). -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
No new features (was Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Modules ossaudiodev.c, 1.35, 1.36)
On 09 March 2005, Anthony Baxter said (privately): > Thanks! I really want to keep the no-new-features thing going for > as long as possible, pending any AoG (Acts of Guido), of course. Grumble. How do you feel about upgrading optparse to sync with Optik 1.5.1? I'm a bit embarassed that Python 2.4's optparse has __version__ == "1.5a2" because I didn't release Optik 1.5 in time. And yes, there were some tiny new features in 1.5 and a few more coming in 1.5.1: * SF patch #870807: allow users to specify integer option arguments in hexadecimal, octal, or binary with leading "0x", "0", or "0b" (1.5 final). * SF feature #1050184: add 'append_const' action (patch by Andrea 'fwyzard' Bocci) (1.5 final). * Keep going if importing gettext fails (so optparse can be used in the Python build process) (1.5 final). * Fix so the 'merge' script works again (bugs spotted, and mostly fixed, by Andrea 'fwyzard' Bocci). (1.5.1) * SF bug #1145594: add 'finish()' method to OptionParser so applications can explicitly break reference cycles, making life easier for Python's garbage collector. (1.5.1) * SF feature #988126: add 'epilog' attribute to OptionParser (and constructor arg): paragraph of text to print after the main option help. (1.5.1) * Corrected French translation (po/optik/fr.po) (Laurent Laporte). (1.5.1) Every one of these is useful to someone, and none of them are even remotely destabilizing. But they all add functionality that would be present in 2.4.1 and not in 2.4. That doesn't bother me in the slightest, but I guess it bothers some people. I'd like to check this in for 2.4.1. But I won't if anyone says "don't do it". Nor will I if no one else says "do it". Burnt once... Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ Any priest or shaman must be presumed guilty until proven innocent. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode inconsistency?
On Sat, Apr 04, 1998 at 07:04:02AM +, Tim Peters wrote:
> [Martin v. L?wis]
> > I can't see any harm by supporting this operation also if __str__ returns
> > a Unicode object.
>
> It doesn't sound like a good idea to me, at least in part because it
> would be darned messy to implement short of saying "OK, we don't give
> a rip anymore about what type of objects PyObject_{Str,Repr} return",
It's about 10 lines of code. See http://python.org/sf/1159501 .
Neil
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
@deprecated (was Re: [Python-Dev] Re: Useful thread project for 2.5?)
On 08 March 2005, Michael Chermside said: > Greg writes: > > This is one of my top two Java features [1]. > ... > > [1] The other is compiler recognition of "@deprecated" in doc comments. > > Hmm... what a good idea! Let's see... what exactly does "@deprecated" DO in > Java? Why it causes the compiler to emit a warning if you use the function in > question. Not a bad idea. Isn't it, though? > Amusingly enough, the syntax is even the same in > Python: [...code omitted...] Cl. So simple, and yet so powerful. One might even call it Pythonic! > So... shall I go add this to the cookbook? Hell yes! Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ Always look on the bright side of life. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
On 09 March 2005, Delaney, Timothy C (Timothy) said: > For those who don't know, LinkedHashSet and LinkedHashMap are simply > hashed sets and maps that iterate in the order that the keys were added > to the set/map. I almost invariably use them for the above scenario - > removing duplicates without changing order. > > Does anyone else think it would be worthwhile adding these to > collections, or should I just make a cookbook entry? +1 on a cookbook entry. +0 on adding to stdlib. I'll attach another approach to the same problem, an ordered dictionary object. I believe the semantics of adding/readding/deleting keys is the same as java.util.LinkedHashMap -- certainly it seems the most sensible and easy-to-implement semantics. Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ I brought my BOWLING BALL -- and some DRUGS!! """ Provides odict, a subclass of the standard dict type that preserves insertion order. """ __revision__ = "$Id: odict.py,v 1.1 2004/03/09 02:32:08 gward Exp $" class odict(dict): """ An order-preserving mapping: lookup works like a dictionary, but keys(), values(), items(), etc. all return items in order of insertion. (Resetting a key preserves order; deleting a key and re-adding it moves it to the end.) Don't use this for enormous dictionaries, since it increases the memory use of the whole object, and the worst-case runtime for many common operations is O(N) rather than O(1). """ def __init__(self, arg=None): super(odict, self).__init__() self.order = [] if isinstance(arg, dict): self.update(arg) def copy(self): return self.__class__(self) def __delitem__(self, key): dict.__delitem__(self, key) self.order.remove(key) def __iter__(self): return iter(self.order) def __setitem__(self, key, value): add = key not in self dict.__setitem__(self, key, value) if add: self.order.append(key) def items(self): return [(key, self[key]) for key in self.order] def keys(self): return self.order def values(self): return [self[key] for key in self.order] def iteritems(self): for key in self.order: yield (key, self[key]) iterkeys = __iter__ def itervalues(self): for key in self.order: yield self[key] def clear(self): dict.clear(self) self.order.clear() def popitem(self): """ Remove and return the most-recently-added item of the mapping. """ key = self.order.pop() value = self[key] dict.__delitem__(self, key) return value def setdefault(self, key, value=None): if key in self: return self[key] else: self[key] = value return value def update(self, other): for key in other: self[key] = other[key] if __name__ == "__main__": m = odict() m['foo'] = 43 m['bar'] = 'barf' m[42] = None print m.items() ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 279 open (-24) / 2797 closed (+33) / 3076 total ( +9) Bugs: 851 open ( +2) / 4853 closed (+16) / 5704 total (+18) RFE : 173 open ( +4) / 150 closed ( +2) / 323 total ( +6) New / Reopened Patches __ Fix for win32 proxy bypass support (no_proxy) in urllib(2) (2005-03-01) http://python.org/sf/1154227 opened by mullendr Fix for win32 proxy bypass support (no_proxy) in urllib(2) (2005-03-02) CLOSED http://python.org/sf/1155083 opened by mullendr exception doc updates (2005-03-03) CLOSED http://python.org/sf/1156102 opened by Michael Hudson patch for bug 1158490 (locale breakage) (2005-03-08) http://python.org/sf/1158909 opened by Wummel cookielib mis-handles RFC 2109 cookies in Netscape mode (2005-03-04) http://python.org/sf/1157027 opened by John J Lee fix for a deadlock in the logging module (2005-03-07) http://python.org/sf/1158052 opened by Sebastian Prause Names conflict with QT (on linux) (2005-03-08) http://python.org/sf/1158926 opened by CyberRan Handle corrupted gzip files with unexpected EOF (2005-03-08) http://python.org/sf/1159051 opened by Wummel cgi.py invalid REQUEST_METHOD set (2005-03-08) http://python.org/sf/1159139 opened by Joe Improve %s support for unicode (2005-03-09) http://python.org/sf/1159501 opened by Neil Schemenauer Patches Closed __ Reference count bug fix (2005-02-12) http://python.org/sf/1121234 closed by loewis PEP 309 reference implementation (2004-04-07) http://python.org/sf/931005 closed by rhettinger Fix for win32 proxy bypass support (no_proxy) in urllib(2) (2005-03-02) http://python.org/sf/1155083 closed by loewis Flush stdout/stderr if closed (fix for bug 1074011) (2004-11-29) http://python.org/sf/1075147 closed by loewis setup.py --help and --help-commands altered. (2005-01-17) http://python.org/sf/1104111 closed by loewis tarfile.ExFileObject iterators (2005-01-23) http://python.org/sf/1107973 closed by loewis patch for gzip.GzipFile.flush() (2005-01-26) http://python.org/sf/1110248 closed by loewis PyArg_ParseTuple problem with 'L' format (2003-04-17) http://python.org/sf/723201 closed by loewis crach link c++ extension by mingw (2004-06-29) http://python.org/sf/981773 closed by loewis Patch for Lib/bsddb/__init__.py to work with modulefinder (2005-01-31) http://python.org/sf/1112812 closed by loewis Changes to cookielib.py & friends for 2.4b1 (2004-09-16) http://python.org/sf/1028908 closed by loewis cookielib and cookies with special names (2005-02-06) http://python.org/sf/1117339 closed by loewis cookielib.LWPCookieJar incorrectly loads value-less cookies (2005-02-06) http://python.org/sf/1117454 closed by loewis Consistent retrieval of Python version. (2004-10-14) http://python.org/sf/1046831 closed by loewis allow UNIX mmap size to default to current file size (new) (2005-02-19) http://python.org/sf/1144555 closed by loewis allow UNIX mmap size to default to current file size (2003-06-06) http://python.org/sf/749830 closed by loewis better timer resolution for profile.py (2002-11-30) http://python.org/sf/645894 closed by loewis better parser error message for non-EOL following line cont. (2003-09-08) http://python.org/sf/802188 closed by loewis Updated "Working on Cygwin" section (2005-01-22) http://python.org/sf/1107221 closed by loewis Non-ascii in non-unicode __credits__ in Lib/pydoc.py (2004-08-15) http://python.org/sf/1009389 closed by mwh exception doc updates (2005-03-03) http://python.org/sf/1156102 closed by mwh support PY_LONGLONG in structmember (2005-02-02) http://python.org/sf/1115086 closed by loewis HEAD/PUT/DELETE support for urllib2.py (2005-01-28) http://python.org/sf/653 closed by loewis tarfile.py: fix for bug #1100429 (2005-01-16) http://python.org/sf/1103407 closed by loewis Patch for bug 1088077 (2004-12-19) http://python.org/sf/1088078 closed by loewis gcc compiler on Windows (2004-11-30) http://python.org/sf/1075887 closed by loewis tarfile: add extractall() method (2004-10-10) http://python.org/sf/1043890 closed by loewis Arrange 64bits detection for ReliantUnix (2004-05-24) http://python.org/sf/959534 closed by loewis tarfile.py enhancements (2004-03-17) http://python.org/sf/918101 closed by loewis Allow compilation of C/C++ Python extensions without MSVC (2004-05-19) http://python.org/sf/957033 closed by loewis Fix crash in xmlprase_GetInputContext in pyexpat.c (2005-02-08) http://python.org/sf/1118602 closed by loewis Minor improvement on 1116583 (2005-02-06) http://python.org/sf/1117114 cl
RE: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
Greg Ward wrote: > I'll attach another approach to the same problem, an ordered > dictionary object. I believe the semantics of > adding/readding/deleting keys is the same as java.util.LinkedHashMap > -- certainly it seems the most sensible and easy-to-implement > semantics. That's essentially the same approach I used - I didn't get around to properly implementing a doubly-linked list between the keys - I just maintained a list with the correct order. If I'm going to write a Cookbook recipe though I should probably do it properly ... Personally, I think it would be quite nice if all python dictionaries had these semantics - it would be nice to be able to say that items will be returned in the order they're inserted - but I wouldn't want to incur the additional cost in such a fundamental data structure. One thing I did notice - dict.__repr__ and dict.__str__ don't produce strings in the iteration order of subclasses - they always use the arbitrary dict iteration order. Is this intentional? Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: No new features (was Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Modules ossaudiodev.c, 1.35, 1.36)
On Tue, Mar 08, 2005, Greg Ward wrote: > On 09 March 2005, Anthony Baxter said (privately): >> >> Thanks! I really want to keep the no-new-features thing going for >> as long as possible, pending any AoG (Acts of Guido), of course. > > Grumble. How do you feel about upgrading optparse to sync with Optik > 1.5.1? I'm a bit embarassed that Python 2.4's optparse has __version__ > == "1.5a2" because I didn't release Optik 1.5 in time. -1, sorry -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
