Re: [Python-Dev] r83893 - python/branches/release27-maint/Misc/ACKS
On 8/10/2010 6:29 PM, Martin v. Löwis wrote: If I were committing a patch and was checking to see whether a name that started with a decorated A (or any other letter) were already in the list, I would look in the appropriate place in the A (or other) section, not after Z. Everyone working on the English-based Python distribution knows the order of the 26 English letters. Please use that order (including for decorated versions and tranliterations) instead of various idiosyncratic and possibly conflicting nationality-based rules. So where do you put Γεώργιος Μπουτσιούκης? As I said above, where the transliterated version Geor.. goes, with the tranliteration followed by '(Γεώργιος Μπουτσιούκης)' as I suggested elsewhere -- 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] r83893 - python/branches/release27-maint/Misc/ACKS
On Wed, Aug 11, 2010 at 12:56 AM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: .. BTW, does anybody know if Jiba = Jean-Baptiste LAMY (Jiba)? Yes that's it. He work on Soya 3d ___ 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] Proposed tweaks to functools.wraps
On Wed, Aug 11, 2010 at 4:39 AM, Benjamin Peterson benja...@python.org wrote: Namespace conflict with what? I would prefer wraps unless it's standardized as a behavior for all decorators. Having the original function available as __wrapped__ would be really cool, although I'm not quite sure what the behaviour should be in corner cases like: * The decorator returns the original function (I suppose a reference to itself is okay?) * The decorator returns the a function that is already decorating something else. Schiavo Simon ___ 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] Proposed tweaks to functools.wraps
On Wed, Aug 11, 2010 at 9:26 PM, Simon Cross hodgestar+python...@gmail.com wrote: On Wed, Aug 11, 2010 at 4:39 AM, Benjamin Peterson benja...@python.org wrote: Namespace conflict with what? I would prefer wraps unless it's standardized as a behavior for all decorators. Having the original function available as __wrapped__ would be really cool, although I'm not quite sure what the behaviour should be in corner cases like: * The decorator returns the original function (I suppose a reference to itself is okay?) * The decorator returns the a function that is already decorating something else. Those are the corner cases that make it more appropriate to have this as a behaviour of functools.update_wrapper() (and hence the functools.wraps() decorator) rather than built in to the decorator machinery. The change will just add the following line to update_wrapper(): wrapper.__wrapped__ = wrapped 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] Proposed tweaks to functools.wraps
On Wed, Aug 11, 2010 at 8:45 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 11 Aug 2010 12:30:40 +1000 Nick Coghlan ncogh...@gmail.com wrote: The second (#9396) came up in the context of the new cache decorators added to functools, and allowing applications to choose their own caching strategies. I suggested exposing the original (uncached) function, and Raymond suggested that the easiest way to enable that would be for functools.update_wrapper to add a new attribute that provides a reference to the original function. Some time back, we considered doing this automatically as an integral part of decoration, but decided that wasn't appropriate. However, building it into the explicit wrapping functions makes sense to me. To avoid namespace conflicts, I plan to use __wraps__ as the name for the reference to the original function. I think it should be __wrapped__. Agreed, particularly since the relevant argument to update_wrapper() is already called wrapped. 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] Proposed tweaks to functools.wraps
On Wed, 11 Aug 2010 09:26:56 pm Simon Cross wrote: On Wed, Aug 11, 2010 at 4:39 AM, Benjamin Peterson benja...@python.org wrote: Namespace conflict with what? I would prefer wraps unless it's standardized as a behavior for all decorators. Having the original function available as __wrapped__ would be really cool, although I'm not quite sure what the behaviour should be in corner cases like: * The decorator returns the original function (I suppose a reference to itself is okay?) There's no reason why a function can't have an attribute that refers to the function itself. It works fine: def f(): ... return f.__wrapped__ ... f.__wrapped__ = f f() is f True But in the case of a decorator returning the original function, the point is moot. If the original function is returned, then it hasn't been decorated at all, so there shouldn't be a __wrapped__ attribute added: def decorator(func): if not __debug__: # Return undecorated original. return func @wraps(func) def inner(*args): print args return func(*args) return inner * The decorator returns the a function that is already decorating something else. That shouldn't make any difference. Given: @wraps(f) def func(*args): do_something() return f(*args) then func.__wrapped__ gives f. If f itself wraps (say) g, and g wraps h, then you have: func.__wrapped__ = f func.__wrapped__.__wrapped__ = g func.__wrapped__.__wrapped__.__wrapped__ = h and so on, until you reach a function that doesn't wrap anything and doesn't have a __wrapped__ attribute. I'm +1 on the proposal. -- Steven D'Aprano ___ 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] mingw support?
David Cournapeau: Autotools only help for posix-like platforms. They are certainly a big hindrance on windows platform in general, That is why mingw has MSYS. mingw is not just a gcc port, but also a miniature gnu environment for windows. MSYS' bash shell allows us to do things like: $ ./configure $ make make install Sturla ___ 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] r83893 - python/branches/release27-maint/Misc/ACKS
On Tue, 10 Aug 2010 15:25:52 -0400
Terry Reedy tjre...@udel.edu wrote:
Everyone working on the English-based Python distribution knows the
order of the 26 English letters.
How does that solve anything?
I just had to decide whether “Jason V. Miller” had to come before or
after “Jay T. Miller” ('Jason' 'Jay' but 'V' 'T'). Knowledge of the
“English” alphabet isn't enough to make a resolution: an idiosyncratic
rule is still needed.
(and before you claim that rule is well-known: I had to ask)
Regards
Antoine.
___
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] Proposed tweaks to functools.wraps
On Wed, Aug 11, 2010 at 3:00 PM, Steven D'Aprano st...@pearwood.info wrote: * The decorator returns the original function (I suppose a reference to itself is okay?) There's no reason why a function can't have an attribute that refers to the function itself. It works fine: Yes. But it's more common for the original function to have be modified in some way. e.g.: def autodoc(f): f.__doc__ += document_args(f) return f @autodoc def f(x, y): Add two numbers return x + y And then f.__wrapped__ is not particularly useful because the original function no longer exists and odd things will happen. For example, in the code above autodoc(f.__wrapped__).__doc__ will not equal f.__doc__. * The decorator returns the a function that is already decorating something else. That shouldn't make any difference. Given: @wraps(f) def func(*args): do_something() return f(*args) then func.__wrapped__ gives f. If f itself wraps (say) g, and g wraps h, then you have: I guess my description of the problem wasn't clear. I meant: def _debug(*args, **kwargs) print args, kwargs def mock(f): return _debug @mock def plus(a, b): return a + b @mock def prod(a, b): return a * b Schiavo Simon ___ 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] New Summary Lists on Issue Tracker
Thanks to whoever's been working on the new Summary lists on the Issue Tracker. The Followed by you / Created by you / Assigned to you are just what the doctor ordered. TJG ___ 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] Proposed tweaks to functools.wraps
I think this is a good idea, because sometimes getting the innermost wrapped function from a wrapper function is very useful. For example, when I use inspect.getsource(), in most case, I want to get the source code of the wrapped function, not the wrapper, because the wrapped function usually contains the most important code. Even further, we can add optional keyword argument to let the functions in inspect module to get the wrapped function instead of the wrapper function by following the __wrapped__ chain automatically. -- Ray Allen Best wishes! ___ 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] New Summary Lists on Issue Tracker
On Wed, Aug 11, 2010 at 3:21 PM, Tim Golden m...@timgolden.me.uk wrote: Thanks to whoever's been working on the new Summary lists on the Issue Tracker. Ezio Melotti, I assume. The Followed by you / Created by you / Assigned to you are just what the doctor ordered. Agreed. Now I can get rid of my own equivalent custom searches. :) One niggle: we seem to have lost the simple 'Open Issues' search under 'Summaries' on the left-hand side of the page. This feels a bit odd, given that it's what's displayed by default when a non-registered user goes to http://bugs.python.org. If that non-registered user then clicks on something else, like 'easy issues', there doesn't seem to be any easy way (that I can see) to go back to the original list of all open issues. Of course, as a registered user, I can add my own custom search for that if I want it. But I can't help feeling that non-registered users might miss this. Mark ___ 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] New Summary Lists on Issue Tracker
On 11/08/2010 17.59, Mark Dickinson wrote: On Wed, Aug 11, 2010 at 3:21 PM, Tim Goldenm...@timgolden.me.uk wrote: Thanks to whoever's been working on the new Summary lists on the Issue Tracker. Ezio Melotti, I assume. Yes :) (see http://psf.upfronthosting.co.za/roundup/meta/issue329) The Followed by you / Created by you / Assigned to you are just what the doctor ordered. Agreed. Now I can get rid of my own equivalent custom searches. :) One niggle: we seem to have lost the simple 'Open Issues' search under 'Summaries' on the left-hand side of the page. I was expecting someone to complain about it. This feels a bit odd, given that it's what's displayed by default when a non-registered user goes to http://bugs.python.org. If that non-registered user then clicks on something else, like 'easy issues', there doesn't seem to be any easy way (that I can see) to go back to the original list of all open issues. There actually is an easy way: the big python logo on the top left of the page. However I understand that this is not so obvious, so I can either add back the 'open issues' link or try to make it more obvious. Of course, as a registered user, I can add my own custom search for that if I want it. But I can't help feeling that non-registered users might miss this. Mark Best Regards, Ezio Melotti ___ 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] Fixing #7175: a standard location for Python config files
Hello list Tarek opened a distutils bugs in http://bugs.python.org/issue7175 that evolved into a discussion about the proper location to use for config files. Distutils uses [.]pydistutils.cfg and .pypirc, and now unittest2 has a config file too. It would be nice to define one standard location for config files used by stdlib modules, and maybe also by third-party programs related closely to Python development (testing tools, static code checkers and the like), in a way that doesn’t clutter the user home directory with a dozen dotfiles while still being easily found. (The Unix notions of dotfiles and home directory have to be adapted to use non-dotfiles in some standard place on various Windows. The Mac experts disagree on the right directory to use.) Tarek, Antoine, RDM, MAL were +1 on using ~/.python (whether to use .pythonx.y or .python/x.y is a subissue to discuss after general agreement). What do you think about this? Regards ___ 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] New Summary Lists on Issue Tracker
On Wed, Aug 11, 2010 at 4:09 PM, Ezio Melotti ezio.melo...@gmail.com wrote: On 11/08/2010 17.59, Mark Dickinson wrote: One niggle: we seem to have lost the simple 'Open Issues' search under 'Summaries' on the left-hand side of the page. I was expecting someone to complain about it. Glad to oblige. :) There actually is an easy way: the big python logo on the top left of the page. Ah yes---that does indeed work. Thanks! However I understand that this is not so obvious Well, it wasn't obvious to me, at least. If I'd thought about it, I probably would have expected that logo to take me back to the top-level python.org site. so I can either add back the 'open issues' link or try to make it more obvious. Well, perhaps I'm the only person bothered by this (and when I say 'bothered', it's not exactly keeping me up at nights). So unless/until there's evidence that others would like it restored, I wouldn't worry about it. In any case, thanks for all the b.p.o. improvements! Mark ___ 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] Fixing #7175: a standard location for Python config files
On 11/08/2010 16:22, Éric Araujo wrote: Hello list Tarek opened a distutils bugs in http://bugs.python.org/issue7175 that evolved into a discussion about the proper location to use for config files. Distutils uses [.]pydistutils.cfg and .pypirc, and now unittest2 has a config file too. IDLE has a config directory too - currently .idlerc in ~ (on Mac OS X at any rate). Michael It would be nice to define one standard location for config files used by stdlib modules, and maybe also by third-party programs related closely to Python development (testing tools, static code checkers and the like), in a way that doesn’t clutter the user home directory with a dozen dotfiles while still being easily found. (The Unix notions of dotfiles and home directory have to be adapted to use non-dotfiles in some standard place on various Windows. The Mac experts disagree on the right directory to use.) Tarek, Antoine, RDM, MAL were +1 on using ~/.python (whether to use .pythonx.y or .python/x.y is a subissue to discuss after general agreement). What do you think about this? Regards ___ 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.ironpythoninaction.com/ http://www.voidspace.org.uk/blog 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] New Summary Lists on Issue Tracker
On 11 Aug, 2010, at 16:21, Tim Golden wrote: Thanks to whoever's been working on the new Summary lists on the Issue Tracker. The Followed by you / Created by you / Assigned to you are just what the doctor ordered. I'm not quite happy about them because these reports include closed issues which is noise most of the time, and because issues aren't grouped or ordered by priorities. Ronald smime.p7s Description: S/MIME cryptographic 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
Re: [Python-Dev] New Summary Lists on Issue Tracker
On 11/08/2010 16:45, Ronald Oussoren wrote: On 11 Aug, 2010, at 16:21, Tim Golden wrote: Thanks to whoever's been working on the new Summary lists on the Issue Tracker. The Followed by you / Created by you / Assigned to you are just what the doctor ordered. I'm not quite happy about them because these reports include closed issues which is noise most of the time, and because issues aren't grouped or ordered by priorities. Hadn't noticed that in my enthusiasm about having them at all. TJG ___ 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] mingw support?
On Wed, Aug 11, 2010 at 03:21:15PM +0200, Sturla Molden wrote: David Cournapeau: Autotools only help for posix-like platforms. They are certainly a big hindrance on windows platform in general, That is why mingw has MSYS. mingw is not just a gcc port, but also a miniature gnu environment for windows. MSYS' bash shell allows us to do things like: $ ./configure $ make make install Sturla I will try to compile the python-svn trunk then by using the autotools plus tdm-gcc (a mingw fork) as well as MSYS. I might try to report any errors back to the autotools list and sort out with them what is happening. Gabriel ___ 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] Fixing #7175: a standard location for Python config files
On Wed, Aug 11, 2010 at 11:22 AM, Éric Araujo mer...@netwok.org wrote: Tarek, Antoine, RDM, MAL were +1 on using ~/.python (whether to use .pythonx.y or .python/x.y is a subissue to discuss after general agreement). +0.5 I'd like to see a more complete proposal, including: - what to do with Windows, Mac OS X - backward compatibility considered (seems straightforward, but seemings are often wrong) - cross-platform API to locate these files (should be able to address the b/w compat issues) Seems like a good idea to have a registry of files known to be placed there (a wiki page should be sufficient; if the API is used to create the directory, it can drop in a README.txt pointing to that page). -Fred -- Fred L. Drake, Jr. fdrake at gmail.com A storm broke loose in my mind. --Albert Einstein ___ 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] New Summary Lists on Issue Tracker
On Wed, Aug 11, 2010 at 11:28 AM, Mark Dickinson dicki...@gmail.com wrote: Well, perhaps I'm the only person bothered by this (and when I say 'bothered', it's not exactly keeping me up at nights). I'm not going to lose sleep over it either, but the logo-link is generally considered very non-discoverable. Keeping a query in the sidebar doesn't seem a huge price to pay. -Fred -- Fred L. Drake, Jr. fdrake at gmail.com A storm broke loose in my mind. --Albert Einstein ___ 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] Proposed tweaks to functools.wraps
On Aug 11, 2010, at 6:00 AM, Steven D'Aprano wrote: @wraps(f) def func(*args): do_something() return f(*args) then func.__wrapped__ gives f. If f itself wraps (say) g, and g wraps h, then you have: func.__wrapped__ = f func.__wrapped__.__wrapped__ = g func.__wrapped__.__wrapped__.__wrapped__ = h and so on, until you reach a function that doesn't wrap anything and doesn't have a __wrapped__ attribute. I'm +1 on the proposal. +1 from me also. The ability to introspect is basic to Python's design. Objects know their class, functions know their code objects, bound methods know both their underlying function, classes know their own class dictionary, etc. 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] New Summary Lists on Issue Tracker
On Thu, Aug 12, 2010 at 1:45 AM, Ronald Oussoren ronaldousso...@mac.com wrote: On 11 Aug, 2010, at 16:21, Tim Golden wrote: Thanks to whoever's been working on the new Summary lists on the Issue Tracker. The Followed by you / Created by you / Assigned to you are just what the doctor ordered. I'm not quite happy about them because these reports include closed issues which is noise most of the time, and because issues aren't grouped or ordered by priorities. I like the new list of standard queries, and don't mind having them sorted by activity rather than priority. (And with the closed issues grouped after the open issues, that aspect doesn't really bother me either). However, it would be nice to at least have the issue priority *visible* in the results for these searches. If I want more than that, it's easy enough to keep my own queries around. 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] Proposed tweaks to functools.wraps
On Thu, Aug 12, 2010 at 12:12 AM, Simon Cross hodgestar+python...@gmail.com wrote: Yes. But it's more common for the original function to have be modified in some way. e.g.: def autodoc(f): f.__doc__ += document_args(f) return f @autodoc def f(x, y): Add two numbers return x + y And then f.__wrapped__ is not particularly useful because the original function no longer exists and odd things will happen. For example, in the code above autodoc(f.__wrapped__).__doc__ will not equal f.__doc__. There's no call to wraps or update_wrapper here, so f.__wrapped__ won't exist. I guess my description of the problem wasn't clear. I meant: def _debug(*args, **kwargs) print args, kwargs def mock(f): return _debug @mock def plus(a, b): return a + b @mock def prod(a, b): return a * b Again, without any calls to wraps or update_wrapper, plus.__wrapped__ and prod.__wrapped__ won't exist. However, as I noted before, these kinds of scenario are the reason we decided that building this feature directly into the decorator machinery wasn't a good idea. 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] Proposed tweaks to functools.wraps
On 8/11/2010 3:16 PM, Raymond Hettinger wrote: The ability to introspect is basic to Python's design. Objects know their class, functions know their code objects, bound methods know both their underlying function, classes know their own class dictionary, etc. Should iterators know their iterable when there is one? There is or was a request for this on python-list, I believe, a few days ago. I suggested bad idea because a) iterator requirement is intentially minimal b) not all iterators have underlying object c) OP wanted to mutate underlying object (list) while iterating I did give a my_iter class that would do what OP wanted. -- 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] Proposed tweaks to functools.wraps
On Wed, Aug 11, 2010 at 11:21 PM, Nick Coghlan ncogh...@gmail.com wrote: However, as I noted before, these kinds of scenario are the reason we decided that building this feature directly into the decorator machinery wasn't a good idea. I agree. I was just replying to Steven's response to my post. :) Schiavo Simon ___ 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] Proposed tweaks to functools.wraps
On Aug 11, 2010, at 2:37 PM, Terry Reedy wrote: On 8/11/2010 3:16 PM, Raymond Hettinger wrote: The ability to introspect is basic to Python's design. Objects know their class, functions know their code objects, bound methods know both their underlying function, classes know their own class dictionary, etc. Should iterators know their iterable when there is one? There is or was a request for this on python-list, I believe, a few days ago. I suggested bad idea because a) iterator requirement is intentially minimal b) not all iterators have underlying object c) OP wanted to mutate underlying object (list) while iterating I did give a my_iter class that would do what OP wanted. I agree with your assessment. Also an iterator is a protocol, not a single class. 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] Proposed tweaks to functools.wraps
2010/8/11 Raymond Hettinger raymond.hettin...@gmail.com: On Aug 11, 2010, at 2:37 PM, Terry Reedy wrote: On 8/11/2010 3:16 PM, Raymond Hettinger wrote: The ability to introspect is basic to Python's design. Objects know their class, functions know their code objects, bound methods know both their underlying function, classes know their own class dictionary, etc. Should iterators know their iterable when there is one? There is or was a request for this on python-list, I believe, a few days ago. I suggested bad idea because a) iterator requirement is intentially minimal b) not all iterators have underlying object c) OP wanted to mutate underlying object (list) while iterating I did give a my_iter class that would do what OP wanted. I agree with your assessment. Also an iterator is a protocol, not a single class. As is decoration... -- Regards, Benjamin ___ 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] Fixing #7175: a standard location for Python config files
Hello, Fred Drake fdrake at acm.org wrote: +0.5 I'd like to see a more complete proposal, including: - what to do with Windows, Mac OS X PEP 370 already specifies a directory for Python config files: user data directory Usually the parent directory of the user site directory. It's meant for Python version specific data like config files, docs, images and translations. Unix (including Mac) ~/.local/lib/python2.6 Windows %APPDATA%/Python/Python26 Regards ___ 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] Proposed tweaks to functools.wraps
On Wed, 2010-08-11 at 13:10 +1000, Nick Coghlan wrote: On Wed, Aug 11, 2010 at 12:39 PM, Benjamin Peterson benja...@python.org wrote: which would require ignoring the absence of __annotations__. It turns out the patch that added __annotations__ support also made a change to make all of the copied attributes optional. The discussion happened on issue 8814. I initially made only __annotations__ optional, however, after finding issue 1576241 on the tracker and thinking about it a bit, making all of the annotations optional seemed like the only sane solution. http://bugs.python.org/issue8814 http://bugs.python.org/issue1576241 So I'll be tidying up the implementation of that, extending it to the updated attributes and adding unit tests to make sure they're all optional. Cheers, Nick. -- Terrence ___ 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] Proposed tweaks to functools.wraps
On Aug 11, 2010, at 3:28 PM, Benjamin Peterson wrote: 2010/8/11 Raymond Hettinger raymond.hettin...@gmail.com: On Aug 11, 2010, at 2:37 PM, Terry Reedy wrote: On 8/11/2010 3:16 PM, Raymond Hettinger wrote: The ability to introspect is basic to Python's design. Objects know their class, functions know their code objects, bound methods know both their underlying function, classes know their own class dictionary, etc. Should iterators know their iterable when there is one? There is or was a request for this on python-list, I believe, a few days ago. I suggested bad idea because a) iterator requirement is intentially minimal b) not all iterators have underlying object c) OP wanted to mutate underlying object (list) while iterating I did give a my_iter class that would do what OP wanted. I agree with your assessment. Also an iterator is a protocol, not a single class. As is decoration... This isn't proposed for decoration in general, just for wraps(). In that respect, it is very much like bound methods or other things that introspect. The length of the this thread is surprising. It is a rather basic piece of functionality with no real downside. 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] Proposed tweaks to functools.wraps
On 8/11/2010 5:37 PM, Terry Reedy wrote: On 8/11/2010 3:16 PM, Raymond Hettinger wrote: The ability to introspect is basic to Python's design. Objects know their class, functions know their code objects, bound methods know both their underlying function, classes know their own class dictionary, etc. Should iterators know their iterable when there is one? There is or was a request for this on python-list, I believe, a few days ago. I suggested bad idea because a) iterator requirement is intentially minimal b) not all iterators have underlying object c) OP wanted to mutate underlying object (list) while iterating I did give a my_iter class that would do what OP wanted. Mutation of the underlying iterable is a terrible idea. Imagine the confusion when multiple iterators are active on the same iterable. But I suspect I am preaching to the choir here. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ 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] Fixing #7175: a standard location for Python config files
I'd like to see a more complete proposal, including:
Fair enough.
tl;dr: Locating config files is hard.
I have looked at http://github.com/ActiveState/appdirs (MIT) for
OS-specific bits of knowledge. (Note that the directories it uses for
free OSes are not compliant with the freedesktop.org Base Directory
specification, which already did the reflexion and code to separate
config, user data and cache.)
- what to do with Windows,
appdirs uses pywin32 or ctypes or _winreg to find the correct value for
the user settings directory. There is a new complication in recent
Windows called roaming profiles, which are copied from a server to
multiple clients and need synchronization calls.
Mac OS X
There is debate between Ned Deily, Ronald Oussoren and Glyph Lefkowitz
as to whether Mac OS is just a Unix or a special beast. appdirs chooses
the Mac-specific directory. There are also probably variations between
system installations, framework things and unix-style installations.
- backward compatibility considered
(seems straightforward, but seemings are often wrong)
Are you talking about finding config from older locations, or automatic
renaming of ~/.idlerc to ~/.python/idlerc? The former seems easy; not
sure how to do the latter. Gajim, a PyGTK Jabber client, moved from a
custom layout to BaseDir-compliant directories a few months ago; I think
it looks for the old directories on every startup to see if they need to
be moved. I’m not sure if this affects startup time noticeably, since
it’s after all a graphical network Python app, but it may be a concern
with programs that are run a lot like the unittest2 script (or not,
considering startup time of the interpreter).
- cross-platform API to locate these files
I was thinking about adding a function to site with this tentative
signature:
def getuserconfig(appname=''):
Return the configuration file name for `appname`.
If `appname` is the empty string, return the directory used for
Python configuration files, else returns the file name used for the
configuration file of `appname` (a PyPI project name).
Strings starting with a number ('3.2') are reserved by Python.
I’m not sure the x.y subdirectory is necessary. distutils config files
are compatible since forever and will still be compatible with
distutils2; config files in unittest2 are very recent, they could have a
policy of compatiblity too; I can investigate IDLE config format.
A boolean could control whether to return filenames using the old
conventions. On Windows, this would need application name and
author/vendor name (settings are grouped by author). On Mac, the
application would have to say whether it uses a unix-style dotfile or a
Mac-style directory. Also, capitalization differs across OSes. Can of
worms here.
Seems like a good idea to have a registry of files known to be placed there
The project name registration on PyPI may be enough to avoid duplicates.
Next steps:
1) Find out if winreg is reliable enough, since we don’t want to depend
on ctypes or pywin32 IIRC.
2) Have the Mac people come to an agreement for each type of install.
3) Prototype the new function. It’s probably a good idea to contact the
author of appdirs and work with him on a Python-specific subset of his
module instead of rewriting the same code.
4) Think about the best way to handle b/w compat. Timings could help
deciding for or against automatic renaming.
Thanks for the feedback.
___
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] Fixing #7175: a standard location for Python config files
PEP 370 already specifies a directory for Python config files: user data directory Usually the parent directory of the user site directory. It's meant for Python version specific data like config files, docs, images and translations. Thanks for pointing that. However, I have to disagree with the PEP here: config files are not data files. Considering the FHS or the XDG Base Directory specifications, there is a precedent in distinguishing user config (edited by the user through a text editor or settings graphical window), program data (state) and cache (files for speedups that can safely be deleted). Regards ___ 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] Fixing #7175: a standard location for Python config files
On Wed, Aug 11, 2010 at 10:58 PM, Éric Araujo mer...@netwok.org wrote: Considering the FHS or the XDG Base Directory specifications, there is a precedent in distinguishing user config (edited by the user through a text editor or settings graphical window), program data (state) and cache (files for speedups that can safely be deleted). Right. The wording in that PEP is ambiguous at best, but the inclusion of the Python version number in the listed path suggests that this is for automatically managed stat (like those trashy *.pth files some tools worry about), not for something the human user is going to manipulate directly. That PEP is particularly concerned with package management per user (a dodgy proposition at best), so everything there is about package management tool support, not user-manipulated configuration data. -Fred -- Fred L. Drake, Jr. fdrake at gmail.com A storm broke loose in my mind. --Albert Einstein ___ 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] Fixing #7175: a standard location for Python config files
In article 4c62c01d.6000...@netwok.org, Ãric Araujo mer...@netwok.org wrote: Hello list Tarek opened a distutils bugs in http://bugs.python.org/issue7175 that evolved into a discussion about the proper location to use for config files. Distutils uses [.]pydistutils.cfg and .pypirc, and now unittest2 has a config file too. It would be nice to define one standard location for config files used by stdlib modules, and maybe also by third-party programs related closely to Python development (testing tools, static code checkers and the like), in a way that doesnât clutter the user home directory with a dozen dotfiles while still being easily found. (The Unix notions of dotfiles and home directory have to be adapted to use non-dotfiles in some standard place on various Windows. The Mac experts disagree on the right directory to use.) Tarek, Antoine, RDM, MAL were +1 on using ~/.python (whether to use .pythonx.y or .python/x.y is a subissue to discuss after general agreement). What do you think about this? I like the idea as long as different versions of python have different directories and the files are intended to be user-specific. If the files are shared among all users then /usr/local/something seems more reasonable. I also think whatever you choose for linux is also the best choice for Mac OS X (my preferred platform). While there are other possible directories, such as ~/Library/Application Support/something, all tools derived from unix that I know about use the unix convention (ssh, X11, bash...) and I would argue that Python is close enough to count even though it is a framework build. Put another way, copying the unix convention is simple, is exactly what power users would expect and I don't see it would do any harm. -- Russell ___ 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
