Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

At 01:03 AM 3/5/2010, Brian Quinlan wrote: Hi all, I recently submitted a daft PEP for a package designed to make it easier to execute Python functions asynchronously using threads and processes. It lets the user focus on their computational problem without having to build explicit thread/proces

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

At 01:19 AM 3/6/2010, Jeffrey Yasskin wrote: On Fri, Mar 5, 2010 at 10:11 PM, Phillip J. Eby wrote: > I'm somewhat concerned that, as described, the proposed API ... [creates] yet another alternative (and > mutually incompatible) event loop system in the stdlib ... Futures are

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

At 05:32 AM 3/6/2010, Brian Quinlan wrote: Using twisted (or any other asynchronous I/O framework) forces you to rewrite your I/O code. Futures do not. Twisted's "Deferred" API has nothing to do with I/O. ___ Python-Dev mailing list Python-Dev@pyth

Re: [Python-Dev] Doctest and Footnotes

At 11:36 PM 7/10/2006 -0400, Benji York wrote: >The footnote code is executed every time the footnote is referenced, and >is /not/ executed at any other time (i.e. it's not executed at the point >the footnote is defined). A warning is generated if a footnote (that >includes code) is defined but ne

Re: [Python-Dev] Capabilities / Restricted Execution

At 03:36 AM 7/11/2006 -0700, Talin wrote: >I thought a little bit more about Guido's comment that you can hide >Python objects in a C wrapper class. However, as I was trying to sleep, >I realized that you don't even need C to do it. > >The trick is to store the object reference as a closure variabl

Re: [Python-Dev] Capabilities / Restricted Execution

At 01:30 PM 7/11/2006 -0400, Scott Dial wrote: >Phillip J. Eby wrote: > > A function's func_closure contains cell objects that hold the > > variables. These are readable if you can set the func_closure of some > > function of your own. If the overall plan includes

Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]

At 10:56 AM 7/11/2006 -0700, Brett Cannon wrote: >On 7/10/06, Talin <[EMAIL PROTECTED]> wrote: >>(Although, I've often wished for Python to have a variant of __call__ >>that could be used to override individual methods, i.e.: >> >> __call_method__( self, methodname, *

Re: [Python-Dev] Doctest and Footnotes

At 02:12 PM 7/11/2006 -0400, Alexander Belopolsky wrote: >On 7/11/06, Benji York <[EMAIL PROTECTED]> wrote: >[snip] > > I'm not quite sure what you're suggesting. A guess: put the code that > > isn't to be seen in the __test__ dict with a string key being the name > > of the footnote? > >That's ri

Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]

At 11:35 AM 7/11/2006 -0700, Brett Cannon wrote: >On 7/11/06, Phillip J. Eby ><<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote: >>At 10:56 AM 7/11/2006 -0700, Brett Cannon wrote: >> >On 7/10/06, Talin >> <<mailto:[EMAIL PROTECTED]><ma

Re: [Python-Dev] Dynamic module namspaces

At 03:38 PM 7/15/2006 -0300, Johan Dahlin wrote: >In an effort to reduce the memory usage used by GTK+ applications >written in python I've recently added a feature that allows attributes >to be lazy loaded in a module namespace. The gtk python module contains >quite a few attributes (around 850) o

[Python-Dev] Undocumented PEP 302 protocol change by need-for-speed sprint

While investigating the need to apply http://python.org/sf/1525766 I found that there was a modification to pkgutil during the need-for-speed sprint that affects the PEP 302 protocol in a backwards incompatible way. Specifically, PEP 302 documents that path_importer_cache always contains either

Re: [Python-Dev] Undocumented PEP 302 protocol change by need-for-speed sprint

At 12:28 PM 7/20/2006 -0700, Brett Cannon wrote: >On 7/20/06, Phillip J. Eby ><<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote: >>While investigating the need to apply >><http://python.org/sf/1525766>http://python.org/sf/1525766 I found >>that ther

Re: [Python-Dev] new security doc using object-capabilities

At 01:00 PM 7/23/2006 -0700, Brett Cannon wrote: >I obviously don't want to change the feel of Python, but if I have to >remove the constructor for code objects to prevent evil bytecode or >__subclasses__() from object to prevent poking around stuff, then so be >it. For this project, security i

Re: [Python-Dev] new security doc using object-capabilities

At 11:07 PM 7/23/2006 +0100, David Hopwood wrote: >Phillip J. Eby wrote: > > At 01:00 PM 7/23/2006 -0700, Brett Cannon wrote: > > > >>I obviously don't want to change the feel of Python, but if I have to > >>remove the constructor for code objects to preve

Re: [Python-Dev] new security doc using object-capabilities

At 09:27 PM 7/23/2006 -0700, Brett Cannon wrote: >On 7/23/06, Phillip J. Eby ><<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote: >>one proxy plus one namechecker equals one capability. In other words, >>you could take the restricted interpreter, the proxy mechan

Re: [Python-Dev] new security doc using object-capabilities

At 12:50 AM 7/24/2006 -0700, Brett Cannon wrote: >OK, then I need something clarified. If you read >http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TransitionToSecurityProxies > >, it t

Re: [Python-Dev] new security doc using object-capabilities

At 12:04 PM 7/25/2006 +1200, Greg Ewing wrote: >Phillip J. Eby wrote: > > > When I say "name checker" I mean the Zope type that allows you to > specify a > > list of names that are allowed for a given object. This allowing is not > > based on identity or code

[Python-Dev] Release manager pronouncement needed: PEP 302 Fix

I posted last week about a need-for-speed patch that broke PEP 302 compliance, and asked if it should be fixed or reverted. I got exactly one response which said "yes, it should be fixed or reverted", which unfortunately didn't answer my question as to which one we should do. :) If we don't r

Re: [Python-Dev] New miniconf module

At 07:47 PM 7/26/2006 +0100, David Hopwood wrote: >Sylvain Fourmanoit wrote: > > I wrote a data persistence module called miniconf, aimed at making > > easy to create and safely retrieve configuration info from external, > > human-readable sources using Python syntax. I feel it would eventually > >

Re: [Python-Dev] New miniconf module

At 05:43 PM 7/26/2006 -0400, Sylvain Fourmanoit wrote: > > The loading code could also be made a lot faster by using a dictionary > > mapping AST node types to functions, instead of doing string > > manipulation for each node. Each function could take 'pedantic' as a > > parameter, which would eli

Re: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix

At 12:52 PM 7/27/2006 +0200, Georg Brandl wrote: >Armin Rigo wrote: > > Hi Phillip, > > > > On Wed, Jul 26, 2006 at 02:40:27PM -0400, Phillip J. Eby wrote: > >> If we don't revert it, there are two ways to fix it. One is to just > change > >&

Re: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix

At 12:52 PM 7/27/2006 +0200, Georg Brandl wrote: >Though beta1 and beta2 shipped with this change nobody reported any bug that >could be linked to it Actually, that's no longer true. See: http://python.org/sf/1529871 This is a user-reported bug against 2.5b2, and I have just confirmed that it

Re: [Python-Dev] Which version of distutils to ship with Python 2.5?

At 01:51 PM 7/27/2006 -0400, Collin Winter wrote: >On 7/27/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Collin Winter wrote: > > > Is it intentional that Python 2.5 is (currently) shipping with > > > distutils 2.4.0, while Python 2.4 (at least 2.4.1, 2.4.2 and 2.4.3) > > > shipped with dist

Re: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix

At 09:49 PM 7/27/2006 -0700, Neal Norwitz wrote: >On 7/27/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: >> >>Personally, I would prefer to see it properly fixed in 2.5 rather than >>having to rip it out. It's more work for me to create the proper fix than >>i

Re: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix

At 07:33 AM 7/28/2006 +0200, Martin v. Löwis wrote: >Phillip J. Eby wrote: > > I'm willing to write code that makes it PEP 302 compliant, if the release > > manager will bless such an addition. But if that's not acceptable, then > > somebody needs to produce the nec

Re: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix

At 04:07 PM 7/28/2006 -0400, Fred L. Drake, Jr. wrote: >On Friday 28 July 2006 00:49, Neal Norwitz wrote: > > Based on this comment, is it really acceptable to just document a > > behaviour change? ISTM there should really only be 2 choices: fix > > 2.5 properly or revert the change. This see

Re: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix

At 10:55 PM 7/28/2006 +0200, Martin v. Löwis wrote: >Phillip J. Eby wrote: > > The issue is that a proper fix that caches existence requires adding new > > types to import.c and thus might appear to be more of a feature. I was > > therefore reluctant to embark upon the work w

Re: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix

At 11:11 AM 8/8/2006 -0400, Jean-Paul Calderone wrote: >On Fri, 28 Jul 2006 18:00:36 -0400, "Phillip J. Eby" ><[EMAIL PROTECTED]> wrote: >>At 10:55 PM 7/28/2006 +0200, Martin v. Löwis wrote: >>>Phillip J. Eby wrote: >>> > The issue is that a pro

Re: [Python-Dev] SyntaxError: can't assign to function call

At 09:24 AM 8/10/2006 -0700, Guido van Rossum wrote: >On 8/10/06, James Y Knight <[EMAIL PROTECTED]> wrote: > > It makes just as much sense as assigning to an array access, and the > > semantics would be pretty similar. > >No. Array references (x[i]) and attribute references (x.a) represent >"locat

Re: [Python-Dev] SyntaxError: can't assign to function call

At 12:28 PM 8/10/2006 -0700, Guido van Rossum wrote: >>On Aug 10, 2006, at 12:31 PM, Phillip J. Eby wrote: >> > Honestly, it might make more sense to get rid of augmented >> > assignment in Py3K rather than to add this. It seems that the need >> > for something

Re: [Python-Dev] SyntaxError: can't assign to function call

At 09:40 PM 8/11/2006 +0200, Martin v. Löwis wrote: >Michael Urman schrieb: > > On 8/9/06, Michael Hudson <[EMAIL PROTECTED]> wrote: > >> The question doesn't make sense: in Python, you assign to a name, > >> an attribute or a subscript, and that's it. > > > > Just to play devil's advocate here, wh

Re: [Python-Dev] Type of range object members

At 11:46 PM 8/15/2006 -0700, Neal Norwitz wrote: >On 8/15/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> >>That penalty is already paid today. Much code dealing with >>ints has a type test whether it's an int or a long. If >>int and long become subtypes of each other or of some abstract >>type

Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary

I rather like it, actually. I don't recall there being any real reasons to catch a GeneratorExit exception, but even if there were, you could do the equivalent like this: try: closed = True yield 1 closed = False finally: if closed: # s

Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary

At 04:10 PM 8/23/2006 -0700, Guido van Rossum wrote: >IIUC this is how return currently works -- in some sense it's an >exception, but it can't be caught, and it won't escape from the >current frame. Ditto for break/continue. > >The generator extensions are still very young, and I'm not against >ch

Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary

At 01:44 AM 8/24/2006 +0200, Igor Bukanov wrote: >Regarding yield in the finally problem: > >The current implementation throws RuntimeException after the yield >transfer the control back to the close method. If that is changed to >reporting a bad behavior and rethrowing GeneratorExit or its hidden

Re: [Python-Dev] Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented

At 05:20 PM 8/29/2006 -0700, Raymond Hettinger wrote: >* The implementation's doc string examples were not tested and don't >work (this is a deep error). One reads: > > with decimal.getcontext() as ctx: > ctx.prec += 2 > s = ... > return +s > > >To get this to work with the

Re: [Python-Dev] Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented

At 05:57 PM 8/29/2006 -0700, Raymond Hettinger wrote: >Phillip J. Eby wrote: > >>At 05:20 PM 8/29/2006 -0700, Raymond Hettinger wrote: >> >>>* The implementation's doc string examples were not tested and don't >>>work (this is a deep error). One reads

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

At 04:55 PM 9/5/2006 -0400, Barry Warsaw wrote: >On Sep 5, 2006, at 4:43 PM, Jim Jewett wrote: > > > I think I finally figured out where Raymond is coming from. > > > > For Raymond, "head" is where he started processing -- for rpartition, > > this is the .endswith part. > > > > For me, "head" is th

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

At 02:08 AM 9/6/2006 +0100, David Hopwood wrote: >Barry Warsaw wrote: > > The bias with these terms is clearly the English left-to-right > > order. Actually, that brings up an interesting question: what would > > happen if you called rpartition on a unicode string representing > > Hebrew, Arabic,

Re: [Python-Dev] deja-vu .. python locking

At 07:08 PM 9/18/2006 +0200, Martin Devera wrote: > >> So that you are right. It is not RCU. It only uses similar technique > as RCU > >> uses for free-ing old copy of data. > >> > >> It is based on assumption that an object is typicaly used by single > thread. > > > > Which thread owns builtins?

Re: [Python-Dev] New relative import issue

At 01:54 PM 9/21/2006 -0700, Guido van Rossum wrote: >On 9/21/06, Paul Moore <[EMAIL PROTECTED]> wrote: > > On 9/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > I think one missing feature is a mechanism whereby you can say "THIS > > > package (gives top-level package name) lives HERE (giv

Re: [Python-Dev] New relative import issue

At 03:28 PM 9/21/2006 -0700, Guido van Rossum wrote: >os.environ is useless because there's no way for a package installer >to set it for all users. Or even for *one* user! :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mai

Re: [Python-Dev] New relative import issue

At 12:07 PM 9/22/2006 +1200, Greg Ewing wrote: >Another thought on static module namespace configuration: >It would make things a *lot* easier for py2exe, py2app >and the like that have to figure out what packages >a program depends on without running the program. Setuptools users already explicit

Re: [Python-Dev] New relative import issue

At 12:40 PM 9/22/2006 +1200, Greg Ewing wrote: >Guido van Rossum wrote: > > > While I agree with your idea(l), I don't think that's what Greg meant. > > He clearly say "sys.path should not exist at all". > >Refining that a bit, I don't think there should be >a *single* sys.path for the whole progra

Re: [Python-Dev] New relative import issue

At 08:44 PM 9/21/2006 -0700, Josiah Carlson wrote: >This can be implemented with a fairly simple package registry, contained >within a (small) SQLite database (which is conveniently shipped in >Python 2.5). There can be a system-wide database that all users use as >a base, with a user-defined pack

Re: [Python-Dev] New relative import issue

At 12:08 AM 9/22/2006 -0700, Josiah Carlson wrote: >"Phillip J. Eby" <[EMAIL PROTECTED]> wrote: > > > > At 08:44 PM 9/21/2006 -0700, Josiah Carlson wrote: > > >This can be implemented with a fairly simple package registry, contained > > >within

Re: [Python-Dev] Relative import bug?

At 08:10 PM 9/22/2006 +0200, Thomas Heller wrote: >Consider a package containing these files: > >a/__init__.py >a/b/__init__.py >a/b/x.py >a/b/y.py > >If x.py contains this: > >""" >from ..b import y >import a.b.x >from ..b import x >""" > >Python trunk and Python 2.5 both complain: > >Python 2.5 (

Re: [Python-Dev] New relative import issue

At 12:42 PM 9/22/2006 -0700, Josiah Carlson wrote: > > You might as well suggest that each environment > > consist of a single large zipfile containing the packages in question: > this > > would actually be *more* practical (and fast!) in terms of Python startup, > > and is no different from havin

Re: [Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source

At 02:11 PM 9/27/2006 -0700, Brett Cannon wrote: >But it has been suggested here that the import machinery be rewritten in >Python. Now I have never touched the import code since it has always had >the reputation of being less than friendly to work with. I am asking for >opinions from people w

Re: [Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source

At 04:11 PM 9/27/2006 -0700, Brett Cannon wrote: >On 9/27/06, Phillip J. Eby ><<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote: >>At 02:11 PM 9/27/2006 -0700, Brett Cannon wrote: >> >But it has been suggested here that the import machinery be rewritten

Re: [Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source

At 05:26 PM 9/27/2006 -0700, Brett Cannon wrote: >Ah, OK. So for importing 'email', the zipimporter would call the .pyc >importer and it would ask the zipimporter, "can you get me email.pyc?" and >if it said no it would move on to asking the .py importer for email.py, etc. Yes, exactly. >That

Re: [Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source

At 11:25 AM 9/28/2006 -0700, Brett Cannon wrote: >I will think about it, but I am still trying to get the original question >of how bad the C code is compared to rewriting import in Python from >people. =) I would say that the C code is *delicate*, not necessarily bad. In most ways, it's rath

Re: [Python-Dev] PEP 351 - do while

At 12:58 PM 10/1/2006 -0400, Andrew Koenig wrote: > > (I don't think this has been suggested yet.) > > > > while , : > > > >This usage makes me uneasy, not the least because I don't understand why the >comma isn't creating a tuple. That is, why whould > > while x, y: >

Re: [Python-Dev] Created branch for PEP 302 phase 2 work (in C)

At 01:01 PM 10/2/2006 -0700, Brett Cannon wrote: >In the interest of time I have decided to go ahead and do the PEP 302 >phase 2 work in C. Just FYI, it's not possible (so far as I know) to implement phase 2 while maintaining backward compatibility with existing 2.x code. So this work shouldn'

Re: [Python-Dev] Created branch for PEP 302 phase 2 work (in C)

At 03:48 PM 10/2/2006 -0700, Brett Cannon wrote: >On 10/2/06, Paul Moore <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> >wrote: >>On 10/2/06, Phillip J. Eby >><<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote: >>[SNIP] >> > I'm su

Re: [Python-Dev] Created branch for PEP 302 phase 2 work (in C)

At 08:21 PM 10/2/2006 -0400, A.M. Kuchling wrote: >On Mon, Oct 02, 2006 at 11:27:07PM +0100, Paul Moore wrote: > > Yes, I'm quite surprised at how much has appeared in pkgutil. The > > "what's new" entry is very terse, and the module documentation itself > > hasn't been updated to mention the new s

Re: [Python-Dev] PEP 355 status

At 09:49 AM 10/25/2006 -0700, Talin wrote: >Having done a path library myself (in C++, for our code base at work), >the trickiest part is getting the Windows path manipulations right, and >fitting them into a model that allows writing of platform-agnostic code. >This is especially vexing when you r

Re: [Python-Dev] PEP 355 status

At 10:16 AM 10/25/2006 -0700, Talin wrote: >Phillip J. Eby wrote: > > At 09:49 AM 10/25/2006 -0700, Talin wrote: > >> Having done a path library myself (in C++, for our code base at work), > >> the trickiest part is getting the Windows path manipulations right, and >

Re: [Python-Dev] Path object design

At 01:56 AM 11/4/2006 +0100, Andrew Dalke wrote: >os.join assumes the base is a directory >name when used in a join: "inserting '/' as needed" while RFC >1808 says > >The last segment of the base URL's path (anything >following the rightmost slash "/", or the entire path if

Re: [Python-Dev] infinities

At 07:07 PM 11/26/2006 +0200, tomer filiba wrote: > > sys.maxint makes more sense there. >no, it requires *infinity* to accomplish x - y == x; y != 0, for example: > >while limit > 0: > limit -= len(chunk) Um, you do realize that you're not going to be able to fit sys.maxint strings into a li

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

At 11:09 AM 11/22/2006 -0500, Ian Murdock wrote: >The first question we have to answer is: What does it mean to "add >Python to the LSB"? Is it enough to say that Python is present >at a certain version and above, or do we need to do more than that >(e.g., many distros ship numerous Python add-ons

Re: [Python-Dev] Distribution tools: What I would like to see

At 01:21 PM 11/26/2006 -0800, Mike Orr wrote: >A comprehensive third-party manual that integrates the documentation >would be a good place to start. Even the outline of such a manual >would be a good. That would give a common baseline of understanding >for package users, package developers, and cor

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

At 02:38 PM 11/27/2006 +0100, Jan Matejek wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >Phillip J. Eby napsal(a): > > Just a suggestion, but one issue that I think needs addressing is the FHS > > language that leads some Linux distros to believe that they sh

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

At 01:05 PM 11/28/2006 -0800, Guido van Rossum wrote: >On 11/28/06, Barry Warsaw <[EMAIL PROTECTED]> wrote: > > There's a related issue that may or may not be in scope for this > > thread. For distros like Gentoo or Ubuntu that rely heavily on their > > own system Python for the OS to work properl

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

At 06:41 PM 11/28/2006 -0500, Barry Warsaw wrote: >On Nov 28, 2006, at 4:19 PM, Phillip J. Eby wrote: >>At 01:05 PM 11/28/2006 -0800, Guido van Rossum wrote: >>>On 11/28/06, Barry Warsaw <[EMAIL PROTECTED]> wrote: >>> > There's a related issue that may or

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

At 03:20 AM 11/30/2006 +, [EMAIL PROTECTED] wrote: >One of the things that combinator hacks is where distutils thinks it >should install to - when *I* type "python setup.py install" nothing tries >to insert itself into system directories (those are for Ubuntu, not me) - >~/.local is the *def

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

At 06:49 PM 11/29/2006 -0500, Barry Warsaw wrote: >What might be nice would be to build a little more >infrastructure into Python to support eggs, by say adding a default >PEP 302 style importer that knows how to search for eggs in >'nests' (a directory containing a bunch of eggs). If you have set

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

At 05:10 AM 11/30/2006 +, [EMAIL PROTECTED] wrote: >On 04:36 am, [EMAIL PROTECTED] wrote: > > >easy_install uses the standard distutils configuration system, which means > >that you can do e.g. > >Hmm. I thought I knew quite a lot about distutils, but this particular >nugget had evaded me. T

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

At 06:02 PM 11/30/2006 +, [EMAIL PROTECTED] wrote: >On 05:37 pm, [EMAIL PROTECTED] wrote: > >Perhaps "pyinstall"? > >Keep in mind that Python packages will still generally be >*system*-installed with other tools, like dpkg (or apt) and rpm, on >systems which have them. The name of the packag

Re: [Python-Dev] Small tweak to tokenize.py?

At 09:49 AM 11/30/2006 -0800, Guido van Rossum wrote: >I've got a small tweak to tokenize.py that I'd like to run by folks here. > >I'm working on a refactoring tool for Python 2.x-to-3.x conversion, >and my approach is to build a full parse tree with annotations that >show where the whitespace and

Re: [Python-Dev] Small tweak to tokenize.py?

At 10:28 AM 11/30/2006 -0800, Guido van Rossum wrote: >Are you opposed changing tokenize? If so, why (apart from >compatibility)? Nothing apart from compatibility. I think you should have to explicitly request the new behavior(s), since tools (like detokenize) written to work around the old beh

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

At 02:46 PM 11/30/2006 -0800, Mike Orr wrote: >Speaking of Virtual Python [1], I've heard some people recommending it >as a general solution to the "this library breaks that other >application" problem and "this app needs a different version of X >library than that other app does". It was actually

Re: [Python-Dev] Virtual Python (was Re: Python and the Linux Standard Base (LSB))

At 11:38 AM 12/4/2006 -0800, Mike Orr wrote: >The other approaches work fine for giving each user a private install >dir, but don't address the case of the same user wanting different >install dirs for different projects. For instance, when exploring >Pylons or TurboGears which install a lot of pa

Re: [Python-Dev] Pydoc Improvements / Rewrite

At 06:35 PM 1/5/2007 -0700, Fernando Perez wrote: >Ron Adam wrote: > > > Laurent Gautier wrote: > > > > From the top of my head, there might be "ipython" (the excellent > > > interactive console) is possibly using pydoc > > > (in any case, I would say that the authors would be interested in > >

Re: [Python-Dev] Pydoc Improvements / Rewrite

At 12:16 AM 1/6/2007 -0500, Barry Warsaw wrote: >If you've already explained it, that's fine, but if not, could you >outline what you have against epydoc? The last I tried to work with it, it had even more hardcoded typechecking than pydoc does, spread out over more of the code base. Also, over

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater

At 11:10 PM 1/10/2007 +, Paul Moore wrote: >On 10/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I've been assuming for some time that the only hope for Py3k compatibility > > within Twisted would be using PyPy as a translation layer. > >Does this ring as many warning bells for me as i

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater

At 11:59 AM 1/12/2007 +, [EMAIL PROTECTED] wrote: >In order to do this, everything that has been changed in 3.0 has to have >some mechanism for working both ways in some 2.x release. I phrased this >as its "feature set" because I am not aware of any new functionality in >3.0 that simply isn

Re: [Python-Dev] The bytes type

At 07:47 AM 1/16/2007 -0800, Guido van Rossum wrote: >On 1/16/07, James Y Knight <[EMAIL PROTECTED]> wrote: > > On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote: > > > There seems to be rather a lot of confusion. No one is suggesting > > > Python 3.0 be anything less for the sake of backward compa

Re: [Python-Dev] The bytes type

At 09:50 AM 1/16/2007 -0800, Guido van Rossum wrote: >Actually it's very easy to write code using keys(), items() and >values() that works as well in 2.2 as it works in 3.0: never use the >iter* variants, and don't sweat the performance costs of creating a >list so much. If you can't afford to crea

Re: [Python-Dev] Proposed 3.0 compatiblity module

At 08:52 PM 1/16/2007 +, Steve Holden wrote: >I foresee that many people would be happy restricting their 2.X source >slightly to ensure perfect translation into (working, no necessarily >optimal) 3.0. Under those circumstances the 2to3 tool wouldn't >necessarily have to translate all valid 2.X

Re: [Python-Dev] Proposed 3.0 compatiblity module

At 03:18 PM 1/16/2007 -0800, Guido van Rossum wrote: >On 1/16/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > The idea here being that, once 2.6 is widely-enough deployed that it can be > > assumed as a base for one's users, you can simply run the translator once, &g

Re: [Python-Dev] Proposed 3.0 compatiblity module

At 10:23 PM 1/16/2007 +, Steve Holden wrote: >Phillip J. Eby wrote: >>At 08:52 PM 1/16/2007 +, Steve Holden wrote: >>>I foresee that many people would be happy restricting their 2.X source >>>slightly to ensure perfect translation into (working, no necessarily &

Re: [Python-Dev] Proposed 3.0 compatiblity module

At 03:47 PM 1/16/2007 -0800, Guido van Rossum wrote: >Oh, as long as we're talking adding features to 2.6 I'm fine. I >thought you were proposing changes to the plans for 3.0, as in your >proposal" regarding the dict view API. Nah, that was a side tangent, combined with a partial lack of understan

Re: [Python-Dev] syntax misfeature (exception)

At 01:17 PM 1/20/2007, Josiah Carlson wrote: >Neal Becker <[EMAIL PROTECTED]> wrote: >[snip] > > It's not a question, it's a critique. I believe this is a misfeature since > > it's so easy to make this mistake. > >And it is going away with Py3k. Making it go away for Python 2.6 would >either all

Re: [Python-Dev] Changing a value in a frame (for a debugger)

At 08:11 AM 2/7/2007 -0200, Fabio Zadrozny wrote: >Would it be ok to add a feature request for that? I initially thought it >was completely read-only, but I find it strange that it affects the >topmost frame correctly (so, it seems that even though I get a copy, when >I alter that copy on the to

Re: [Python-Dev] Changing a value in a frame (for a debugger)

At 12:06 PM 2/8/2007 +1300, Greg Ewing wrote: >That's because the topmost frame has a module's dict >as its locals, so in that case you are modifying them >directly. It's only code compiled as the body of a >function that uses an array for locals. By "topmost", he means the frame that was interrup

Re: [Python-Dev] Trial balloon: microthreads library in stdlib

At 08:41 PM 2/13/2007 +, [EMAIL PROTECTED] wrote: > and the microthreading features being discussed here are a trivial hack > somewhere in its mainloop machinery, not an entirely new subsystem that > it should be implemented in terms of. It doesn't even require hacking the mainloop; it can

Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)

At 01:31 PM 2/15/2007 +1300, Greg Ewing wrote: >To my mind, there shouldn't be a "reactor" object >exposed to the application at all. There should just >be functions for setting up callbacks. The choice of >implementation should be made somewhere deep inside >the library, based on what platform is

Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)

At 04:25 PM 2/15/2007 +1300, Greg Ewing wrote: >Phillip J. Eby wrote: >>peak.events, for example, lets you have multiple event loops running in >>the same or different threads. > >Different threads is okay if you're willing to use threads, >but you might not. The reas

Re: [Python-Dev] microthreading vs. async io

At 11:00 PM 2/14/2007 -0600, [EMAIL PROTECTED] wrote: >Instead, I would like to concentrate on producing a small, clean, >consistent, generator-based microthreading library. I've seen several >such libraries (including the one in PEP 342, which is fairly skeletal), >and they all work *almost* the

Re: [Python-Dev] microthreading vs. async io

At 11:47 AM 2/15/2007 -0500, Jean-Paul Calderone wrote: >Is the only problem here that this style of development hasn't had been made >visible enough? You betcha. I sure as heck wouldn't have bothered writing the module I did, if I'd known it already existed. Or at least only written whatever

Re: [Python-Dev] Py2.6 ideas

At 01:38 PM 2/16/2007 +0100, Martin v. Löwis wrote: >Nick Coghlan schrieb: > > However, another aspect that occurred to me is that inheriting from > > tuple has significant practical benefits in terms of speed and memory > > consumption, at which point it doesn't seem worthwhile to *remove* the > >

Re: [Python-Dev] urllib2 EP + decr. startup time

At 04:38 PM 2/16/2007 +0200, KoDer wrote: >'strace' command shows next: most of startup time the interpreter >try to find imported modules. >And most of them finished with 'not found' error, because of large >size of sys.path variable. >In future this time will be increase - setuptools

Re: [Python-Dev] urllib2 EP + decr. startup time

At 07:29 PM 2/16/2007 +0200, KoDer wrote: >2007/2/16, Phillip J. Eby <[EMAIL PROTECTED]>: > > At 04:38 PM 2/16/2007 +0200, KoDer wrote: >. > > > > > > Also, are you aware that putting a zipped version of the standard library > > on sys.path already spe

Re: [Python-Dev] urllib2 EP + decr. startup time

At 01:25 PM 2/17/2007 +0200, KoDer wrote: >C:\\Python25\\lib\\. contain *many* packages with .dll files - i can't >just zip it. >wxPython,pyOpenGL,PIL,tk and so on. On Fedora 6 more than 40% dirs of >/usr/lib/site-packages contained .so files. Some of them add dirs to path >(wx,PIL,Gtk,...). I'm n

Re: [Python-Dev] Py2.6 ideas

At 10:17 AM 2/20/2007 +, Fuzzyman wrote: >Michele Simionato wrote: > > >Raymond Hettinger verizon.net> writes: > > > > > >>* Add a pure python named_tuple class to the collections module. I've > been > >>using the class for about a year and found that it greatly improves the > >>usability of

Re: [Python-Dev] Py2.6 ideas

At 09:56 AM 2/20/2007 -0800, Larry Hastings wrote: >My final bit of feedback: why is it important that a NamedTuple have a >class name? In a word: pickling. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python

Re: [Python-Dev] Old bug still unfixed? [ python-Patches-1183712 ] package_data chops off first char of default package

At 10:35 PM 2/23/2007 +0100, Martin v. Löwis wrote: >Hans Meine schrieb: > > > (I first posted this to distutils-sig but was told that distutils is a bit > > neglected there, so I decided to try to push these simple patches in via > > python-dev.) Lately, a student came to me complaining about an

Re: [Python-Dev] [Distutils] unicode bug in distutils

At 02:47 PM 2/24/2007 -0600, Tarek Ziadé wrote: >I have created a setup.py file for distirbution and I bumped into >a small bug when i tried to set my name in the contact field (Tarek Ziadé) > >Using string (utf8 file): > >setup( > maintainer="Tarek Ziadé" >) > >leads to: > > File ".../lib/pyt

Re: [Python-Dev] with_traceback

At 03:38 PM 2/26/2007 -0700, Andrew Dalke wrote: >Guido's talk at PyCon said: > > > Use raise E(arg).with_traceback(tb) > > instead of raise E, arg, tb > >That seems strange to me because of the mutability. Looking through >the back discussions on this list I see Guido commented: > http://m

  1   2   3   4   5   6   7   8   9   10   >