Re: [Python-Dev] avoiding accidental shadowing of top-level libraries by the main module

On 12/07/2010 22:59, Antoine Pitrou wrote: On Mon, 12 Jul 2010 17:47:31 -0400 Fred Drake wrote: On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord wrote: I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a diff

Re: [Python-Dev] avoiding accidental shadowing of top-level libraries by the main module

On 12/07/2010 23:23, Nick Coghlan wrote: On Tue, Jul 13, 2010 at 8:06 AM, Michael Foord wrote: An explicit error being raised instead would be just as good. Ah, refusing the temptation to guess. So the idea would be, when attempting to import __main__ under it's original name

Re: [Python-Dev] Removing IDLE from the standard library

On 12/07/2010 23:00, Terry Reedy wrote: On 7/12/2010 5:43 PM, "Martin v. Löwis" wrote: Am 12.07.2010 23:21, schrieb Terry Reedy: On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote: On Windows, IDLE opens when you right click / edit a .py. Very useful. On my xp machine with 3.1.2, it edit .py opens

Re: [Python-Dev] python-checkins replies

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'

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 Drake wrote: On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord wrote: I'm sure Brett will love this idea, but if it was imp

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 Coghlan 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

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 Pitrou wrote: On Tue, 13 Jul 2010 11:25:23 -0400 .. Only for top-level modules: __import__("distutils.core", level=0) sys.modules["distutils.core"]

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

Re: [Python-Dev] more details of list comprehension in tutorial than in language reference

ke to write an addition and post it to the Python bug tracker it would be (very) welcomed for consideration. The tutorial has no single "maintainer" but we are always looking to improve it. All the best, Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.or

Re: [Python-Dev] IDLE contributors and committers

l (and other interested parties) as a developer makes a lot of sense. Guilherme's *existing* patch for IDLE looks like it improves it a great deal, at the cost of potentially requiring Tk 8.5 (?). Can this just be committed? https://code.google.com/p/python-ttk/wiki/Scre

Re: [Python-Dev] Markup of command-line options in Python's .rst documentation

On 17/07/2010 14:23, Eli Bendersky wrote: Hello, I'm currently working, together with Terry Reedy, on improving the documentation of the trace module, and I ran into a peculiar convention of marking command-line options which seems to be widespread. Consider the documentation of timeit, for

Re: [Python-Dev] Windows process creation flags

ipatrol6...@yahoo.com Could you create an issue on the Python bug tracker for this, preferably with a patch. Thanks Michael Foord ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http

Re: [Python-Dev] mkdir -p in python

the python bug tracker, preferably with patch and tests of course! It would be worth searching to see if there is an existing feature request for this, and if so you can add a comment to it. All the best, Michael Foord -- http://www.ironpythoninaction.com/ ___

Re: [Python-Dev] Markup of command-line options in Python's .rst documentation

On 17/07/2010 14:44, Eli Bendersky wrote: On Sat, Jul 17, 2010 at 16:26, Michael Foord mailto:fuzzy...@voidspace.org.uk>> wrote: On 17/07/2010 14:23, Eli Bendersky wrote: Hello, I'm currently working, together with Terry Reedy, on improving the documentation o

Re: [Python-Dev] mkdir -p in python

On 20/07/2010 14:43, Nick Coghlan wrote: On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Aprano wrote: I'm -0 on adding an argument to os.makedirs, +0 on adding a variant function to os, and +0.5 on adding the variant to the shutil module. shutil seems like the place for it to me. The sub

Re: [Python-Dev] Python profiler and other tools

://codespeak.net/svn/user/antocuni/hack/pdb.py Among its improvements it includes the ability to debug through generator frames, which pdb can't. It would be great to see some of these fixes folded back into the standard library version. All the best, Michael

Re: [Python-Dev] Thoughts fresh after EuroPython

On 26/07/2010 04:42, Guido van Rossum wrote: On Sun, Jul 25, 2010 at 8:31 PM, Peter Portante wrote: FWIW: We use Python at Tabblo, straddled across Python 2.5.4 and 2.6.5. They work. And they work well. But we make light use of threads (mostly background I/O handling), and heavy use of mul

Re: [Python-Dev] Thoughts fresh after EuroPython

On 26/07/2010 04:42, Guido van Rossum wrote: On Sun, Jul 25, 2010 at 8:31 PM, Peter Portante wrote: FWIW: We use Python at Tabblo, straddled across Python 2.5.4 and 2.6.5. They work. And they work well. But we make light use of threads (mostly background I/O handling), and heavy use of mul

Re: [Python-Dev] mkdir -p in python

On 28/07/2010 11:53, Greg Ewing wrote: Hrvoje Niksic wrote: mktree would only create a single "branch", not an entire tree. Maybe mkbranch, then? Seeing as we already have a decision to add this functionality to os.makedirs as a switch and not to create a new function, this bikeshedding see

Re: [Python-Dev] GIL musings (was Re: Thoughts fresh after EuroPython)

On 28/07/2010 11:50, Nick Coghlan wrote: On Tue, Jul 27, 2010 at 12:33 AM, Ronald Oussoren wrote: In my opinion the GIL is a weak point of CPython and it would be nice if it could be fixed. That is however easier said than done, a number of people have tried in the past and ran into imple

Re: [Python-Dev] Compiling Free Cad on Rhel5

On 28/07/2010 12:21, Vikas Mahajan wrote: Hello to all..Today I was trying to install FreeCAD 0.10 from its source code. I am using RHEL5. I have firstly installed python2.6.5 from source and also tested it. Python is working fine. But when I try to compile FreeCAD 0.10, I got following con

Re: [Python-Dev] GIL musings (was Re: Thoughts fresh after EuroPython)

On 28/07/2010 12:43, Ronald Oussoren wrote: On 28 Jul, 2010,at 12:56 PM, Michael Foord wrote: On 28/07/2010 11:50, Nick Coghlan wrote: > On Tue, Jul 27, 2010 at 12:33 AM, Ronald Oussoren > wrote: > >> In my opinion the GIL is a weak point of CPython and it would be nice

Re: [Python-Dev] Thoughts fresh after EuroPython

On 28/07/2010 22:20, Benjamin Peterson wrote: 2010/7/25 Stefan Behnel: Nick Coghlan, 25.07.2010 08:29: We knew PEP 380 would be hurt by the moratorium when the moratorium PEP went through. The goals of the moratorium itself, in making it possible to have a 3.2 release that is fully s

Re: [Python-Dev] Thoughts fresh after EuroPython

On 28/07/2010 23:57, Jesse Noller wrote: On Wed, Jul 28, 2010 at 5:20 PM, Benjamin Peterson wrote: 2010/7/25 Stefan Behnel: Nick Coghlan, 25.07.2010 08:29: We knew PEP 380 would be hurt by the moratorium when the moratorium PEP went through. The goals of the moratorium itse

Re: [Python-Dev] unexpected import behaviour

behaviour (not a bug), but it frequently confuses even relatively experienced programmers (it can happen by accident and cause hard to track down bugs) and I personally think that Python would be improved by issuing a warning if a __main__ script reimports itself. All the best, Michael Foord

Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2

On 29/07/2010 19:47, Mark Dickinson wrote: Now that we've got the short float repr in Python, there's less value in having float.__str__ truncate to 12 significant digits (as it currently does). For Python 3.2, I propose making float.__str__ use the same algorithm as float.__repr__ for its outpu

Re: [Python-Dev] Proposal: make float.__str__ identical tofloat__repr__ in Python 3.2

ame floating point number. Mark did an excellent presentation on this at EuroPython and the slides are online: http://www.slideshare.net/dickinsm/magical-float-repr Michael Foord Robert Brewer fuman...@aminus.org ___ Python-Dev mailing list Python-Dev@p

[Python-Dev] proto-pep: plugin proposal (for unittest)

Hello all, My apologies in advance if email mangles whitespace in the code examples. I can reformulate as a PEP if that is deemed useful and this document can be found online at: http://hg.python.org/unittest2/file/tip/description.txt (Please excuse errors and omissions - but do feel fre

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

ists.idyll.org/pipermail/testing-in-python/2010-March/002799.html On 29/07/2010 23:55, Michael Foord wrote: Hello all, My apologies in advance if email mangles whitespace in the code examples. I can reformulate as a PEP if that is deemed useful and this document can be found online at: http

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 30/07/2010 11:09, Tarek Ziadé wrote: On Fri, Jul 30, 2010 at 12:55 AM, Michael Foord wrote: ... The Plugin Class A sometimes-more-convenient way of creating plugins is to subclass the ``unittest2.events.Plugin`` class. By default subclassing ``Plugin`` will auto

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

23:55, Michael Foord wrote: > Hello all, > > My apologies in advance if email mangles whitespace in the code examples. I > can reformulate as a PEP if that is deemed useful and this document can be > found online at: > >http://hg.python.org/unittest2/file/tip/description.txt

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 30/07/2010 15:04, Barry Warsaw wrote: On Jul 30, 2010, at 11:38 AM, Michael Foord wrote: I'm going to read your blog entry on the topic to evaluate it properly though: https://tarekziade.wordpress.com/2009/05/01/basic-plugin-system-using-abcs- and-the-extensions-package/

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 30/07/2010 15:37, Tarek Ziadé wrote: On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw wrote: .. * Registration - How do third party plugins declare themselves to exist, and be enabled? Part of this seems to me to include interface declarations too. Is installation of the plugin enough

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 30/07/2010 15:41, Marty Alchin wrote: This is my first post to python-dev, so for those who might not know me, I'm the author of Pro Django and more recently, Pro Python. I haven't looked at the plugin landscape in a while, but I was very disappointed the last time I looked at how complex typ

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 30/07/2010 16:28, Éric Araujo wrote: Le 30/07/2010 17:04, Michael Foord a écrit : There is no type checking or interface requirements in my plugin proposal for unittest. It is essentially an event based system. Event-based sounds good. unittest2 does have an interface IMO

Re: [Python-Dev] unexpected import behaviour

On 30/07/2010 17:59, Oleg Broytman wrote: On Fri, Jul 30, 2010 at 07:26:26AM +0100, Daniel Waterworth wrote: @Oleg: ... This is purely CPython bug-fixing/the discussion of implementation choices. I am not sure it's a bug. It isn't a bug but it's a very common *cause* of bugs, ev

Re: [Python-Dev] Is it intentional that "sys.__debug__ = 1" is illegal in Python 2.7?

On 30/07/2010 21:53, Barry Warsaw wrote: On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote: Well it is a reserved name so those packages that were setting it should have known that they were using undefined behavior that could change at any time. Shouldn't it be described here the

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 30/07/2010 21:56, P.J. Eby wrote: At 03:34 PM 7/30/2010 +0100, Michael Foord wrote: Automatic discoverability, a-la setuptools entry points, is not without its problems though. Tarek outlines some of these in a more recent blog post: FWIW, it's not discovery that's the pr

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 31/07/2010 01:51, David Cournapeau wrote: On Fri, Jul 30, 2010 at 10:23 PM, Michael Foord wrote: For those of you who found this document perhaps just a little bit too long, I've written up a *much* shorter intro to the plugin system (including how to get the prototype) on my

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 31/07/2010 12:46, Michael Foord wrote: [snip...] If PEP 376 goes ahead then we could keep the user plugin I meant "keep the user config file". Michael and use the PEP 376 metadata, in concert with a user config file, to discover all plugins *available*. A plugins subcommand

Re: [Python-Dev] unexpected import behaviour

On 31/07/2010 16:07, Nick Coghlan wrote: On Sat, Jul 31, 2010 at 3:57 PM, Daniel Waterworth wrote: @Nick: I suppose the simplest way to detect re-importation in the general case, is to store a set of hashes of files that have been imported. When a user tries to import a file where it's has

Re: [Python-Dev] unexpected import behaviour

On 31/07/2010 16:30, Nick Coghlan wrote: On Sun, Aug 1, 2010 at 1:14 AM, Michael Foord wrote: Some people workaround the potential for bugs caused by __main__ reimporting itself by doing it *deliberately*. Glyf even recommends it as good practise. ;-) http://glyf.livejournal.com/60326

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 31/07/2010 17:22, Tarek Ziadé wrote: On Sat, Jul 31, 2010 at 1:46 PM, Michael Foord wrote: ... Installation of plugins would still be done through the standard distutils(2) machinery. (Using PEP 376 would depend on distutils2. I would be fine with this.) Note that the PEP 376

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

he user ever expects to visit. The home directory, or a subdirectory thereof, for user editable app specific data is more usual and more friendly. All the best, Michael Foord -- R. David Murray www.bitdance.com ___ Pytho

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

On 01/08/2010 21:37, Tarek Ziadé wrote: Hello, Here's a proposal to extend PEP 376 to support a basic plugins feature -- you should read PEP 376 before reading this mail It's basically Phillip's entry points, but with an activation flag, and a per-user config file. = adding a PLUGINS file = A

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

On 02/08/2010 00:46, Tarek Ziadé wrote: [snip...] I don't think that unittest would use a distutils2 (or pkgutil) supplied API for activation. But the discovery API you will use might just simply filter out disabled plugins. I did consider asking this but thought it was a silly ques

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

On 02/08/2010 01:03, Tarek Ziadé wrote: On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord wrote: On 02/08/2010 00:46, Tarek Ziadé wrote: [snip...] I don't think that unittest would use a distutils2 (or pkgutil) supplied API for activation. But the discovery AP

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 02/08/2010 07:18, Ronald Oussoren wrote: On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote: On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote: On 1 Aug, 2010, at 17:22, Éric Araujo wrote: Speaking of which... Your documentation says it's named ~/unittest.cfg, could you mak

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 02/08/2010 11:48, Ronald Oussoren wrote: On 02 Aug, 2010,at 11:48 AM, Michael Foord wrote: On 02/08/2010 07:18, Ronald Oussoren wrote: On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote: On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote: On 1 Aug, 2010, at 17:22, Éric Araujo

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 02/08/2010 11:48, Ronald Oussoren wrote: On 02 Aug, 2010,at 11:48 AM, Michael Foord wrote: On 02/08/2010 07:18, Ronald Oussoren wrote: On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote: On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote: On 1 Aug, 2010, at 17:22, Éric Araujo

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

On 02/08/2010 13:31, exar...@twistedmatrix.com wrote: On 12:21 pm, m...@egenix.com wrote: Tarek Ziad� wrote: On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote: .. So without specific examples of why this is a problem, it's hard to see why a special Python-specific set of configuration files is

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 02/08/2010 14:34, Ronald Oussoren wrote: On 02 Aug, 2010,at 01:00 PM, Michael Foord wrote: > The only apple one that is actually used is the .CFUserTextEncoding > file, I have an .Xcode in my home as well but that is empty and last > updated in 2007. AFAIK current versions

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 02/08/2010 14:34, Ronald Oussoren wrote: On 02 Aug, 2010,at 01:00 PM, Michael Foord wrote: > The only apple one that is actually used is the .CFUserTextEncoding > file, I have an .Xcode in my home as well but that is empty and last > updated in 2007. AFAIK current versions

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 02/08/2010 15:24, R. David Murray wrote: (Ronald, the text version of your message was very difficult to sort through and read, because all of the quoting information was lost. Just thought you'd want to know.) What I hear Glyph saying is that we should support looking in *both* locations for

Re: [Python-Dev] No response to posts

On 02/08/2010 17:54, Brian Curtin wrote: On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt > wrote: Benjamin Peterson mailto:benja...@python.org>> writes: > Please, let's stop messing with the tracker for everything. I think > the current set up works reasonably w

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

On 02/08/2010 19:05, Holger Krekel wrote: On Mon, Aug 2, 2010 at 6:57 PM, Ian Bicking wrote: Just to add a general opinion in here: Having worked with Setuptools' entry points, and a little with some Zope pluginish systems (Products.*, which I don't think anyone liked much, and some ways Z

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

On 02/08/2010 19:45, Holger Krekel wrote: On Mon, Aug 2, 2010 at 8:12 PM, Michael Foord wrote: On 02/08/2010 19:05, Holger Krekel wrote: On Mon, Aug 2, 2010 at 6:57 PM, Ian Bickingwrote: Just to add a general opinion in here: Having worked with Setuptools'

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

On 02/08/2010 20:36, M.-A. Lemburg wrote: Michael Foord wrote: On 02/08/2010 13:31, exar...@twistedmatrix.com wrote: On 12:21 pm, m...@egenix.com wrote: Tarek Ziad� wrote: On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote: .. So without specific

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

On 03/08/2010 09:28, M.-A. Lemburg wrote: P.J. Eby wrote: At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote: If that's the case, then it would be better to come up with an idea of how to make access to that meta-data available in a less I/O intense way, e.g. by having pip or other packa

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

standard tools, whether that be disutils2 or package managers, to install the plugins instead of requiring ad-hoc approaches like "drop this file in this location". All the best, Michael Foord System-wise, I much prefer the later, and auto-discovery should be left at the application

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

On 03/08/2010 16:24, David Cournapeau wrote: On Tue, Aug 3, 2010 at 11:35 PM, Michael Foord wrote: On 03/08/2010 15:19, David Cournapeau wrote: On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou wrote: On Tue, 03 Aug 2010 10:28:07 +0200 "M.-A. Lemburg"

Re: [Python-Dev] Looking after the buildbots (in general)

On 04/08/2010 16:15, exar...@twistedmatrix.com wrote: On 02:51 pm, ba...@python.org wrote: On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote: I think the issue is that many core developers don't have the reflex to check buildbot state after they commit some changes (or at least on a regular, s

Re: [Python-Dev] [python-committers] (Windows) buildbots on 3.x

On 04/08/2010 18:53, "Martin v. Löwis" wrote: It happens when running test_smtplib before test_smtpb: Nice! How did you work that out? I'd like to learn how to diagnose this sort of thing, because it seems to come up a lot, and I'm not much use at the moment :-) I simply tried

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. ID

Re: [Python-Dev] Fixing #7175: a standard location for Python config files

On 12/08/2010 11:18, Steve Holden wrote: On 8/12/2010 5:50 AM, Tim Golden wrote: On 11/08/2010 16:22, Éric Araujo wrote: 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 developme

Re: [Python-Dev] Fixing #7175: a standard location for Python config files

On 12/08/2010 11:54, Tim Golden wrote: On 12/08/2010 11:40, Michael Foord wrote: User editable configuration files are very different from libraries. The per user site-packages folder *should* be hidden somewhere out of the way where you can get at them if you want them but won't stumble a

Re: [Python-Dev] Fixing #7175: a standard location for Python config files

On 12/08/2010 08:26, Tarek Ziadé wrote: [snip...] Choosing an arbitrary location we think is good on every system is fine and non risky I think, as long as Python let the various distribution change those paths though configuration. In fact, that's one of the future goal of the sysconfig module

Re: [Python-Dev] Remove "unit test needed"

On 12/08/2010 12:56, Antoine Pitrou wrote: Hello, I would like to see “unit test needed” removed from the workflow menu in the bug tracker. The reason is that we don't do test-driven development (or, at least, most of us don't) and this stage entry is therefore useless and confusing. Saying to s

Re: [Python-Dev] mingw support?

On 13/08/2010 00:44, Greg Ewing wrote: Cesare Di Mauro wrote: You must suggest at least an equivalent "free" alternative to make the switch convenient. Otherwise we are talking about philosophy or religion, and nobody will change his ideas. I think the point is that *because* people don't

Re: [Python-Dev] Fixing #7175: a standard location for Python config files

On 13/08/2010 06:39, Stephen J. Turnbull wrote: Michael Foord writes: > How is ~/python not memorable or consistent? (And cross-platform > memorability and consistency is valuable too.) But what does "~" mean on Windows? There is a "user directory" in Windows di

Re: [Python-Dev] multi-version parallel-installed modules

lieve that setuptools / distribute already has a mechanism for supporting this. It basically does it with sys.path hackery. As far as I know there are no plans to include this in distutils2 - but Tarek can correct me if I am wrong. All the best, Michael

[Python-Dev] Fwd: Old link text in documentation

Could (and should) the online Python 3.1 docs be updated to show Python 2.7 as stable? All the best, Michael Original Message Subject:Old link text in documentation Date: Sun, 15 Aug 2010 15:49:34 -0700 From: Aaron DeVore To: webmas...@python.org The link

Re: [Python-Dev] Fwd: Old link text in documentation

On 18/08/2010 21:59, "Martin v. Löwis" wrote: Am 18.08.2010 17:11, schrieb Michael Foord: Could (and should) the online Python 3.1 docs be updated to show Python 2.7 as stable? I think the answer is "no, it could not". How many old documentation sets would yo

Re: [Python-Dev] 'hasattr' is broken by design

n but do not run code. It would be backwards incompatible with usage of hasattr for dynamically created 'members' using __getattr__ though. For what it's worth I *agree* with you [1], but for better or worse hasattr / getattr trigger code execution and hasattr can return Tr

Re: [Python-Dev] 'hasattr' is broken by design

On 23/08/2010 22:59, Benjamin Peterson wrote: [snip...] IMO, this is a much better solution, more in line with known use cases for hasattr(). If the proposed change when through, it would fail to address the common use case and cause people to start writing their own versions of hasattr() tha

Re: [Python-Dev] 'hasattr' is broken by design

On 23/08/2010 23:13, Benjamin Peterson wrote: 2010/8/23 Michael Foord: To me hasattr *looks* like a passive introspection function, and the fact that it can trigger arbitrary code execution is unfortunate - especially because a full workaround is pretty arcane. That's the danger of a dy

Re: [Python-Dev] 'hasattr' is broken by design

On 23/08/2010 23:55, Benjamin Peterson wrote: 2010/8/23 Raymond Hettinger: On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote: 2010/8/23 Michael Foord: To me hasattr *looks* like a passive introspection function, and the fact that it can trigger arbitrary code execution is unfortunate

Re: [Python-Dev] 'hasattr' is broken by design

On 24/08/2010 00:05, Benjamin Peterson wrote: 2010/8/23 Michael Foord: On 23/08/2010 23:55, Benjamin Peterson wrote: 2010/8/23 Raymond Hettinger: On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote: 2010/8/23 Michael Foord: To me hasattr *looks* like a passive introspection function

Re: [Python-Dev] 'hasattr' is broken by design

On 24/08/2010 00:40, Nick Coghlan wrote: Properties are allowed to do whatever the heck they want. That doesn't mean that you have to execute code to determine whether they exist or not. If you don't want to execute properties, do the lookup on the type, not the instance (obviously, you know th

Re: [Python-Dev] 'hasattr' is broken by design

On 24/08/2010 01:25, Nick Coghlan wrote: On Tue, Aug 24, 2010 at 8:15 AM, Nick Coghlan wrote: Now, it may be worth considering an addition to the inspect module that was basically: def getattr_static(obj, attr): """Retrieve attributes without triggering dynamic lookup via the descriptor p

Re: [Python-Dev] 'hasattr' is broken by design

you are worried about overhead). This would also work with the suggested "passive introspection" function. All the best, Michael Foord -- at which point, you can always use the trace facility and throw an error when any Python code runs that's not part of your debugging tool

Re: [Python-Dev] Fwd: i18n

On 25/08/2010 21:26, Guido van Rossum wrote: [snip...] If (3) could enter the main trunk it would be a great help by itself. In this case access to international help is useless due the original difficulties with the language, remember I'm talking about kids mainly, and 1st stage to programming

Re: [Python-Dev] r84355 - python/branches/py3k/Lib/test/test_ssl.py

On 30/08/2010 00:23, Antoine Pitrou wrote: On Sun, 29 Aug 2010 22:56:56 +0200 (CEST) giampaolo.rodola wrote: +with self.assertRaises(IOError) as err: +ssl.wrap_socket(socket.socket(), certfile=WRONGCERT) +self.assertEqual(err.errno, errno.ENOENT) The assertEqua

Re: [Python-Dev] PEP 384 status

On 30/08/2010 17:35, Barry Warsaw wrote: On Aug 30, 2010, at 10:18 PM, Nick Coghlan wrote: Since the Linkage section of PEP 384 specifically states the availability of a generic "python3.dll" that dynamically redirects to the relevant "python3y.dll" to allow an extension module to run against

Re: [Python-Dev] PEP 384 status

On 01/09/2010 13:54, Antoine Pitrou wrote: [snip...] Please consider this: even without relying on PEP 384, using FILE* is /already/ dangerous; because you might compile an extension with a different compiler version than Python was compiled with. So, if we were following you, we should rip out

Re: [Python-Dev] 'hasattr' is broken by design

On 24/08/2010 08:40, Michael Foord wrote: On 24/08/2010 01:25, Nick Coghlan wrote: On Tue, Aug 24, 2010 at 8:15 AM, Nick Coghlan wrote: Now, it may be worth considering an addition to the inspect module that was basically: def getattr_static(obj, attr): """Retrieve att

Re: [Python-Dev] 'hasattr' is broken by design

I've written proxy objects several times (for various different purposes) and this would have saved me the effort. :-) All the best, Michael Foord -- http://www.voidspace.org.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.pytho

Re: [Python-Dev] Volunteer help with porting

On 07/09/2010 15:02, exar...@twistedmatrix.com wrote: On 01:33 pm, p...@phd.pp.ru wrote: Hello. Thank you for the offer! On Tue, Sep 07, 2010 at 06:36:10PM +0530, Prashant Kumar wrote: My name is Prashant Kumar and I wish to contribute to the Python development process by helping convert cer

Re: [Python-Dev] Rework nntlib?

On 14/09/2010 11:17, Antoine Pitrou wrote: Hello, Like the email package, nntplib in py3k is broken (because of various bytes/str mismatches; I suppose the lack of a test suite didn't help when porting). I would like to take the opportunity to improve the API a bit; no heavy re-architecting, b

Re: [Python-Dev] Rework nntlib?

nse=&as_case= Of course *every* standard library module will have *some* users. The question is whether or not a handful of users justifies something being in the standard library. If it was proposed as a new package then we probably wouldn't want it, but as we already have it then making

Re: [Python-Dev] Rework nntlib?

On 14/09/2010 12:14, Nick Coghlan wrote: On Tue, Sep 14, 2010 at 9:04 PM, Senthil Kumaran wrote: I guess, Skip's question or intention was, how often nntplib as a module is being used these days to write scripts/tools or clients? Very rarely. It would definitely be interesting to know, if the

Re: [Python-Dev] Rework nntlib?

On 14/09/2010 12:47, Steve Holden wrote: On 9/14/2010 7:10 AM, Michael Foord wrote: On 14/09/2010 12:04, Senthil Kumaran wrote: On Tue, Sep 14, 2010 at 12:44:30PM +0200, Baptiste Carvello wrote: Antoine> Like the email package, nntplib in py3k is broken (because of Anto

Re: [Python-Dev] 3.x as the official release

On 15/09/2010 17:35, Jesse Noller wrote: On Wed, Sep 15, 2010 at 12:22 PM, Brett Cannon wrote: ...snip... The one area I have concerns about is the state of WSGI and other web-oriented modules. These issues have been brought up by Armin and others, but given a lack of a clear path forward (bug

Re: [Python-Dev] r84847 - python/branches/py3k/Doc/library/re.rst

t the time). http://bugs.python.org/issue5337 Michael Foord Georg Am 16.09.2010 14:02, schrieb raymond.hettinger: Author: raymond.hettinger Date: Thu Sep 16 14:02:17 2010 New Revision: 84847 Log: Add tokenizer example to regex docs. Modified: python/branches/py3k/Doc/library/re.rst Mod

Re: [Python-Dev] Polymorphic best practices [was: (Not) delaying the 3.2 release]

On 16/09/2010 23:05, Antoine Pitrou wrote: On Thu, 16 Sep 2010 16:51:58 -0400 "R. David Murray" wrote: What do we store in the model? We could say that the model is always text. But then we lose information about the original bytes message, and we can't reproduce it. For various reasons (ma

Re: [Python-Dev] [Catalog-sig] egg_info in PyPI

d actively hinder adoption of the better replacement. All the best, Michael Foord Ideally, in future - I should be able to query static metadata (with environment markers[2] and such) for *any* package from PyPI. And this static metadata is simply a DIST-INFO file (instead of being a directo

Re: [Python-Dev] [Catalog-sig] egg_info in PyPI

On 18/09/2010 11:03, "Martin v. Löwis" wrote: With the distutils2 work very close to landing in the standard library, providing infrastructure that will cause tools to *depend* on the old formats is a very bad idea. I think you are misunderstanding. The infrastructure will *not* depend on the

Re: [Python-Dev] [Catalog-sig] egg_info in PyPI

On 18/09/2010 11:48, David Cournapeau wrote: On Sat, Sep 18, 2010 at 7:39 PM, Michael Foord wrote: On 18/09/2010 11:03, "Martin v. Löwis" wrote: That's really sad. So people will have to wait a few years to efficiently implement tools that they could implement today.

Re: [Python-Dev] [Catalog-sig] egg_info in PyPI

On 18/09/2010 12:25, "Martin v. Löwis" wrote: I think you are misunderstanding. The infrastructure will *not* depend on the old formats. Instead, packaging that have that information will provide it, packages that don't will not. The infrastructure is entirely agnostic on whether the data is av

Re: [Python-Dev] [Catalog-sig] egg_info in PyPI

ils2a1 is already out and distutils2a2 will be out soon). All the best, Michael Foord On 18/09/2010 14:21, "Martin v. Löwis" wrote: No. See above comment. If exposing this information has no value then don't do it. If it does have value, then we are blessing it - and therefor

<    1   2   3   4   5   6   7   8   9   10   >