[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 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] 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 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] 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 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] 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 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] 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 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] 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
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] @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 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] @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 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] 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 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] 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 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
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 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] 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
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] 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 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: 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 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
