Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
Am 13.07.2010 00:48, schrieb Eric Smith: On 7/12/2010 6:04 PM, Michael Foord wrote: Given how high traffic python-checkins is I don't consider that a reasonable place to send follow-up and nor do I consider it the responsibility of committers to monitor it. As you said earlier this *isn't* in our standard dev procedures and nor do I think it should be. If you can't find an email address then either python-comitters or python-dev would be a better place to send feedback. Maybe reply-to on the checkin messages could be set to python-dev. Not sure if that's a mailman feature, though. Somebody correct me if I'm wrong: I think we had this, at one point, and then switched it to the status quo. I can surely try switching it back if desired. 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] New regex module for 3.2?
On Thu, Jul 8, 2010 at 12:52 PM, MRAB pyt...@mrabarnett.plus.com wrote: Hi all, I re-implemented the re module, adding new features and speed improvements. It's available at: http://pypi.python.org/pypi/regex under the name regex so that it can be tried alongside re. I'd be interested in any comments or feedback. How does it compare with re in terms of speed on real-world data? The benchmarks suggest it should be faster, or at worst comparable. How much interest would there be in putting it in Python 3.2? A big +1 from me. I'm all for putting it in Python 3.2 alphas and beta1 as a *replacement* for the existing 're' module in order to get it visibility and a shakeout and make this available to the world sooner rather than later. This module was designed for compatibility for exactly that reason. Lets give it a high publicity fair shake it iron out any unknown compatibility issues early on so that we can decide how to proceed. Also, +1 to Antoine's point on volunteering to be the maintainer of it for the next couple major releases. (I do expect someone to balk at this idea with but python 3.x doesn't have enough users yet for a beta cycle to shake out hidden regular expression engine assumption bugs to which I'll respond in advance with thats a good thing; we can add a regular expression sniffer to 2to3 that flags potential problems in code being ported over) -gps ___ 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] commit privs
On Sun, Jul 11, 2010 at 9:28 AM, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 11 Jul 2010 13:23:13 + Reid Kleckner reid.kleck...@gmail.com wrote: I'm also expecting to be doing more work merging unladen-swallow into the py3k-jit branch, so I was wondering if I could get commit privileges for that. It sounds good to me. Also, thanks for your threading patches! Regards +1 ___ 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] [Idle-dev] Removing IDLE from the standard library
On Tue, Jul 13, 2010 at 00:11, Martin v. Löwis mar...@v.loewis.de wrote: There's a one-to-one mapping somewhere. Unfortunately, no: we don't have email addresses of all committers. What about the python-committers mailing list? That has at least all the active ones, correct? Probably. Also, Dirkjan is maintaining a list for the Mercurial migration. Indeed: http://hg.python.org/pymigr/file/tip/author-map?style=raw I think I took email addresses from the public key list that Martin maintains for SVN etc and then augmented that with stuff from the mailing list archives and Google. The list is by no means guaranteed to be correct and fully up-to-date, but it's complete (save for maybe new committers from the last few weeks). Cheers, Dirkjan ___ 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] Intended behavior of backlash in raw strings
On Tue, Jul 13, 2010 at 12:26 AM, John Arbash Meinel john.arbash.mei...@gmail.com wrote: rtesting \ backslash and quote 'testing \\ backslash and quote' It happens that this is the behavior I want, but it seemed just as likely to be an error. I tested it with python2.5 and 2.6 and got the same results. The behaviour does appear to be explicitly documented in the language reference: When an 'r' or 'R' prefix is present, a character following a backslash is included in the string without change, and all backslashes are left in the string. For example, the string literal r\n consists of two characters: a backslash and a lowercase 'n'. String quotes can be escaped with a backslash, but the backslash remains in the string; for example, r\ is a valid string literal consisting of two characters: a backslash and a double quote; r\ is not a valid string literal (even a raw string cannot end in an odd number of backslashes). 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] Problem with executing python interpretetor on special build of win server 2003
Hello. Actual problem in the next, when i trying to execute portable python on my build then nothing happens, and the error code is 128. What does mean this code 128? ___ 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] More C API abstraction for user defined types
On Mon, Jul 12, 2010 at 10:19 PM, Nick Coghlan ncogh...@gmail.com wrote: On Tue, Jul 13, 2010 at 3:35 AM, Petre Galan petre.ga...@gmail.com wrote: ival should not be resolved through PyLong_AsLong, but through functionality/interface like PyNumber_Long +1, but I'd prefer it if PyNumber_Index were used, rather than PyNumber_Long. It shouldn't be possible to pass a Decimal instance to something expecting an integer argument. 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] Problem with executing python interpretetor on special build of win server 2003
Hello. We'are sorry but we cannot help you. This mailing list is to work on developing Python (fixing bugs and adding new features to Python itself); if you're having problems using Python, please find another forum. Probably python-list (comp.lang.python) news group/mailing list is the best place. See http://www.python.org/community/ for other lists/news groups/fora. Thank you for understanding. On Tue, Jul 13, 2010 at 03:20:02PM +0700, Бажен Ржеутский wrote: Hello. Actual problem in the next, when i trying to execute portable python on my build then nothing happens, and the error code is 128. What does mean this code 128? ___ 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/phd%40phd.pp.ru Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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] avoiding accidental shadowing of top-level libraries by the main module
On 13/07/2010 01:30, Steven D'Aprano wrote: On Tue, 13 Jul 2010 08:05:24 am Nick Coghlan wrote: On Tue, Jul 13, 2010 at 7:47 AM, Fred Drakefdr...@acm.org wrote: On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a different name it would solve these problems. Indeed! And I'd be quite content with such a solution, since I consider scripts and modules to be distinct. And here I've been busily blurring that distinction for years ;) (actually, the whole name == '__main__' idiom meant the distinction was already pretty blurry long before I got involved) I would hate it if that distinction was un-blurred. Most of my modules include a section if __name__ == '__main__': run_tests(), and some of them do significantly more than that. A few of them import themselves so they can pass the module object to another module. Reimporting yourself (and creating a second version of the module with new versions of all the classes / constants / functions / etc) doesn't seem like a good way of doing that though. If you need the module object you can always do: module = sys.modules[__name__] Michael Foord I take it the concrete proposal here is if the filename of a new module matches either __main__.__file__ or __main__.__cached__, then that module should be ignored completely for import purposes allowing a module with the same name later on sys.path to be found? I'm not sure I like that, I'd be more inclined to just return the __main__ module in that case rather than letting the search continue further down sys.path (although I agree the current semantics of getting two copies of the same module under different names in this case are less than ideal). Yes, that's a weird corner case. I don't see any advantage to keeping that behaviour. -- 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] Removing IDLE from the standard library
On Mon, 12 Jul 2010 19:08:07 -0400 Terry Reedy tjre...@udel.edu wrote: On 7/12/2010 2:05 AM, Martin v. Löwis wrote: What I specifically want right now is Commit Authorization Privilege, especially for IDLE, Not sure who could grant that, but as far as I can: you have it. If I were approved to commit patches directly, then by implication I should be able to approve others doing the same. That is occasionally done now by others, but I wanted to be clear that for the present, the latter is all I could and would do. There is no formal approval process. If you post a review of a patch saying the patch is ok and the patch submitter is also a committer, he can then commit it himself. There is no need for more bureaucracy, and you don't need commit access to do this. 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] New regex module for 3.2?
2010/7/8 MRAB pyt...@mrabarnett.plus.com: Hi all, I re-implemented the re module, adding new features and speed improvements. It's available at: http://pypi.python.org/pypi/regex under the name regex so that it can be tried alongside re. I'd be interested in any comments or feedback. How does it compare with re in terms of speed on real-world data? The benchmarks suggest it should be faster, or at worst comparable. How much interest would there be in putting it in Python 3.2? Hi, please, let me apologize for posting here, not being a python developer; I'd like to support the inclusion of the new regex library in the standard lib. I use it since the early development versions in my internal app for searching, modifying, ordering, extracting data from text - mainly using the manually created regex patterns. I see, that it is only one specific usecase, and the app isn't time or space critical (input texts up to a few MB, mostly smaller; the processing time is often rather negligible compared to the gui presentation, styling etc.) However, I see it as a great enhancement both in terms of regex features (listed on http://pypi.python.org/pypi/regex ) as well as the behaviour in some cornercases, which aren't effectively usable in the current re (e.g. nested subexpressions with quantifiers - while many of these are more effectively solved with the added possesive quantifiers). I think, this is a far more feature complete engine, which doesn't induce any significant drawbacks (IMO) comparing to the current re and is backward compatible. (The mentioned exception in the scoped flags might be fixable by allowing only explicit scoping (?flags)...(?-flags) or using the current paren, if possible (?flag:...) and treating the bare flag setting parens as global; however, I would consider it quite misleading in the current re, if these flags are set at some other place than at the beginning of the pattern. I don't see the readability enhanced in any way with these flags set at the end, while they should apply from the beginning of the pattern.) Having seen MRABs commitment in the development phase in both - bugfixes and feature additions - including some rather complex ones (in my opinion) like unicode properties, I am also confident, that he could be a competent maintainer of this package in the standardlib as well. just my biased opinion... Regards, Vlastimil Brom ___ 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
On Tue, Jul 13, 2010 at 11:05 AM, Stephen J. Turnbull step...@xemacs.org wrote: Antoine Pitrou writes: You don't have to receive e-mail from it. Just take a look at the archives from time to time after you have done some commits. In a threaded view, it's easy to spot the few messages which aren't commit notifications, since they are the only one not at the top-level. It also is possible to arrange that the author (From field) of the commit message is the author of the commit, rather than the bot. Reply-To could be set to bot plus author. Once the Mercurial transition is done, this would be more useful as everybody would have an email address as part of their committer ID. I was actually going to suggest something along those lines post transition, since Hg will have an email address for everyone - leave push notifications coming from the bot (so existing filters based on the bot address keep working), but include the push author in the reply-to field. Given its limited remaining lifespan, I don't see any point in messing with the current SVN setup though. 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] [Idle-dev] Removing IDLE from the standard library
On Sun, Jul 11, 2010 at 18:20, Tal Einat talei...@gmail.com wrote: The (hopefully) compelling arguments were others, such as the sentence following the one you quoted: I think that in its current state, IDLE may still be helpful for learning Python, but it is more likely to drive away users who run into its various quirks and problems. Having taught a few Python courses myself, I must say that while not perfect [I had to apologize for some IDLE issues, which shamed me into filing bugs/patches for some of them], it is *better* for interactive use than most other IDEs! That's IMHO the #1 is the real reason that makes it ideal for teaching, not the fact that it's bundled with Python. I wouldn't mind telling people install Python and X instead of install Python, but very few Python environments do multiline history correctly :-(. The only one I know that beats IDLE is Dreampie (designed by Noam Raphael, a long time IDLE contributor). However, without an editor and F5 it's not a winner for teaching. For the record, I'm -42 on removing IDLE from the distribution (unless you have a better replacement?), but +1 on widening commit access and setting up one obvious way for users to try bleeding-edge IDLE. -0 on extracting it from the stdlib (it's one way to implement the above, not sure if best way). But here's a thought: why not make IDLE an early adopter of Mercurial? It seems to me that could ease a lot of the issues: - contributors will be able to publish their changes without waiting for official commiters - contributors will be able to maintain beefed up IDLE branches with much less pain - trying out bleeding-edge branches would be much simpler - I expect a de-facto stable IDLE branch will emerge from the community -- Beni Cherniavsky-Paskin c...@users.sf.net ___ 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] How to block a module import
On Tue, Jul 13, 2010 at 10:37 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
In my experiments, 0 is not equivalent to None:
import sys, time
sys.modules['time'] = 0
__import__('time')
0
sys.modules['time'] = None
__import__('time')
Traceback (most recent call last):
File stdin, line 1, in module
ImportError: No module named time
Am I missing something?
I don't think so. I suspect I got away with this mistake because the
imports I was trying to block in the test suite were all C
acceleration imports of the form from module import *, and those
will blow up anyway since zero doesn't have __dict__ or __all__
attributes.
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] More C API abstraction for user defined types
On Tue, Jul 13, 2010 at 6:44 PM, Mark Dickinson dicki...@gmail.com wrote: On Mon, Jul 12, 2010 at 10:19 PM, Nick Coghlan ncogh...@gmail.com wrote: On Tue, Jul 13, 2010 at 3:35 AM, Petre Galan petre.ga...@gmail.com wrote: ival should not be resolved through PyLong_AsLong, but through functionality/interface like PyNumber_Long +1, but I'd prefer it if PyNumber_Index were used, rather than PyNumber_Long. It shouldn't be possible to pass a Decimal instance to something expecting an integer argument. Oops, I misread the suggestion. Indeed, PyNumber_Index is the correct API function for this purpose. 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] avoiding accidental shadowing of top-level libraries by the main module
(Two different classes with the same name created - one from __main__ and one from real_name.) Use cases for *genuinely* reimporting the same module with different names (as different module objects rather than aliases) are relatively rare, and the problem of modules *accidentally* reimporting themselves not that rare. That particular issue can be resolved by automatically doing the shadowing at the sys.module level though (i.e. insert into sys.modules under the real module name as well as __main__ for runpy._run_module_as_main and just strip the directory and extension details from __file__ to determine where to insert the second reference for a directly executed script file). Making sure both __main__ and the corresponding importable name refers to the same module object seems reasonable. Trying to special case shadowing detection just because the shadowing module happens to also be the main module seems ugly as hell :) 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] avoiding accidental shadowing of top-level libraries by the main module
On Tue, Jul 13, 2010 at 9:00 AM, Nick Coghlan ncogh...@gmail.com wrote: Making sure both __main__ and the corresponding importable name refers to the same module object seems reasonable. One detail that may not have been obvious when I described the persistent object problem; when class references are pickled, they should be for the real name of the module, not __main__. Loading the file as __main__ and adding an alias in sys.modules simply isn't sufficient. Existing instances could be loaded, but new instances would cause references to the classes defined in __main__. To some degree, this sort of problem can be easily handled using a don't do that approach, and this isn't likely to burn someone just learning Python on the first day. (Well, maybe in the afternoon, once they've got the basics down.) -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] commit privs
Thanks for the support! Georg Brandl authorized my SSH keys for SVN access. Reid On Tue, Jul 13, 2010 at 7:29 AM, Gregory P. Smith g...@krypto.org wrote: On Sun, Jul 11, 2010 at 9:28 AM, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 11 Jul 2010 13:23:13 + Reid Kleckner reid.kleck...@gmail.com wrote: I'm also expecting to be doing more work merging unladen-swallow into the py3k-jit branch, so I was wondering if I could get commit privileges for that. It sounds good to me. Also, thanks for your threading patches! Regards +1 ___ 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/reid.kleckner%40gmail.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] New regex module for 3.2?
On Mon, Jul 12, 2010 at 2:07 PM, Nick Coghlan ncogh...@gmail.com wrote: MRAB's module offers a superset of re's features rather than a subset though, so once it has had more of a chance to bake on PyPI it may be worth another look. I feel like the new module is designed to replace the current re module, and shouldn't need to spend time in PyPI. A faster regex library isn't going to motivate users to add external dependencies to their projects. Reid ___ 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 regex module for 3.2?
On 13/07/2010 15:17, Reid Kleckner wrote: On Mon, Jul 12, 2010 at 2:07 PM, Nick Coghlanncogh...@gmail.com wrote: MRAB's module offers a superset of re's features rather than a subset though, so once it has had more of a chance to bake on PyPI it may be worth another look. I feel like the new module is designed to replace the current re module, and shouldn't need to spend time in PyPI. A faster regex library isn't going to motivate users to add external dependencies to their projects. If the backwards compatibility issues can be addressed and MRAB is willing to remain as maintainer then the advantages seem well worth it to me. Michael Reid ___ 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/ ___ 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 regex module for 3.2?
On Tue, 13 Jul 2010 15:20:23 +0100 Michael Foord fuzzy...@voidspace.org.uk wrote: On 13/07/2010 15:17, Reid Kleckner wrote: On Mon, Jul 12, 2010 at 2:07 PM, Nick Coghlanncogh...@gmail.com wrote: MRAB's module offers a superset of re's features rather than a subset though, so once it has had more of a chance to bake on PyPI it may be worth another look. I feel like the new module is designed to replace the current re module, and shouldn't need to spend time in PyPI. A faster regex library isn't going to motivate users to add external dependencies to their projects. If the backwards compatibility issues can be addressed and MRAB is willing to remain as maintainer then the advantages seem well worth it to me. To me as well. The code needs a full review before integrating, though. 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
[Python-Dev] Peculiar import code in pickle.py
When pickle.py needs to import a module by name, it goes through a peculiar dance of __import__(module, level=0) mod = sys.modules[module] As far as I can tell, unless builtins.__import__ is overridden or sys.modules clobbered by user code, the above should be equivalent to mod = __import__(module, level=0) Note that the optimized _pickle implementation does not do the sys.modules lookup and simply uses the module returned by __import__(..). This code goes back to 1999, so there was probably a good reason back then to write it this way. Presently, however, it seems to be just another obscure difference between C and Python implementation of pickle. ___ 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] Peculiar import code in pickle.py
On Tue, 13 Jul 2010 11:25:23 -0400 Alexander Belopolsky alexander.belopol...@gmail.com wrote: When pickle.py needs to import a module by name, it goes through a peculiar dance of __import__(module, level=0) mod = sys.modules[module] As far as I can tell, unless builtins.__import__ is overridden or sys.modules clobbered by user code, the above should be equivalent to mod = __import__(module, level=0) Only for top-level modules: __import__(distutils.core, level=0) module 'distutils' from '/home/antoine/py3k/__svn__/Lib/distutils/__init__.py' sys.modules[distutils.core] module 'distutils.core' from '/home/antoine/py3k/__svn__/Lib/distutils/core.py' 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] Peculiar import code in pickle.py
On Tue, Jul 13, 2010 at 11:34 AM, Antoine Pitrou solip...@pitrou.net wrote: On Tue, 13 Jul 2010 11:25:23 -0400 .. Only for top-level modules: __import__(distutils.core, level=0) module 'distutils' from '/home/antoine/py3k/__svn__/Lib/distutils/__init__.py' sys.modules[distutils.core] module 'distutils.core' from '/home/antoine/py3k/__svn__/Lib/distutils/core.py' That's right, but I believe the recommended way to achieve that behavior is to supply a dummy fromlist: __import__(distutils.core, fromlist=[dummy], level=0) module 'distutils.core' from '/Users/sasha/Work/python-svn/py3k/Lib/distutils/core.py' That's what C implementation does AFAICT. ___ 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] Peculiar import code in pickle.py
On 13/07/2010 16:46, Alexander Belopolsky wrote: On Tue, Jul 13, 2010 at 11:34 AM, Antoine Pitrousolip...@pitrou.net wrote: On Tue, 13 Jul 2010 11:25:23 -0400 .. Only for top-level modules: __import__(distutils.core, level=0) module 'distutils' from '/home/antoine/py3k/__svn__/Lib/distutils/__init__.py' sys.modules[distutils.core] module 'distutils.core' from '/home/antoine/py3k/__svn__/Lib/distutils/core.py' That's right, but I believe the recommended way to achieve that behavior is to supply a dummy fromlist: __import__(distutils.core, fromlist=[dummy], level=0) module 'distutils.core' from '/Users/sasha/Work/python-svn/py3k/Lib/distutils/core.py' That's what C implementation does AFAICT. I find the little dance much more readable. All the best, Michael ___ 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] avoiding accidental shadowing of top-level libraries by the main module
On 13/07/2010 14:00, Nick Coghlan wrote: (Two different classes with the same name created - one from __main__ and one from real_name.) Use cases for *genuinely* reimporting the same module with different names (as different module objects rather than aliases) are relatively rare, and the problem of modules *accidentally* reimporting themselves not that rare. That particular issue can be resolved by automatically doing the shadowing at the sys.module level though (i.e. insert into sys.modules under the real module name as well as __main__ for runpy._run_module_as_main and just strip the directory and extension details from __file__ to determine where to insert the second reference for a directly executed script file). Sure - there are trivial workarounds which is why I don't think there are *many* genuine use cases for a module reimporting itself with a different name. Michael Making sure both __main__ and the corresponding importable name refers to the same module object seems reasonable. Trying to special case shadowing detection just because the shadowing module happens to also be the main module seems ugly as hell :) Cheers, Nick. -- 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] Removing IDLE from the standard library
On Sun, Jul 11, 2010 at 18:20, Tal Einat talei...@gmail.com wrote: The (hopefully) compelling arguments were others, such as the sentence following the one you quoted: I think that in its current state, IDLE may still be helpful for learning Python, but it is more likely to drive away users who run into its various quirks and problems. The underlying problem is that, given the way Python is currently maintained, there are only two options: 1) part of the main Python distribution and synchronized with it, and 2) supported (or not) by some third party who may or may not produce a working version in sync with what the Python distribution is doing. There's no intermediate tier, like Python extras, with a code base under common source control and some quality control. (PyPi is mostly a link farm to projects elsewhere, not a source repository.) IDLE belongs in such an intermediate tier. There are no dependencies on IDLE. Nothing will stop working because a version of IDLE isn't available. There are a reasonable number of modules not in the Python distribution that are more mission-critical to large numbers of users than IDLE. IDLE is useful, but not critical. Given limited resources, it's necessary to cut back in some areas. I'd vote IDLE off the island. John Nagle ___ 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] Peculiar import code in pickle.py
2010/7/13 Alexander Belopolsky alexander.belopol...@gmail.com: On Tue, Jul 13, 2010 at 11:34 AM, Antoine Pitrou solip...@pitrou.net wrote: On Tue, 13 Jul 2010 11:25:23 -0400 .. Only for top-level modules: __import__(distutils.core, level=0) module 'distutils' from '/home/antoine/py3k/__svn__/Lib/distutils/__init__.py' sys.modules[distutils.core] module 'distutils.core' from '/home/antoine/py3k/__svn__/Lib/distutils/core.py' That's right, but I believe the recommended way to achieve that behavior is to supply a dummy fromlist: __import__(distutils.core, fromlist=[dummy], level=0) module 'distutils.core' from '/Users/sasha/Work/python-svn/py3k/Lib/distutils/core.py' No! That's not recommended and a complete hack. The dance or importlib.import_module is preferred. -- 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] Peculiar import code in pickle.py
On Tue, Jul 13, 2010 at 1:57 PM, Benjamin Peterson benja...@python.org wrote: 2010/7/13 Alexander Belopolsky alexander.belopol...@gmail.com: On Tue, Jul 13, 2010 at 11:34 AM, Antoine Pitrou solip...@pitrou.net wrote: On Tue, 13 Jul 2010 11:25:23 -0400 .. Only for top-level modules: __import__(distutils.core, level=0) module 'distutils' from '/home/antoine/py3k/__svn__/Lib/distutils/__init__.py' sys.modules[distutils.core] module 'distutils.core' from '/home/antoine/py3k/__svn__/Lib/distutils/core.py' That's right, but I believe the recommended way to achieve that behavior is to supply a dummy fromlist: __import__(distutils.core, fromlist=[dummy], level=0) module 'distutils.core' from '/Users/sasha/Work/python-svn/py3k/Lib/distutils/core.py' No! That's not recommended and a complete hack. The dance or importlib.import_module is preferred. A complete hack with a long pedigree: module = __import__(modname, None, None, 'python2.4 is silly, revisit this line in 2.5') I think that line in a code base of mine didn't get altered until 2.6.something. Hack-ily, -Jack ___ 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] Peculiar import code in pickle.py
On Tue, Jul 13, 2010 at 1:57 PM, Benjamin Peterson benja...@python.org wrote:
..
No! That's not recommended and a complete hack. The dance or
importlib.import_module is preferred.
Nevertheless, a complete hack is what PyImport_Import does:
PyObject *
PyImport_Import(PyObject *module_name)
{
static PyObject *silly_list = NULL;
..
/* Call the __import__ function with the proper argument list
* Always use absolute import here. */
r = PyObject_CallFunction(import, i, module_name, globals,
globals, silly_list, 0, NULL);
..
}
and _pickle.c uses PyImport_Import() and thus is different form
pickle.py which uses the double-lookup dance. As a result, the two
implementations are subtly different. They cannot be both right. It
should be easy to fix _pickle.c to do the sys.modules lookup, but I
am not sure this is right.
___
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] Include datetime.py in stdlib or not?
On Thu, Jul 8, 2010 at 3:09 PM, Brett Cannon br...@python.org wrote: .. I can say that all the VM representatives have all said they like the idea. This is encouraging. Here is an update on the status of datetime.py. I believe it is mostly ready to move from sandbox to py3k/Lib. The patch is available on the tracker at http://bugs.python.org/file17978/issue9206b.diff and on Rietveld at http://codereview.appspot.com/1824041 . Unfortunately since many changes are just file renames will minor code modifications, neither the patch nor Rietveld give a good overview of the proposed commit. I will try to give this overview here: 1. Copy datetime.py from sandbox to py3k/Lib. (I need some help from an SVN expert on how to do that.) The diff between sandbox version and proposed commit is just --- ../py3k-datetime/datetime.py2010-07-07 20:12:56.0 -0400 +++ Lib/datetime.py 2010-07-08 21:15:52.0 -0400 @@ -1555,7 +1555,6 @@ @classmethod def strptime(cls, date_string, format): 'string, format - new datetime parsed from a string (like time.strptime()).' -import _strptime return _strptime._strptime_datetime(cls, date_string, format) def utcoffset(self): @@ -1874,6 +1873,13 @@ timezone.min = timezone(timezone._minoffset) timezone.max = timezone(timezone._maxoffset) +try: +from _datetime import * +except ImportError: +pass + +import _strptime + The from _datetime import * is the standard fast implementation override and import _strptime had to be moved from function level to module level after class definitions due to circular dependency of _strptime on datetime. The best place to review the entire datetime.py is on Rietveld at http://codereview.appspot.com/1824041/diff/1/4. I have only one remaining issue with this code - it leaves a number of private _xyz functions in the datetime module that are neither used nor overridden by the C implementation. In my view, this is not a big issue, but it can be dealt with by either moving module level functions to class namespace (making them static or class methods as appropriate) or by deleting them explicitly in the else clause of the try statement that imports the fast overrides. 2. Rename datetimemodule.c to _datetimemodule.c. The code changes are trivial: module name and the name of the init function. http://codereview.appspot.com/1824041/diff/1/7 3. Rename test_datetime.py to datetimetester.py. The testing strategy implements Nick Coghlan's idea of importing the test classes from a tester module with and without _datetime and injecting them into test_datetime namespace under different names. http://mail.python.org/pipermail/python-dev/2010-July/101598.html The changes required to the code are minimal: http://codereview.appspot.com/1824041/diff/1/5 . 4. Add new test_datetime.py that contains somewhat elaborate import machinery to create duplicates of each test case from datetimetester.py running with and without datetime acceleration. Unfortunately, test_datetime.py did not make it to Rietveld, but it is small enough to include here: import unittest import sys from test.support import import_fresh_module, run_unittest TESTS = 'test.datetimetester' pure_tests = import_fresh_module(TESTS, fresh=['datetime', '_strptime'], blocked=['_datetime']) fast_tests = import_fresh_module(TESTS, fresh=['datetime', '_datetime', '_strptime']) test_modules = [pure_tests, fast_tests] test_suffixes = [_Pure, _Fast] for module, suffix in zip(test_modules, test_suffixes): for name, cls in module.__dict__.items(): if isinstance(cls, type) and issubclass(cls, unittest.TestCase): name += suffix cls.__name__ = name globals()[name] = cls def setUp(self, module=module, setup=cls.setUp): self._save_sys_modules = sys.modules.copy() sys.modules[TESTS] = module sys.modules['datetime'] = module.datetime_module sys.modules['_strptime'] = module.datetime_module._strptime setup(self) def tearDown(self, teardown=cls.tearDown): teardown(self) sys.modules.__init__(self._save_sys_modules) cls.setUp = setUp cls.tearDown = tearDown def test_main(): run_unittest(__name__) if __name__ == __main__: test_main() Since this change does not introduce any new features, I think it is safe to commit it and make further improvements to datetime.py (if any) once it is in the main tree. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev
Re: [Python-Dev] python-checkins
I was actually going to suggest something along those lines post transition, since Hg will have an email address for everyone - leave push notifications coming from the bot (so existing filters based on the bot address keep working), but include the push author in the reply-to field. IIRC, you can’t know who pushed without kludgy hackery. Also, the one to push is not necessarily the author of the commit(s). If that was just a braino and you meant setting the committer as reply-to, it seems a good idea. Note that nothing in Mercurial forces you to have a parsable “Name email” user name, it’s just a good practice. Dirkjan’s mapping uses a dummy to...@python.org address for unknown IDs, which probably means the other tools he’s writing depend on an email address. That would need to be in the dev policy. 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] python-checkins
On Jul 13, 2010, at 09:56 PM, Éric Araujo wrote: Note that nothing in Mercurial forces you to have a parsable “Name email” user name, it’s just a good practice. Dirkjan’s mapping uses a dummy to...@python.org address for unknown IDs, which probably means the other tools he’s writing depend on an email address. That would need to be in the dev policy. Bazaar has a facility for digitally signing commits, which I always enable. While this is a local configuration, some projects I contribute to have merge hooks which check the digital signatures and refuse the push if the revisions are not signed with a known gpg key. Does Mercurial have a similar feature? If so, I would suggest that we enable that and require committers to use registered gpg keys to sign their commits. We'd always have a verifiable chain back to a responsible party, and committers would be responsible for any changes or patches they merge on behalf of others. IME the overhead is pretty trivial, but then I'm quite comfortable with gpg concepts and tools. -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
Re: [Python-Dev] python-checkins replies
On Mon, Jul 12, 2010 at 16:42, Michael Foord fuzzy...@voidspace.org.ukwrote: On 12/07/2010 23:48, Eric Smith wrote: On 7/12/2010 6:04 PM, Michael Foord wrote: Given how high traffic python-checkins is I don't consider that a reasonable place to send follow-up and nor do I consider it the responsibility of committers to monitor it. As you said earlier this *isn't* in our standard dev procedures and nor do I think it should be. If you can't find an email address then either python-comitters or python-dev would be a better place to send feedback. Maybe reply-to on the checkin messages could be set to python-dev. Not sure if that's a mailman feature, though. I think this would be a good idea. It would be nice to have on-topic traffic here. :-) Or python-committers since this is discussing code already checked in and thus is somewhat committer-specific. This also has the perk of being easier to spot (don't know about the rest of you but my python-committers filter makes those emails much more obvious than python-dev traffic). -Brett Michael Eric. ___ 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/brett%40python.org ___ 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] How to block a module import
On Tue, Jul 13, 2010 at 05:48, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Jul 13, 2010 at 10:37 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
In my experiments, 0 is not equivalent to None:
import sys, time
sys.modules['time'] = 0
__import__('time')
0
sys.modules['time'] = None
__import__('time')
Traceback (most recent call last):
File stdin, line 1, in module
ImportError: No module named time
Am I missing something?
I don't think so. I suspect I got away with this mistake because the
imports I was trying to block in the test suite were all C
acceleration imports of the form from module import *, and those
will blow up anyway since zero doesn't have __dict__ or __all__
attributes.
Nick's right; 0 fails on an import * to pull anything in of interest. And as
I said on python-checkins -- you can ignore that email, Alexander -- there
is a historical reason because in Python 2 if you tried an implicit relative
import a value of None met to do an absolute import. This doesn't have that
effect in py3k as explicit relative imports are the only way to do relative
imports (and luckily importlib does the proper thing for this as well =).
___
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
This is getting a little off-topic, but let me just respond to this... On Tue, Jul 13, 2010 at 22:10, Barry Warsaw ba...@python.org wrote: Does Mercurial have a similar feature? If so, I would suggest that we enable that and require committers to use registered gpg keys to sign their commits. We'd always have a verifiable chain back to a responsible party, and committers would be responsible for any changes or patches they merge on behalf of others. IME the overhead is pretty trivial, but then I'm quite comfortable with gpg concepts and tools. I wrote something on Stack Overflow about this today, which I reproduce here: - You could verify that whoever is pushing the cset is also the committer (by matching http or ssh authentication). This is somewhat limiting because it can be useful when people push other developer's changesets. - You could use the pgp extension (from hgext) to explicitly sign changesets after committing, but it's kind of a drag if you want to do it for every changeset. In Mercurial, we only do this for releases. - http://bitbucket.org/mg/commitsigs is another extension, which takes a different tack to signing (I believe it doesn't sign the commit metadata, only the file tree, which lets it sign before the commit is finished, meaning it doesn't take up an extra cset). - Mozilla uses a pushlog which just tracks who pushed what. This lets you look in the commit history on the server (but only there) to see who pushed what group of changesets, giving you a better paper trail than you normally get. This can also be provided by changegroup notifications, if you include the guy who did the push in the email (this is what Python will do once their conversion is done). Note that, if you're going to require that each cset is signed, each non-committer contributor also has to have this facility, which IMO raises the bar significantly. I think I added the pushing user to the commit mails to provide just this kind of paper trail. Given the tamper-proofness of the SHA1 changeset ID's (and yes, hg will move to some newer hash algorithm at some point before SHA1 becomes too easy to crack), I don't think signing each cset adds much value. Cheers, Dirkjan ___ 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] Peculiar import code in pickle.py
On Tue, Jul 13, 2010 at 11:34, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Jul 13, 2010 at 1:57 PM, Benjamin Peterson benja...@python.org
wrote:
..
No! That's not recommended and a complete hack. The dance or
importlib.import_module is preferred.
Nevertheless, a complete hack is what PyImport_Import does:
PyObject *
PyImport_Import(PyObject *module_name)
{
static PyObject *silly_list = NULL;
..
/* Call the __import__ function with the proper argument list
* Always use absolute import here. */
r = PyObject_CallFunction(import, i, module_name, globals,
globals, silly_list, 0, NULL);
..
}
and _pickle.c uses PyImport_Import() and thus is different form
pickle.py which uses the double-lookup dance. As a result, the two
implementations are subtly different. They cannot be both right. It
should be easy to fix _pickle.c to do the sys.modules lookup, but I
am not sure this is right.
Pulling from sys.modules is the correct way to do this. There are subtle
issues when using a bunk fromlist argument (empty modules, double
initialization, etc.). If one does not use importlib.import_module --
written *specifically* to prevent people from doing the nasty hack with the
fromlist -- then you should use the sys.modules approach, period. If
import.c is not doing this then it should get fixed. You can assign me the
issue if you want.
I say this every time I give an import talk and it has been brought up here
before but obviously not everyone catches it (which is understandable as I
think when it came up on python-dev it was at the tail end of a discussion),
so I am just going to repeat myself:
Do not put junk in fromlist if you call __import__ directly! Use
importlib.import_module! Or if you have a *really* good reason to not use
it, then use ``__import__(name); module = sys.modules[name]``.
I have stopped fixing bugs related to this in import.c because of the
annoying issues it causes and I expect the correct approach to gain traction
at some point (plus get importlib bootstrapped in so I don't have to care
about import.c anymore).
___
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] How to block a module import
On Tue, Jul 13, 2010 at 4:34 PM, Brett Cannon br...@python.org wrote: .. Nick's right; 0 fails on an import * to pull anything in of interest. but if the imported module has try: import blocked_module except ImportError: do_something_important() then import_fresh_module() will create a broken module with do_something_important() not executed. And as I said on python-checkins -- you can ignore that email, Alexander Too late. I already replied. :-) -- there is a historical reason because in Python 2 if you tried an implicit relative import a value of None met to do an absolute import. This doesn't have that effect in py3k as explicit relative imports are the only way to do relative imports (and luckily importlib does the proper thing for this as well =). Is there a problem with this change for 3.x? ___ 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] avoiding accidental shadowing of top-level libraries by the main module
On Wed, Jul 14, 2010 at 2:25 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: Sure - there are trivial workarounds which is why I don't think there are *many* genuine use cases for a module reimporting itself with a different name. My concerns aren't about a module reimporting itself directly, they're about the case where a utility module is invoked as __main__ but is also imported normally somewhere else in a program (e.g. pdb is invoked as a top-level debugger, but is also imported directly for some reason). Currently that works as a non-circular import and will only cause hassles if there is top-level state in the affected module that absolutely must be a singleton within a given application. Either change (disallowing it completely as you suggest, or making it a circular import, as I suggest) runs the risk of breaking code that currently appears to work correctly. Fred's point about the practice of changing __name__ in the main module corrupting generated pickles is one I hadn't thought of before though. 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] How to block a module import
Nick's right; 0 fails on an import * to pull anything in of interest. And as I said on python-checkins -- you can ignore that email, Alexander -- there is a historical reason because in Python 2 if you tried an implicit relative import a value of None met to do an absolute import. This doesn't have that effect in py3k as explicit relative imports are the only way to do relative imports (and luckily importlib does the proper thing for this as well =). Ah, thank you - I knew we had a reason for doing it that way, I just couldn't remember what it was :) @Alexander: yes, it should be changed to None for 2.7, 3.1 and 3.2, since none of those allow implicit relative imports. 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] [Idle-dev] Removing IDLE from the standard library; Scherer Agreement
Hi Bruce: Please click on the link below to find the contributor agreement form along with instructions on how to send it. http://www.python.org/psf/contrib/ If you have any questions, please let me know. Thanks, Pat Campbell PSF Secretary Administrator On Mon, Jul 12, 2010 at 9:34 PM, Kurt B. Kaiser k...@shore.net wrote: On Mon, Jul 12 2010, Bruce Sherwood wrote: I don't recall that VIDLE has anything to do with running multiple IDLE copies. Well, I stole the ephemeral port idea from him! What's in VIDLE is a lot of bug fixes and some improvements. For example, you can configure it to not require having to save a file, which makes it as easy to use for quick testing as the shell. Another improvement, of high importance for our physics students and other novice programmers, is to bring an error display forward. Many students fill the screen with the edit window and the error message could be hidden, leaving them puzzled as to why their program wasn't running. Stuff like that, all aimed at issues we had seen with a large population of science and engineering students. I'll say again that IDLE/VIDLE is an excellent environment for novices. Issues identified here about look and feel etc. have just not been of any importance in that context. I'd like to get all that incorporated so you can go back to dealing directly with us. Your students are the people we want to reach! If you'll send me what you want from Scherer, I can contact him. I'm copying our PSF Secretary/Administrator, Pat Campbell. She can work with you to get David Scherer's Contributor Agreement. We really appreciate your assistance with this, he's one of the last missing agreements. -- KBK -- Pat Campbell PSF Administrator/Secretary pat...@python.org ___ 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] Peculiar import code in pickle.py
On Tue, Jul 13, 2010 at 4:52 PM, Brett Cannon br...@python.org wrote: .. Pulling from sys.modules is the correct way to do this. There are subtle issues when using a bunk fromlist argument (empty modules, double initialization, etc.). If one does not use importlib.import_module -- written *specifically* to prevent people from doing the nasty hack with the fromlist -- then you should use the sys.modules approach, period. If import.c is not doing this then it should get fixed. You can assign me the issue if you want. Please see http://bugs.python.org/issue9252 . ___ 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] Issue 2986: difflib.SequenceMatcher is partly broken
[Tim] ... BTW, it's not clear whether ratio() computes a _useful_ value in the presence of junk, however that may be defined. [Terry Reedy] I agree, which is one reason why one should be to disable auto-junking. Yup. There are a number of statistical methods for analyzing similarity matrices, analogous to correlation matrices, except that entries are in [0.0,1.0] rather than [-1.0,1.0]. For my Ph.D. thesis, I did such analyses for sets of species. Similarity measures should ususally be symmetric and increase with greater matching. The heuristic can cause both to fail. Two things about that. First, ratio() is here _defined_ to be (when comparing sequence a and b): 2.0 * number_of_matches / (len(a) + len(b)) The denominator is not affected by any junk heuristics, so this ratio does indeed increase directly with greater matching. But I don't know exactly what you mean by greater matching - I get the impression you think that's an inherent property of the sequences, but, as before, I don't see any meaning for it independent of the specific matching algorithm used. The current implementation of quick_ratio() may be closer to what you seem to be thinking. That views both sequences as multisets, and considers number_of_matches to be the cardinality of their intersection. That measure ignores the possibility of junk, and also ignores the order in which elements appear - it's wholly independent of the matching algorithm. But it returns 1.0 when the second sequence is any permutation of the elements in the first sequence, so throws away any notion of ordering. Second, it's common as mud for ratio() to give a different result depending on the order of SequenceMatcher's arguments, junk or no junk. This is mostly because it's a good thing for SequenceMatcher to run in finite time ;-) It's not just comparing sequences in the abstract, it's doing so in the context of producing a one-pass left to right edit sequence transforming the first sequence into the second, using only insert and delete operations. If the longest matching block between sequences X and Y is M, X and Y are effectively split into: X = A + M + B Y = C + M + D and then the same process is recursively applied to the pairs (A, C) and (B, D). If, for example, there are many matches between blocks A and D, they'll never be seen - a one-pass edit sequence restricted to insert and delete has to view M as a wall, transforming A into C entirely before it can skip over the matching M and start thinking about how to transform B into D. For that reason, when there are multiple maximal matching blocks, exactly which one is picked to be M can have percolating effects on how many additional matches are found _later_ (BTW, it's also a reason for why a notion of junk can improve the subjective _quality_ of results as judged by humans: if M is composed of things all of which look interesting to people, people tend to think the match is intuitive). The method find_longest_match() uses to pick a winner is documented: Return (i,j,k) such that a[i:i+k] is equal to b[j:j+k], where alo = i = i+k = ahi blo = j = j+k = bhi and for all (i',j',k') meeting those conditions, k = k' i = i' and if i == i', j = j' In other words, of all maximal matching blocks, return one that starts earliest in a, and of all those maximal matching blocks that start earliest in a, return the one that starts earliest in b. This has consequences. Here's a tiny example: X = abbb Y = bbab All maximal matching blocks between X and Y have length 2. bb appears twice in X and once in Y. ab appears once in each. Pass X first, and M=ab is picked as the winner. That breaks the sequences into: X = + ab + bb Y = bb + ab + and no further matches are found between and bb, or between bb and . ratio() thus returns 0.5. But pass Y first, and M=bb is picked as the winner, breaking the sequences into: X = a + bb + b Y = + bb + ab and an _additional_ match (on b) is later found when comparing the suffixes (b and ab). ratio() thus returns 0.75 in that case. I can conceive of trying all possible winners (and so on recursively), and then backtracking to pick a winner at each branch that maximizes the total number of matches - but it's a good thing for SequenceMatcher to run in finite time ;-) There are multiple possible definitions of similarity for sets (and arguments thereabout). I am sure the same is true for sequences. But I consider the definition for .ratio, without the heuristic, to be sensible. I would consider using it should the occasion arise. If you ever used difflib's file-comparison functions, they used ratio() extensively under the covers. The most interesting case when producing diffs for human consumption is when two blocks have _no_ matching lines in common. difflib's file comparators look for the two most similar lines (highest ratio()) in that case,
Re: [Python-Dev] notifications form Hg to python-checkins
On Wed, Jul 14, 2010 at 5:56 AM, Éric Araujo mer...@netwok.org wrote: I was actually going to suggest something along those lines post transition, since Hg will have an email address for everyone - leave push notifications coming from the bot (so existing filters based on the bot address keep working), but include the push author in the reply-to field. IIRC, you can’t know who pushed without kludgy hackery. Also, the one to push is not necessarily the author of the commit(s). If that was just a braino and you meant setting the committer as reply-to, it seems a good idea. No, I meant push. There's a separate discussion where it was pointed out that publishing each commit as a separate email makes python-checkins even chattier than it is already (this point came up after Tarek pushed a distutils2 changeset containing ~100 separate commits), so the suggestion was made to combine all commit notifications for a given push into a single email. However, I don't remember if that idea was suggested specifically to Dirkjan as a change to the notification email. If not, I'm suggesting it now :) Note that the current distutils2 emails to python-checkins already say Tarek Ziade pushed... and then include the committer details inside the email, and that's what we want - the developer pushing the change into the central repository is always going to be one of the core devs, but the original creator of the change set could have been anyone. 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] avoiding accidental shadowing of top-level libraries by the main module
On Tue, Jul 13, 2010 at 5:02 PM, Nick Coghlan ncogh...@gmail.com wrote: Fred's point about the practice of changing __name__ in the main module corrupting generated pickles is one I hadn't thought of before though. Not sure about changing __name__ anywhere... I don't do that. When an application is defined more by operations on persistent data then what top-level script is run, we (Zope Corp.) often have many different __main__s that run with the same database; there's generally not any point in thinking of the script as a module at all; the fact that it's available as sys.modules['__main__'] isn't important. We generally avoid the problem by applying the don't-do-that rule. Our actual scripts are always generated, and don't live in module-space. Understanding what not to do is an important aspect of teaching, though. -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] avoiding accidental shadowing of top-level libraries by the main module
On Jul 13, 2010, at 5:02 PM, Nick Coghlan wrote: My concerns aren't about a module reimporting itself directly, they're about the case where a utility module is invoked as __main__ but is also imported normally somewhere else in a program (e.g. pdb is invoked as a top-level debugger, but is also imported directly for some reason). Currently that works as a non-circular import and will only cause hassles if there is top-level state in the affected module that absolutely must be a singleton within a given application. Either change (disallowing it completely as you suggest, or making it a circular import, as I suggest) runs the risk of breaking code that currently appears to work correctly. Fred's point about the practice of changing __name__ in the main module corrupting generated pickles is one I hadn't thought of before though. It's not just pickle; anything that requires __name__ (or __module__) to be accurate for introspection or debugging is also problematic. I have long considered it a 'best practice' (ugh, I hate that phrase, but I can't think of what else to call it) to _always_ do this type of shadowing, and avoid defining _any_ names in the __name__ == '__main__' case, so that there's no ambiguity: http://glyf.livejournal.com/60326.html ___ 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] notifications form Hg to python-checkins
On Tue, Jul 13, 2010 at 23:22, Nick Coghlan ncogh...@gmail.com wrote: No, I meant push. There's a separate discussion where it was pointed out that publishing each commit as a separate email makes python-checkins even chattier than it is already (this point came up after Tarek pushed a distutils2 changeset containing ~100 separate commits), so the suggestion was made to combine all commit notifications for a given push into a single email. However, I don't remember if that idea was suggested specifically to Dirkjan as a change to the notification email. If not, I'm suggesting it now :) As I recall, that's what I first implemented, but it was shot down by some of the committers... anyway, I'd be happy to change it back. Cheers, Dirkjan ___ 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] avoiding accidental shadowing of top-level libraries by the main module
On Wed, Jul 14, 2010 at 7:34 AM, Fred Drake fdr...@acm.org wrote: On Tue, Jul 13, 2010 at 5:02 PM, Nick Coghlan ncogh...@gmail.com wrote: Fred's point about the practice of changing __name__ in the main module corrupting generated pickles is one I hadn't thought of before though. Not sure about changing __name__ anywhere... I don't do that. The interpreter does though (when it sets it to __main__ instead of what it would have been if the module had been imported rather than executed). That fact is convincing me that we should leave this alone for now. A module imported as __main__ and a module imported under it's real name are *different*, and this is reflected in pickles they generate and anything else that remembers the values of __name__. Obscuring that by treating them as equivalent in some contexts (such as name shadowing) while they remain different in other significant ways is unlikely to help overall. I must say, this whole discussion is actually making me far more sympathetic to the ideas behind PEP 299 (which proposed __main__ functions as a replacement for __name__ == __main__ blocks). Brett's rejected PEP 3122 and my own accepted PEP 366 were both a direct result of the interpreter lying about the real value of __name__. I don't have a particular good way forward though, and the one thing I can say about the status quo is that at least everyone is accustomed to having to work around it. And back to the topic of inadvertent shadowing when teaching new users: PEP 3147 should actually help in that regard, as the interpreter will now ignore any implicitly created .pyc files if the corresponding .py file has been removed. Only explicitly created .pyc files that live where the source file would have been can completely substitute for a missing source file now. 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] notifications form Hg to python-checkins
On Wed, Jul 14, 2010 at 7:45 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote: On Tue, Jul 13, 2010 at 23:22, Nick Coghlan ncogh...@gmail.com wrote: No, I meant push. There's a separate discussion where it was pointed out that publishing each commit as a separate email makes python-checkins even chattier than it is already (this point came up after Tarek pushed a distutils2 changeset containing ~100 separate commits), so the suggestion was made to combine all commit notifications for a given push into a single email. However, I don't remember if that idea was suggested specifically to Dirkjan as a change to the notification email. If not, I'm suggesting it now :) As I recall, that's what I first implemented, but it was shot down by some of the committers... anyway, I'd be happy to change it back. Having seen the per-commit approach in action, I'd personally like it changed back to per-push notifications, but you may want to start a thread on python-committers about it (given the number of tangents it has spawned, I wouldn't be surprised if a lot of people have stopped following this discussion by now). My rationale is as follows: - for small changesets with only one or two changes, per-push or per-commit emails don't make much difference - for large changesets, per-commit can be very noisy (as Tarek's 100+ notifications showed) while per-push stays the same I seem to have a vague recollection of the discussion you mention - do you remember if the specific objection was to a lack of a list of filenames affected in the subject line for the old per-push emails? Listing all the files affected by the push in the subject line would definitely still be desirable. 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] Issue 2986: difflib.SequenceMatcher is partly broken
Summary: adding an autojunk heuristic to difflib without also adding a way to turn it off was a bug because it disabled running code. 2.6 and 3.1 each have, most likely, one final version each. Don't fix for these but add something to the docs explaining the problem and future fix. 2.7 will have several more versions over several years and will be used by newcomers who might encounter the problem but not know to diagnose it and patch a private copy of the module. So it should have a fix. Solutions thought of so far. 1. Modify the heuristic to somewhat fix the problem. Bad (unacceptable) because this would silently change behavior and could break tests. 2. Add a parameter that defaults to using the heuristic but allows turning it off. Perhaps better, but code that used the new API would crash if run on 2.7.0 3. Tim Peters Think the most pressing thing is to give people a way to turn the damn thing off. An ugly way would be to trigger on an unlikely input-output behavior of the existing isjunk argument. For example, if isjunk(what's the airspeed velocity of an unladen swallow?) returned don't use auto junk! and 2.7.1 recognized that as meaning don't use auto junk, code could be written under 2.7.1 that didn't blow up under 2.7. It could _behave_ differently, although that's true of any way of disabling the auto-junk heuristics. Ugly, but perhaps crazy brilliant. Use of such a hack would obviously be temporary. Perhaps its use could be made to issue a -3 warning if such were enabled. I would simplify the suggestion to something like isjunk(disable!heuristic) == True so one could pass lambda s:s==disable!heuristic It should be something easy to document and write. This issue is the only place such a string should appear, so it should be safe. Tim and Antoine: if you two can agree on what to do for 2.7, Eli and I will code it. This suggestion amounts to a suggestion that the fix for 2.7 be decoupled from a better fix for 3.2. I agree. The latter can be discussed once 2.7 is settled. [copied to the tracker] -- 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
