Re: [Python-Dev] Set methods for mapping views
Steven D'Aprano wrote: > On Tue, 27 Oct 2009 10:09:14 am Guido van Rossum wrote: >> On Mon, Oct 26, 2009 at 4:06 PM, Antoine Pitrou > wrote: >>> Steven D'Aprano pearwood.info> writes: I don't understand that rationale. Let's take a concrete example. The new `yield from` syntax was accepted >>> Was it? >> No. > > I thought it had been. My mistake. Serves me right for not checking the > PEP first. But my point still stands. Rather than going through and saying "oh, change X touches on area Y, where we're waiting to see how change Z plays out, so we shouldn't do X yet" it is simpler to declare the core of the language off limits for a release or two. We made a lot of big changes to fairly core parts of the language in a relatively short period. Giving those a chance to settle down before we start fiddling further is unlikely to be detrimental in the long run. 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] nonlocal keyword in 2.x?
Lennart Regebro gmail.com> writes: > > So 2.7 support will for the most part be a case not of supporting > Python versions, but Python *users*. That's still not a good reason to backport nonlocal. The same reasoning could be used to backport new features to the 2.6 branch after all. 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] Refactoring installation schemes
Tarek Ziadé wrote: > Hello, > > Since the addition of PEP 370, (per-user site packages), site.py and > distutils/command/install.py are *both* providing the various > installation directories for Python, > depending on the system and the Python version. > > We have also started to discuss lately in various Mailing Lists the > addition of new schemes for IronPython and Jython, meaning that we > might add some more in both places. > > I would like to suggest a simplification by adding a dedicated module > to manage these installation schemes in one single place in the > stdlib. > > This new independant module would be used by site.py and distutils and > would also make it easier for third party code to work with these > schemes. > Of course this new module would be rather simple and not add any new > import statement to avoid any overhead when Python starts and loads > site.py +1 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 28 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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 Package Management Roadmap in Python Releases
>> (*) Remember, however, that Tarek and work on Distribute, and also on >> bringing pieces of setuptools/Distribute functionality into distutils. > > But if that's the case then why not work on any third party tool..? like > pip or setuptools? > > It seems are very longwinded process if the only way to work on > python is to work on distutils but before doing that you have to > first work on distribute and then wait for all the changes to work > their way back up the chain.. > > Actually, I have finally worked out what I want. That is shell support > in the python windows distribution so that you can right click an > .egg and install it. > > I don't see how that can be achieved by following the workprocess > that you describe above. As has been said by many, you are entirely welcome to work on whatever tool you think is useful. Once you are done you are again welcome to distribute your tool or application to users and see how many users are happy with it. Once you are done with this step as well, you are again encouraged to come back to python-dev and say: "In the last X months my app/tool became very popular in the python community. There are Y developers working on the app/tool and there are Z happy users. I'd suggest including it in the python stdlib or I'd suggest coordinating the releases of my app/tool with that of python." At this point a useful conversation can start. Please note that a similarly useful conversation is impossible to take place before all the above steps have been completed. HTH, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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] Refactoring installation schemes
M.-A. Lemburg wrote: Tarek Ziadé wrote: Hello, Since the addition of PEP 370, (per-user site packages), site.py and distutils/command/install.py are *both* providing the various installation directories for Python, depending on the system and the Python version. We have also started to discuss lately in various Mailing Lists the addition of new schemes for IronPython and Jython, meaning that we might add some more in both places. I would like to suggest a simplification by adding a dedicated module to manage these installation schemes in one single place in the stdlib. This new independant module would be used by site.py and distutils and would also make it easier for third party code to work with these schemes. Of course this new module would be rather simple and not add any new import statement to avoid any overhead when Python starts and loads site.py +1 Also +1. It seems like this would make things easier for the alternative implementations. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] Reworking the GIL
Kristján Valur Jónsson ccpgames.com> writes: > > In my experience (from stackless python) using priority wakeup for IO can result in very erratic > scheduling when there is much IO going on, every IO trumping another. I whipped up a trivial multithreaded HTTP server using socketserver.ThreadingMixin and wsgiref, and used apachebench against it with a reasonable concurrency level (10 requests at once). Enabling/disabling priority requests doesn't seem to make a difference. 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] nonlocal keyword in 2.x?
>> So 2.7 support will for the most part be a case not of supporting >> Python versions, but Python *users*. Antoine> That's still not a good reason to backport nonlocal. The same Antoine> reasoning could be used to backport new features to the 2.6 Antoine> branch after all. No, because 2.6 is in feature freeze (bug fixes only). 2.7 is the current version of 2.x where new features are allowed to be added. Skip ___ 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] Refactoring installation schemes
On Oct 28, 2009, at 7:02 AM, Michael Foord wrote: M.-A. Lemburg wrote: Tarek Ziadé wrote: Hello, Since the addition of PEP 370, (per-user site packages), site.py and distutils/command/install.py are *both* providing the various installation directories for Python, depending on the system and the Python version. We have also started to discuss lately in various Mailing Lists the addition of new schemes for IronPython and Jython, meaning that we might add some more in both places. I would like to suggest a simplification by adding a dedicated module to manage these installation schemes in one single place in the stdlib. This new independant module would be used by site.py and distutils and would also make it easier for third party code to work with these schemes. Of course this new module would be rather simple and not add any new import statement to avoid any overhead when Python starts and loads site.py +1 This would help unpollute ~/ which is getting quite full of 'stuff.' S ___ 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] nonlocal keyword in 2.x?
pobox.com> writes: > > >> So 2.7 support will for the most part be a case not of supporting > >> Python versions, but Python *users*. > > Antoine> That's still not a good reason to backport nonlocal. The same > Antoine> reasoning could be used to backport new features to the 2.6 > Antoine> branch after all. > > No, because 2.6 is in feature freeze (bug fixes only). 2.7 is the current > version of 2.x where new features are allowed to be added. That was precisely my point. There are development practices which mitigate the idea that backporting is always helpful to the user. 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] Retrieve an arbitrary element from a set without removing it
[Guido wrote:] > - If sets were to grow an API to non-destructively access the object > stored in the set for a particular key, then dicts should have such a > method too. > - I still wish we could go back in time and unify sets and dicts, if > only to find out how that experiment would turn out. +5. If Python3 were to have this feature it would make it worth migrating to (and nearly worthy of the intent that was behind the idea of python3k). FWIW ... :) marcos ___ 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] Retrieve an arbitrary element from a set without removing it
[I wrote:] > If Python3 were to have this feature it would make it worth > migrating to Sorry that may have sounded more harsh than I expected. If I had more resources, I'd propose (and volunteer) a python3000 branch where any and all who were disappointed at the *lack* of compatability changes could continue working on the core language. (Moratorium controversy solved and quaranteened--any desireable features for the working branch would be back-propagated via the time machine as BDFL permits.) marcos ___ 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] Refactoring installation schemes
M.-A. Lemburg wrote: > +1 On Oct 28, 2009, at 7:02 AM, Michael Foord wrote: > Also +1. It seems like this would make things easier for the alternative > implementations. On Wed, Oct 28, 2009 at 3:30 PM, sstein...@gmail.com wrote: > +1 Ok then I'll work on a patch for that change and start an issue about it soon. > This would help unpollute ~/ which is getting quite full of 'stuff.' Notice that there's a discussion going on about that at http://bugs.python.org/issue7175 Regards Tarek ___ 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] Retrieve an arbitrary element from a set without removing it
On Wed, Oct 28, 2009 at 12:34 PM, average wrote: > [I wrote:] >> If Python3 were to have this feature it would make it worth >> migrating to > > Sorry that may have sounded more harsh than I expected. If I had more > resources, I'd propose (and volunteer) a python3000 branch where any > and all who were disappointed at the *lack* of compatability changes > could continue working on the core language. (Moratorium controversy > solved and quaranteened--any desireable features for the working > branch would be back-propagated via the time machine as BDFL permits.) > > marcos This is effectively the sandbox idea I proposed, except with backporting. Geremy Condra ___ 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] Where is `ctypes.com` ?
Hello ! Recently I found a code snippet [1]_ illustrating integration between Python and COM technology in Win32 systems. I tried to reproduce it and I can't import module `ctypes.com`. Q: - Is it (`ctypes.com`) distributed with stdlib ? If that's true then I'm affraid that those py files were removed somehow (accidentally ? who knows ? ) ... Thnx in advance ! .. [1] ctypes.win32.com.server @ Py (http://svn.python.org/projects/ctypes/tags/release_0_6_2/ctypes/win32/com/server.py) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: [visualization-api] ANN: TracGViz 1.3.4 released: msg#00244 ... - http://feedproxy.google.com/~r/TracGViz-full/~3/OBfKGS_sy2E/msg00244.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] Where is `ctypes.com` ?
Olemis Lang schrieb: > Hello ! > > Recently I found a code snippet [1]_ illustrating integration between > Python and COM technology in Win32 systems. I tried to reproduce it > and I can't import module `ctypes.com`. First, the python-dev mailing list is used for developing the Python language itself, not developing WITH Python. For questions about developing with Python, please use the newsgroup comp.lang.python. > Q: > > - Is it (`ctypes.com`) distributed with stdlib ? > > If that's true then I'm affraid that those py files were removed > somehow (accidentally ? who knows ? ) ... ctypes.com is very old and has been superseeded by the comtypes package: http://starship.python.net/crew/theller/comtypes/ An even more popular package for using COM with python is pywin32: http://sourceforge.net/projects/pywin32/ -- Thanks, Thomas ___ 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] Where is `ctypes.com` ?
On Wed, Oct 28, 2009 at 4:39 PM, Thomas Heller wrote: > Olemis Lang schrieb: >> Hello ! >> >> Recently I found a code snippet [1]_ illustrating integration between >> Python and COM technology in Win32 systems. I tried to reproduce it >> and I can't import module `ctypes.com`. > > First, the python-dev mailing list is used for developing the Python language > itself, not developing WITH Python. For questions about developing with > Python, > please use the newsgroup comp.lang.python. > I apologize if needed ... but I didn't ask about «how to program things using `ctypes.com` ». I asked here because you are the ones who should know about modules in stdlib . That's why I thought that it was not «very» OT >> Q: >> >> - Is it (`ctypes.com`) distributed with stdlib ? >> >> If that's true then I'm affraid that those py files were removed >> somehow (accidentally ? who knows ? ) ... > > ctypes.com is very old and has been superseeded by the comtypes > package: http://starship.python.net/crew/theller/comtypes/ > Thnx ! > An even more popular package for using COM with python is > pywin32: http://sourceforge.net/projects/pywin32/ > Yes, I've just tried that one, but the fact is that I'm experiencing a problem with it (that I won't detail in here because this is not the list to talk about such subjects , isn't it ? ... just learning fast ... :P ) and I thought I could switch to that one ... Thnx very much for your reply ! -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Suggestions: Wave (private) Groups, integration - Google Wave API ... - http://feedproxy.google.com/~r/TracGViz-full/~3/cuwdwGkX1WA/90bf35ca0c38caf0 ___ 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] Retrieve an arbitrary element from a set without removing it
geremy condra writes: > On Wed, Oct 28, 2009 at 12:34 PM, average wrote: > > [I wrote:] > >> If Python3 were to have this feature it would make it worth > >> migrating to > > > > Sorry that may have sounded more harsh than I expected. If I had more > > resources, > This is effectively the sandbox idea I proposed, Um, guys? Python 3000 was a project involving fairly concentrated effort by about a dozen senior, very skilled, developers plus many others over a period of several (3 or 4?) years. The "sandbox" is going to be played in by people without the resources to create such an industrial-strength "code workshop," and as such is not going to be given anywhere near the credibility that the py3k effort got. As evidence of how difficult an effort like "Python 3000" is, consider: where is Perl 6? There are hundreds, perhaps thousands, of developers saying "we want Perl 6" but the resources aren't there to *finish* it. On the other hand, "this feature" is already present in Python in great generality. You just have to spell it for x in container: break (or any of several other ways). The multiple spellings (of different degrees of efficiency) and the lack of an obvious spelling are indeed warts IMO, but "this feature would make Python 3 worth migrating to" and "+5" are hard for me to understand except as extreme exaggeration. The Python 3000 effort succeeded because the resources were sufficient to the goal. Part of that is because some very powerful developers found some itches they needed to scratch: Guido is clearly happy with P3tL (Python 3 the Language), both its current state and the fact that all that effort was devoted to it. But now he (inter alia) wants to focus effort (mostly not his own ;-) on P3tSL (Python 3 the Standard Library) which still needs substantial cleanup though it's already very usable for many applications, and on P3S3PA (Python 3 Supported 3rd Party Applications). The resources available for language evolution have dried up; *you* who want more language evolution are going to have to supply them. OTOH, there are at present few attractive improvements. set.getany() is an example of the kind of decidedly unattractive improvement currently available. It has an efficient if not obvious spelling as above; it has several less efficient but more transparent spellings as have been posted several times. The *need* is not infinitesimal; some good programmers have testified to being stumped by this one. But it's not big, either. The *resources* required are surprisingly large: although we already have a satisfactory implementation, about half of this thread has been devoted to discussing the various names proposed, and no conclusion reached in this thread or the previous one (of similar length). ___ 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] Retrieve an arbitrary element from a set without removing it
[Stephen Turbull] > The resources available for language evolution have dried up; > *you* who want more language evolution are going to have to > supply them. That's the idea I've been advocating- a code-first-jaw-later approach and the sandbox to support it. Its not even that hard to find where I've said exactly that in the moratorium discussion. Geremy Condra ___ 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] MSDN subscribers: Using Visual Studio?
I just wondered, with the recent flood of new MSDN subscriptions loosed on the developer community, how many people have installed the required version of Visual Studio and built Python for Windows from source? Not being that familiar with the process myself I was hoping for some advice from the inexperienced who have overcome any hurdles there might be. I have a pristine virtual machine just waiting for the right pieces ... Also what other uses have you found for the licenses? It would be good to get some information about how useful the licenses have been, and how they have helped people to improve Python's quality or ease of distribution (if they have). I'm sure Microsoft would also appreciate some positive feedback to their generosity, and I'll undertake to provide that if this message elicits much by way of reply. Since I'm pretty much too busy to follow the dev list right now I'd appreciate direct Cc's. regards Steve PS: If any further core developers need licenses, I plan to apply to Microsoft again in the new year. I'll be sending out a message then, I don't intend to keep a waiting list. -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Watch PyCon on video now! http://pycon.blip.tv/ ___ 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
