Re: [Python-Dev] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
On 10/26/2010 05:35 PM, Raymond Hettinger wrote: On Oct 26, 2010, at 2:54 PM, Ron Adam wrote: I wonder what you may think. Keep it in pydoc or move it to the HTTP package? Document it or not? I still would like to know what your thoughts are concerning where to put, and/or how to package, the simple threaded text server? Cheers, Ron ___ 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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
On Oct 26, 2010, at 09:54 PM, Antoine Pitrou wrote: >I think it comes down to the preference of whoever works the most >actively on it. Michael is the most active contributor to unittest by >far, and I suppose he prefers it to be split into several submodules. And that seems perfectly reasonable to me, especially if the alternative were that Michael was so frustrated with a massive single .py file that it discouraged him from working on it. If done well, a split can help improve the readability and discoverability of the code. I shudder at the madness that a single email.py file would cause. -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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
On Tue, 26 Oct 2010 16:46:15 -0400, Michael Foord wrote: > On 26/10/2010 15:05, R. David Murray wrote: > > On Tue, 26 Oct 2010 10:39:19 -0700, Raymond > > Hettinger wrote: > >> If someone wants to reorganize code for clarity, I would prefer keeping > >> it within one file, bringing related functions together and using > >> comment lines to mark the major sections. ISTM, this is cleaner than > >> introducing a new directory and having multiple files that cross-import > >> one another. > > +1 (or more) > Really, you prefer to work in single multi-thousand line modules than > cleanly split smaller packages? (Is that how you develop your own > projects, out of interest?) Yes. Note that this is a more recent tendency, a few years ago I used to split things pretty finely right off the bat, but I found I wasted a lot of time on py-file interdependencies doing it that way. Now I generally only split when the pieces end up generalized enough that I want to reuse them. Which, granted, is often enough. But what I'm doing in that case is moving code out of a file at the top level of my libraryinto a new file at the top level of my library. Now, it's true that I haven't written any huge applications lately, but looking at a couple of typical projects the main files run between 1500 and 2000 lines (including comments), and I don't find those to be particularly big and certainly not awkward. I do understand the attraction of putting "related stuff" into separate files. I just think the balance may have tilted too far in the direction of nested and could stand to be nudged back toward flat :) Unittest is only 2600 lines total including comments. Typical file sizes are between 200 and 300 lines. Those feel tiny to me :) (And email is worse...a number of files only have a single class in them, and some of those classes consist of maybe 20 lines...) -- R. David Murray www.bitdance.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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
On Oct 26, 2010, at 04:46 PM, Michael Foord wrote: >I find the big-ball-of-mud style development, where everything lives inside >huge monolithic modules, very painful. I also think that it is an extremely >bad example for new developers. There is something to be said for consistency >within the standard library, but I don't think it is a price worth paying in >this particular case. +1 (or more). :) or-maybe-you'd-prefer-more-^L-y y'rs, -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] new buffer in python2.7
Not forgetggin the StringI object in cStringIO.
IMHO, not accepting buffers by these objects can be consided a bug, that needs
fixing.
K
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of
Kristján Valur Jónsson
Sent: Wednesday, October 27, 2010 10:13
To: Python-Dev (python-dev@python.org)
Subject: [Python-Dev] new buffer in python2.7
Although 2.7 has the new buffer interface and memoryview objects, these are
widely not accepted in the built in modules.
Examples are the structmodule, some of the socketmodule apis, structmodule, etc.
IMHO this is unfortunate. For example when doign network io, you would want
code like this:
Buffer = bytearray(10)
Socket.recv_into(Buffer)
Header = struct.unpack("i", memoryview(Buffer)[:4])[0]
In other words, you want to minimize coping the data around. Currently in 2.7
you have to cast the memoryview to str() which copies the data. In 3.0 you
don't.
Is there any chance of getting changes like these in ?
(swapping s# for s* in PyArg_ParseTuple in a few strategic places)
My current list of places would be:
_strucmodule.c
arraymodule.c
zlibmodule.c
marshal.c
audioop.c and imageop.c are probably less important.
K
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] new buffer in python2.7
Although 2.7 has the new buffer interface and memoryview objects, these are
widely not accepted in the built in modules.
Examples are the structmodule, some of the socketmodule apis, structmodule, etc.
IMHO this is unfortunate. For example when doign network io, you would want
code like this:
Buffer = bytearray(10)
Socket.recv_into(Buffer)
Header = struct.unpack("i", memoryview(Buffer)[:4])[0]
In other words, you want to minimize coping the data around. Currently in 2.7
you have to cast the memoryview to str() which copies the data. In 3.0 you
don't.
Is there any chance of getting changes like these in ?
(swapping s# for s* in PyArg_ParseTuple in a few strategic places)
My current list of places would be:
_strucmodule.c
arraymodule.c
zlibmodule.c
marshal.c
audioop.c and imageop.c are probably less important.
K
___
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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
On Tue, Oct 26, 2010 at 5:37 PM, Fred Drake wrote: > On Tue, Oct 26, 2010 at 4:46 PM, Michael Foord > wrote: >> I find the big-ball-of-mud style development, where everything lives inside >> huge monolithic modules, very painful. I also think that it is an extremely >> bad example for new developers. > > Gadzooks, Michael! Something else we agree on. 2000-line modules are > a source of maintenance pain. > While I appreciate your and Michael's eloquence, I don't really see why five 400-line modules are necessarily easier to maintain than one 2000-line module. Splitting code into modules is certainly a good thing when the resulting modules can be used independently. This helps users write leaner programs, reduces mental footprint of individual modules, etc, etc. The split unittest module does not bring any such benefits. It still presents a single "big-ball-of-mud" namespace, only rather than implemented in a single file, it is now swept in from eight different files. If instead, unittest module was split into several top level modules so that test cases can be defined without pulling in test runner machinery and third party test runners could avoid importing irrelevant text runners, that would qualify as an improvement in my book, but probably not big enough to justify breaking compatibility. While maintainers' convenience is a valid valid concern and some level of idiosyncrasy is healthy to allow active maintainers to code in their preferred style, I think users' convenience should come first when it conflicts with that of maintainers. Remember, code is written once and read many. This is particularly true about stdlib. A minor inconvenience of finding the right place to stick a new function in a large file does not in my view overweights a major inconvenience of not having all pieces in one place neatly organized in a linear order. ___ 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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
On 10/26/2010 05:35 PM, Raymond Hettinger wrote: On Oct 26, 2010, at 2:54 PM, Ron Adam wrote: I've worked on pydoc to make it much nicer to use in a browser. While you're at it. Can you please modernize the html and create a style sheet? Right now, all of formatting is deeply intertwined with content generation. > Fixing that would be a *huge* improvement. Half way there! The server will read one if it exists. ;-) I'd really like to get this part in before 3.2 beta, and then I'll add a basic style sheet and update the html code to use it for 3.3. The present patch fixes and updates all the functional parts and allows you to do every thing that you can do on the command line, but a LOT easier. I think You, Nick. or one of the other Core developers could probably have this finished up in an afternoon if you really wanted. All the parts work. It's more about checking and adjusting the packaging at this point. Cheers, Ron ___ 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] __setcall__
Robert Kern wrote: This thread is off-topic for python-dev, which is intended for the development *of* the Python interpreter, not development *in* Python. I got the impression that he was asking for a new feature -- i.e. to be allowed to write a call on the left of an assignment, with a corresponding special method. If that's the case, the appropriate place for initial discussion would be python-ideas. -- Greg ___ 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 10194 - Adding a gc.remap() function
--- On Tue, 10/26/10, P.J. Eby wrote: > If all you really want this for is reloading, it would > probably make more sense to simply modify the existing class > and function objects using the reloaded values as a > template, then save the modified classes and functions back > to the module. > > Have you tried http://pypi.python.org/pypi/plone.reload > or http://svn.python.org/projects/sandbox/trunk/xreload/xreload.py, > or any other existing code reloaders, or tried extending > them for your specific use case? I've investigated several reloading frameworks, including the ones you mentions as well as http://code.google.com/p/reimport/ and http://code.google.com/p/livecoding/. The approach of using the gc to remap references seemed to have the fewest overall limitations, but requiring C API changes is a big downside. I'm going to have to do a more detailed comparison of the features offered by each approach. --- On Tue, 10/26/10, exar...@twistedmatrix.com wrote: > This can be implemented with ctypes right now (I half did > it several years ago). > > Jean-Paul Is there a trick to doing it this way, or are you suggesting building a ctypes wrapper for each C type in the Python library, and then effectively reimplementing tp_traverse in Python? ___ 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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
On Oct 26, 2010, at 2:54 PM, Ron Adam wrote: > I've worked on pydoc to make it much nicer to use in a browser. While you're at it. Can you please modernize the html and create a style sheet? Right now, all of formatting is deeply intertwined with content generation. Fixing that would be a *huge* improvement. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __setcall__
On 10/26/10 5:05 PM, Bj Raz wrote: I'll look into SAGE, I am still curious if there is, a way, to write this in native python, cause I'm currently plotting in Autodesk Maya, and using Python. This thread is off-topic for python-dev, which is intended for the development *of* the Python interpreter, not development *in* Python. We should continue this discussion on python-list, instead: http://mail.python.org/mailman/listinfo/python-list That said, I will answer your question. No, there is no way to do this in Python. However, I don't think that is what the code you are trying to emulate does. It looks like it is building up a list of values, not defining a function. If you take your question over to python-list, I can explain more. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ 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 10194 - Adding a gc.remap() function
--- On Tue, 10/26/10, Neil Schemenauer wrote: > > I am happy to write up a PEP for this feature. > > I'll start that process now, though if anyone > > feels that this idea has no chance of > > acceptance please let me know. > > I think a feature that allows modules to be more > reliability reloaded could be accepted. Martin's > suggestion sounds like it could be useful. I would > recommend trying to limit the scope of the feature > and clearly define what it intends to achieve (e.g. > use cases). > The idea of replacing references does not seem to > have much hope, IMHO. I agree that the important feature is module reloading, whether it is implemented via remapping references or by replacing the state of existing objects is an implementation detail. I will try to keep the scope of the PEP focused, and if necessary I will split it up into two. Thanks, Peter ___ 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 10194 - Adding a gc.remap() function
At 10:24 AM 10/26/2010 -0700, Peter Ingebretson wrote: I have a relatively large application written in Python, and a specific use case where it will significantly increase our speed of iteration to be able to change and test modules without needing to restart the application. If all you really want this for is reloading, it would probably make more sense to simply modify the existing class and function objects using the reloaded values as a template, then save the modified classes and functions back to the module. Have you tried http://pypi.python.org/pypi/plone.reload or http://svn.python.org/projects/sandbox/trunk/xreload/xreload.py, or any other existing code reloaders, or tried extending them for your specific use case? ___ 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] __setcall__
I'll look into SAGE, I am still curious if there is, a way, to write this in native python, cause I'm currently plotting in Autodesk Maya, and using Python. Sent from my iPhone On Oct 24, 2010, at 12:51 PM, Benjamin Peterson wrote: > 2010/10/24 Bj Raz : >> I was looking for a way to set a function being equal to another function: >> q(m+1) = q(m)+ ((-1)^m) * exp(lnanswer); >> I was hoping to use something like this: >> (q).__setcall__.(m+1) = (q).__setcall__.(m)+ ((-1)^m) * exp(lnanswer); >> As a work around. >> But I have not found the `__setcall__' built in being there. >> >> Here is the code block I'm working with: >> >> indvar = 200; >> q = 0; >> lnanswer = 0; >> for m = 1:150 >> lnanswer = (3 * m) * log(indvar) - log(factorial(3 * m)) ; >> q(m+1) = q(m)+ ((-1)^m) * exp(lnanswer); >> end >> lnanswer >> q >> >> Any help would be appreciated. > > Please see python-list. This list is for the development of python. > > The SAGE math package can do something like this. > > > > -- > 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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
On 10/26/2010 02:34 PM, Raymond Hettinger wrote: FWIW, it wasn't that big (approx 2500 lines). The argparse, difflib, doctest, pickletools, pydoc, tarfile modules are about the same size and the decimal module is even larger. Please don't split those. Sense you mention this... I've worked on pydoc to make it much nicer to use in a browser. While doing that I needed to reworked the server part. That resulted in a clean server thread object (and supporting parts) with no pydoc specific code in those parts. It can work as a stand alone module quite nicely. It's about 170 lines with around a third of that as documented examples that can also run as doctests. More to the point, it's a simple text/html server wrapped in a thread object. It can work as a starting point to using a browser as a user interface like pydoc does. There is a patch in the bug tracker, I just need to make some minor updates to it and it can go in, but I really need some code organizing/placement review help. I I'm wonder what you may think. Keep it in pydoc or move it to the HTTP package? Document it or not? Ron ___ 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 10194 - Adding a gc.remap() function
On 08:28 pm, pinge...@yahoo.com wrote: --- On Tue, 10/26/10, "Martin v. L�wis" wrote: I think this then mandates a PEP; I'm -1 on the feature also. I am happy to write up a PEP for this feature. I'll start that process now, though if anyone feels that this idea has no chance of acceptance please let me know. This can be implemented with ctypes right now (I half did it several years ago). Jean-Paul ___ 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 10194 - Adding a gc.remap() function
Peter Ingebretson wrote: > I am happy to write up a PEP for this feature. I'll start that > process now, though if anyone feels that this idea has no chance of > acceptance please let me know. I think a feature that allows modules to be more reliability reloaded could be accepted. Martin's suggestion sounds like it could be useful. I would recommend trying to limit the scope of the feature and clearly define what it intends to achieve (e.g. use cases). The idea of replacing references does not seem to have much hope, IMHO. It presents all kinds of subtle problems. Dictionary hashing is only one of many invariants that could be broken by blindly replacing references. You have no way of knowing what other invariants are expected or if the new objects will satisfy them. Also, there would have to be a very compelling reason to change to the signature of "visitproc". Every Python module that participates in GC would have to be modified as a result of the signature change. Regards, Neil ___ 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 10194 - Adding a gc.remap() function
--- On Tue, 10/26/10, "Martin v. Löwis" wrote:
>>> I think this then mandates a PEP; I'm -1 on the feature also.
>>
>> I am happy to write up a PEP for this feature. I'll start that
>> process now, though if anyone feels that this idea has no chance of
>> acceptance please let me know.
>
> If it could actually work in a reasonable way, I would be +0. If,
> as I think, it can't possibly work correctly, I'll be -1.
>
> In this evaluation, I compare this to Smalltalk's
> Object>>#become:
> What you propose should have a similar effect, IMO, although
> it's probably not necessary to provide the two-way nature
> of become.
Thanks, I didn't know about Object>>#become until now but it
is a perfect comparison. The two-way nature of become appears to
be due to the implementation detail of swapping two entries in a
table, but the current spec for gc.remap can achieve the same effect
with:
>>> gc.remap({a:b, b:a})
Of course #become and gc.remap also share the same power and danger.
I'm retracting the patch in 10194 and will submit a new one later
as part of the PEP that uses a parallel traverse mechanism. Still,
if you are concerned that this approach cannot work I encourage you
to try out the patch associated with 10194 by playing around with
gc.remap in the interpreter or looking at the unit tests. I was
surprised when I made the change initially by how little code was
required and by how well it seemed to work in practice.
Thanks,
Peter
___
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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
On Tue, Oct 26, 2010 at 4:46 PM, Michael Foord wrote: > I find the big-ball-of-mud style development, where everything lives inside > huge monolithic modules, very painful. I also think that it is an extremely > bad example for new developers. Gadzooks, Michael! Something else we agree on. 2000-line modules are a source of maintenance pain. -Fred -- Fred L. Drake, Jr. "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] r85838 - python/branches/py3k/.gitignore
Le mardi 26 octobre 2010 09:31:11, Georg Brandl a écrit : > Am 25.10.2010 19:37, schrieb victor.stinner: > > Author: victor.stinner > > Date: Mon Oct 25 19:37:18 2010 > > New Revision: 85838 > > > > Log: > > update gitignore > > > > Added: > >python/branches/py3k/.gitignore > > This looks more like "Add gitignore". Do we really want to check in > ignore files for every possible DVCS? It's a mistake. I didn't want to commit this file. The changelog is "update" because I merged two or three commits about gitignore using git rebase -i, and I kept the wrong changelog. If it doesn't "hurt", keep it, otherwise you can delete it. As you want. But each time that I create a git-svn repository, I have to recreate this file. -- Victor Stinner http://www.haypocalc.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] Issue 10194 - Adding a gc.remap() function
Am 26.10.2010 22:28, schrieb Peter Ingebretson: > --- On Tue, 10/26/10, "Martin v. Löwis" wrote: >> I think this then mandates a PEP; I'm -1 on the feature also. > > I am happy to write up a PEP for this feature. I'll start that > process now, though if anyone feels that this idea has no chance of > acceptance please let me know. If it could actually work in a reasonable way, I would be +0. If, as I think, it can't possibly work correctly, I'll be -1. In this evaluation, I compare this to Smalltalk's Object>>#become: What you propose should have a similar effect, IMO, although it's probably not necessary to provide the two-way nature of become: 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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
On 26/10/2010 15:05, R. David Murray wrote: On Tue, 26 Oct 2010 10:39:19 -0700, Raymond Hettinger wrote: If someone wants to reorganize code for clarity, I would prefer keeping it within one file, bringing related functions together and using comment lines to mark the major sections. ISTM, this is cleaner than introducing a new directory and having multiple files that cross-import one another. +1 (or more) Really, you prefer to work in single multi-thousand line modules than cleanly split smaller packages? (Is that how you develop your own projects, out of interest?) The cross imports are unfortunate (there are very few actually circular dependencies in the package though I think), but more of an indictment on the design of unittest than the decision to split it into a package. How the splitting happened is that I proposed it on this list many months ago and got one reply in favour and no dissenters. Benjamin actually did the splitting. I find unittest *massively* easier to maintain and navigate now that it is a package. It doesn't take very long to work out where the classes live (no time at all if you look in the module names - where the classes live is *very* obvious except for the TextTestResult which lives alongside the TestRunner). The package split into modules is into conceptual units, where the responsibility of the units is clear. This makes the code not only easier to navigate but easier to *think about*. The structure of unittest is now much clearer. I find the big-ball-of-mud style development, where everything lives inside huge monolithic modules, very painful. I also think that it is an extremely bad example for new developers. There is something to be said for consistency within the standard library, but I don't think it is a price worth paying in this particular case. All the best, Michael Foord -- R. David Murray www.bitdance.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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ ___ 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 10194 - Adding a gc.remap() function
--- On Tue, 10/26/10, "Martin v. Löwis" wrote: > I think this then mandates a PEP; I'm -1 on the feature also. I am happy to write up a PEP for this feature. I'll start that process now, though if anyone feels that this idea has no chance of acceptance please let me know. Thanks, Peter ___ 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 bug week-end : 20-21 November
Am 26.10.2010 19:53, schrieb Brett Cannon: > Can whomever has edit access to the Python Google Calendar add this? Done. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
On Tue, 26 Oct 2010 12:34:30 -0700 Raymond Hettinger wrote: > > FWIW, it wasn't that big (approx 2500 lines). > The argparse, difflib, doctest, pickletools, pydoc, tarfile modules > are about the same size and the decimal module is even larger. > Please don't split those. I think it comes down to the preference of whoever works the most actively on it. Michael is the most active contributor to unittest by far, and I suppose he prefers it to be split into several submodules. 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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
On Oct 26, 2010, at 12:18 PM, Benjamin Peterson wrote: > 2010/10/26 Alexander Belopolsky : >> On Tue, Oct 26, 2010 at 1:39 PM, Raymond Hettinger >> wrote: >> .. >>> Packaging is not always wrong. Maybe it was the right thing to do for >>> unittest, maybe not. >> >> This is an example that I personally find ill-justified. Particularly >> annoying is the fact that opening __init__.py gives you a list of >> relative imports and sends you to the next file for everything else. >> Having both main.py and __main__.py seems redundant.What were the >> benefits that justified unittest.py split? > > Mostly it was huge. Now, it's huge and split across multiple files so it's harder to search, the class browser won't work, and the full source cannot be brought up immediately using just the module name. The svn annotations and history are munged-up. The components were highly interdependent so now every file has to start with a set of cross-imports. Well, at least the __init__.py is not full of code. That's something. FWIW, it wasn't that big (approx 2500 lines). The argparse, difflib, doctest, pickletools, pydoc, tarfile modules are about the same size and the decimal module is even larger. Please don't split those. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r85838 - python/branches/py3k/.gitignore
In article <20101026200234.5f8e8...@pitrou.net>,
Antoine Pitrou wrote:
> You could use own of the "official" mirrors at
> http://code.python.org/hg/
The "official" hg mirrors work great: in my experience, faster than svn
and simpler with all the useful history information retained from the
original svn repos. Thanks for that! As an example, for OS X TextMate
users out there, with up-to-date Mercurial and Subversion bundles, try
doing an Annotate on an hg clone of a Python branch vs a Blame on an svn
co. With the hg clones and the hg rebase extension (now a standard part
of hg), I've moved away from using hg mq patch queues for patch
development although I still use the svn repos (until the transition is
closer) and mq for installer build and regression testing.
FWIW, my hg workflow these days is to clone a local "master" clone for
each of 27, 31, and py3k repos from the official mirrors then just clone
working copies from my local masters as needed for each issue. Using a
local master speeds things up, potentially saves disk space as hg uses
hard links for local clones where possible, and saves on network
bandwidth. With work-in-progress committed to a working copy, I can
update automatically to the latest tip by a two-step update: update the
local master from the official mirror (via "pull") and then update the
working copy from the local master and use rebase to manage any new
merge conflicts. I couldn't quite get the two-stage pulls to completely
work using one standard hg command so I wrote a "pull-clone" script that
does the trick for me:
import ConfigParser
import os.path
import subprocess
import sys
HG_DEFAULTS = '.hg/hgrc'
HG_BIN = '/opt/local/bin/hg'
if not os.path.exists(HG_DEFAULTS):
sys.exit('No hg repository here')
else:
config = ConfigParser.ConfigParser()
config.read(HG_DEFAULTS)
try:
default = config.get('paths', 'default')
except ConfigParser.NoSectionError, ConfigParser.NoOptionError:
default = ''
if default.startswith('/'):
subprocess.check_call([HG_BIN, 'pull', '-R', default],
cwd=default)
subprocess.check_call([HG_BIN, 'pull', '-u', '--rebase'])
subprocess.check_call([HG_BIN, 'summary', '--remote'])
--
Ned Deily,
n...@acm.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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
2010/10/26 Alexander Belopolsky : > On Tue, Oct 26, 2010 at 1:39 PM, Raymond Hettinger > wrote: > .. >> Packaging is not always wrong. Maybe it was the right thing to do for >> unittest, maybe not. > > This is an example that I personally find ill-justified. Particularly > annoying is the fact that opening __init__.py gives you a list of > relative imports and sends you to the next file for everything else. > Having both main.py and __main__.py seems redundant. What were the > benefits that justified unittest.py split? Mostly it was huge. -- 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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
On Tue, 26 Oct 2010 10:39:19 -0700, Raymond Hettinger wrote: > If someone wants to reorganize code for clarity, I would prefer keeping > it within one file, bringing related functions together and using > comment lines to mark the major sections. ISTM, this is cleaner than > introducing a new directory and having multiple files that cross-import > one another. +1 (or more) -- R. David Murray www.bitdance.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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
On Tue, Oct 26, 2010 at 1:39 PM, Raymond Hettinger wrote: .. > Packaging is not always wrong. Maybe it was the right thing to do for > unittest, maybe not. This is an example that I personally find ill-justified. Particularly annoying is the fact that opening __init__.py gives you a list of relative imports and sends you to the next file for everything else. Having both main.py and __main__.py seems redundant.What were the benefits that justified unittest.py split? ___ 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] r85838 - python/branches/py3k/.gitignore
On Tue, 26 Oct 2010 10:42:27 -0700 Ned Deily wrote: > In article <20101026085124.4c684...@mission>, > Barry Warsaw wrote: > > On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote: > > >On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl wrote: > > >> This looks more like "Add gitignore". Do we really want to check in > > >> ignore files for every possible DVCS? > > > > > >No, but supporting the current big four open source ones (svn, hg, > > >bzr, git) seems reasonable enough. > > > > +1. A couple of extra dot files never hurt anyone. :) > > Actually they have. I got burned a while back by the checked-in > .hgignore file when creating my own hg repo (to use mq patch management) > on top of a svn checkout. You could use own of the "official" mirrors at http://code.python.org/hg/ cheers 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] Issue 10194 - Adding a gc.remap() function
Am 26.10.2010 19:24, schrieb Peter Ingebretson: > --- On Tue, 10/26/10, Benjamin Peterson wrote: >> Is there any reason that you'd want to do this? >>> http://doublestar.org/python-hot-loading-prototype/ > > I have a relatively large application written in Python, and a > specific use case where it will significantly increase our speed > of iteration to be able to change and test modules without needing > to restart the application. We have experimented with different > approaches to reloading and this one seems the most promising by > a wide margin. I think this then mandates a PEP; I'm -1 on the feature also. In the PEP, you should explain what the alternatives are and why they don't work in the use cases of this feature. For example, I wonder why just changing the classes to have the updated methods isn't good enough. Or, if you want to be able to change the class of all instances of that class, why you can't track all instances explicitly. In the PEP, you should then also explain what the limitations of the feature should. I.e. the feature should not be specified by its implementation, but have some abstract specification. 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] Python bug week-end : 20-21 November
Can whomever has edit access to the Python Google Calendar add this? On Mon, Oct 25, 2010 at 14:03, Antoine Pitrou wrote: > > Hello, > > The development team of the Python interpreter (a.k.a python-dev) is > organizing a bug week-end on Saturday 20th and Sunday 21st of November. > > We would like to encourage anyone who feels interested in participating > to give it a try. Contributing to Python is much less intimidating than > it sounds. You don't need to have previous experience with modifying > the Python source; in fact bug days offer a good opportunity to learn > the basics by asking questions and working on relatively simple bugs > (see "how to get prepared" below). And most core developers are actual > human beings! > > How it happens > -- > > The bug week-end will happen on the #python-dev IRC channel on the > Freenode network, where several core developers routinely hang out. No > physical meeting is scheduled as far as I know, but anyone is > encouraged to organize one and announce it on the official Python > channels such as this one. > > Participants (you!) join #python-dev and collaboratively go through the > Python issue tracker at http://bugs.python.org . From there, you can > provide patches and/or review existing patches. Also, you can help us > assess issues on any specific topic you have expertise in (the range of > topics touched in the stdlib is quite broad and it is more than likely > that the core developers' expertise is lacking in some of them). > > Or, if you feel shy, you can simply watch other people work and > slowly get more confident about participating yourself. > Development is public and lurkers are welcome. > > What you can work on > - > > Our expectation is that Python 3.2 beta 1 will have been released a > couple of days before the bug week-end and, therefore, one primary goal > is to polish the 3.2 branch for the following betas and the final > release. There are many issues to choose from on the bug tracker; any > bug fixes or documentation improvements will do. New features are > discouraged: they can't be checked in before the official 3.2 release. > > How to get prepared > --- > > If you are a beginner with the Python codebase, you may want to read the > development guide available here (courtesy of Brian Curtin): > http://docs.pythonsprints.com/core_development/beginners.html > > There's a small practical guide to bug days/week-ends on the wiki: > http://wiki.python.org/moin/PythonBugDay > > And the development FAQ holds answers to generic development questions: > http://www.python.org/dev/faq/ > > You can also do all of the above during the bug week-end, of course. > Please, don't hesitate to ask us questions on the #python-dev channel. > > 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/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] r85838 - python/branches/py3k/.gitignore
In article <20101026085124.4c684...@mission>, Barry Warsaw wrote: > On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote: > >On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl wrote: > >> This looks more like "Add gitignore". Do we really want to check in > >> ignore files for every possible DVCS? > > > >No, but supporting the current big four open source ones (svn, hg, > >bzr, git) seems reasonable enough. > > +1. A couple of extra dot files never hurt anyone. :) Actually they have. I got burned a while back by the checked-in .hgignore file when creating my own hg repo (to use mq patch management) on top of a svn checkout. Now that I know they are there, I ensure they get deleted. -- Ned Deily, n...@acm.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
[Python-Dev] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
On Oct 26, 2010, at 9:31 AM, Guido van Rossum wrote: > I would like Gregor Lingl's approval of turning turtle.py into a package. It > might make some things harder for novices, e.g. trackebacks and just browsing > the source code. > > Also many people don't expect to find any code in a file named __init__.py > (and most of the time I agree with this). But the alternative isn't so great > either, assuming we'll want strict backwards compatibility (I wouldn't want > the instructions in Gregor's or anyone's book to start failing because of > this). You can't rename turtle to turtle/turtle.py either, because then > there'd be horrible confusion between turtle/ and turtle.py. > > IOW, yes, flat still seems better than nested here! Thanks for saying this. It might be a good time to also have a discussion about what may be an emerging trend of wanting to split standard library modules into packages. I understand the urge to split longer modules into multiple source files but would like to mention some of the advantages of keeping modules in a single source file. Taking the decimal module as an example: * Right now, I can pull up the source and entire history from subversion by knowing just the module name: http://svn.python.org/view/python/branches/py3k/Lib/decimal.py?view=markup , and I can search the entire module with nothing more sophisticated than "find" in the web browser. That no longer works with unittest. * I can easily email the file to someone or copy it back to a previous version of Python because only one file is involved. To look at the code, I don't have to guess how someone would have partitioned it into decimal.context.utils.threadlocal.py or somesuch. I don't need a packaging tool to distribute a module (pyparsing and BeautifulSoup are two examples of tools that are easily managed by just being in one file). * Some editors are set up to easily dance across multiple files and directories as if they were a single unit; however, many editors are not. Most file viewers and editors work better with single files.Take two operations in IDLE for example. If I press Alt-M for open module, I can retrieve all of the source for decimal (but this won't work with the logging or unittest packages). Once the source is visible, I press Alt-C to bring up a class browser for quickly reviewing the source (but this also won't work with packages). Several Python editors have this capability (provided by the pyclbr module) but they are defeated by packaging. * The Lib directory is more easily grepped when it is flat. The more we nest the Lib directory, the harder it will be to search the sources (while excluding the test directory). Packaging is not always wrong. Maybe it was the right thing to do for unittest, maybe not. I just wanted to bring up some of the advantages of having a single file for a library module. It would not be a good thing if some of the newer committers embarked on taking modules over 2000 lines and split them into packages. Right now, we have hundreds of source files, but it wouldn't take long for someone on a packaging mission to turn that into thousands. If someone wants to reorganize code for clarity, I would prefer keeping it within one file, bringing related functions together and using comment lines to mark the major sections. ISTM, this is cleaner than introducing a new directory and having multiple files that cross-import one another. Raymond___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 10194 - Adding a gc.remap() function
--- On Tue, 10/26/10, Benjamin Peterson wrote: > Is there any reason that you'd want to do this? > > http://doublestar.org/python-hot-loading-prototype/ I have a relatively large application written in Python, and a specific use case where it will significantly increase our speed of iteration to be able to change and test modules without needing to restart the application. We have experimented with different approaches to reloading and this one seems the most promising by a wide margin. > Overall, I think this adds lots of backwards incompatible > code for an obscure use-case that will cause subtle and > complicated bugs. So, -1. Would you still object to the change if (visitproc), Py_VISIT and tp_traverse were reverted to their previous state, and a separate path was added for modifying references using (visitchangeproc), Py_VISIT_CHANGE, and tp_traverse_change? Thanks, Peter ___ 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 10194 - Adding a gc.remap() function
--- On Tue, 10/26/10, Hrvoje Niksic wrote: > What about objects that don't implement tp_traverse because > they cannot take part in cycles? A significant majority of objects that can hold references to other objects can take part in cycles and do implement tp_traverse. My original thought was that modifying any references not visible to the cyclic GC would be out of the scope of gc.remap. Even adding a 'tp_extended_traverse' method might not help solve this problem because untracked objects are not in any generation list, so there is no general way to find all of them. > Changing immutable objects such as tuples and frozensets > doesn't exactly sound appealing. My original Python-only approach cloned immutable objects that referenced objects that were to be remapped, and then added the old and new immutable object to the mapping. This worked well, although it was somewhat complicated because it had to happen in dependency order (e.g., to handle tuples of tuples in frozensets). I thought about keeping this, but I am now convinced that as long as you are doing something as drastic as changing references in the heap you may as well change immutable objects. The main argument is that preserving immutable objects increases the complexity of remapping and does not actually solve many problems. The primary reason for objects to be immutable is so that their comparison operators and hash value can remain consistent. Changing, for example, the contents of a tuple that a dictionary key references has the same effect as changing the identity of the tuple -- both modify the hash value of the key and thus invalidate the dictionary. The full reload processs needs to rehash collections invalidated by hash values changing, so we might as well modify the contents of tuples. > > the signature of visitproc has been modified to take (PyObject **) > > instead of (PyObject *) so that a visitor can modify fields > > visited with Py_VISIT. > > This sounds like a bad idea -- visitproc is not limited to > visiting struct members. Visited objects can be stored > in data structures where their address cannot be directly > obtained. > > If you want to go this route, rather create an extended > visit procedure (visitchangeproc?) that accepts a function > that can change the reference. A convenience function > or macro could implement this for the common case of struct > member or PyObject**. This is a compelling argument. I considered adding an extended traverse / visit path, but decided against it after not finding any cases in the base distribution that required it. The disadvantage of creating an additional method is that C types will have yet another method to implement for the gc (tp_traverse, tp_clear, and now tp_traverse_modify(?)). On the other hand, you've convinced me that this is necessary in some cases, so it might as well be used in all of them. Jon Parise also pointed out in a private communication that this eliminates the minor performance impact on tp_traverse, which is another advantage over my change. If a 'tp_traverse_modify' function were added, many types could replace their custom tp_clear function with a generic method that makes use of (visitchangeproc), which somewhat mitigates adding another method. ___ 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 10194 - Adding a gc.remap() function
2010/10/26 Peter Ingebretson : > I have a patch that adds a new function to the gc module. The gc.remap() > function uses the tp_traverse mechanism to find all references to any keys > in a provided mapping, and remaps these references in-place to instead point > to the value corresponding to each key. > > The motivation for adding this method is to enable writing a module that > provide an enhanced version of imp.reload. The builtin reload function > is very useful for iterating on a single module within the Python interpreter > shell, but in more complex situations it very limited. Is there any reason that you'd want to do this? ... > http://doublestar.org/python-hot-loading-prototype/ > > Please let me know if you have any feedback on the reloading proposal, the > hot loading prototype, or on the patch. Overall, I think this adds lots of backwards incompatible code for an obscure use-case that will cause subtle and complicated bugs. So, -1. -- 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] r85838 - python/branches/py3k/.gitignore
On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote: >On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl wrote: >> This looks more like "Add gitignore". Do we really want to check in >> ignore files for every possible DVCS? > >No, but supporting the current big four open source ones (svn, hg, >bzr, git) seems reasonable enough. +1. A couple of extra dot files never hurt anyone. :) -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] Change to logging Formatters: support for alternative format styles
Nick Coghlan gmail.com> writes: > Looking at your checkin though, I wonder if it might be worth > implementing some little formatting style classes to get rid of the > if/elif chains from the Formatter code. Something like: Fair comment: I did think about the messiness of that if/elif, but considered it OK as it was likely that Python would not grow any more formatting approaches. However, I hadn't thought about user-defined approaches; what you're suggesting is more extensible. I'll incorporate your and Boštjan's comments in the next checkin. Thanks, Vinay ___ 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] Change to logging Formatters: support for alternative format styles
Line 31 (in Pastebin): _STYLE_CODES = tuple("% { $".split())
Is this really necessary? Why not
_STYLE_CODES = ('%', '{', '$')
On Tue, Oct 26, 2010 at 1:15 PM, Nick Coghlan wrote:
> On Tue, Oct 26, 2010 at 9:08 PM, Nick Coghlan wrote:
> > On Tue, Oct 26, 2010 at 12:28 AM, Vinay Sajip
> wrote:
> >> Comments welcome. Assuming there are no strong objections asking for
> reversion
> >> of this change, I'll publicise to the wider community in a few days.
> >
> > It strikes me as a solid, pragmatic solution to a thorny problem.
> >
> > Looking at your checkin though, I wonder if it might be worth
> > implementing some little formatting style classes to get rid of the
> > if/elif chains from the Formatter code. Something like:
>
> Some syntax highlighting may make that wall-o'-code a little easier to
> read: http://pastebin.com/SG0Qr3r5
>
> 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/bostjan.mejak%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] r85838 - python/branches/py3k/.gitignore
On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl wrote: > This looks more like "Add gitignore". Do we really want to check in > ignore files for every possible DVCS? No, but supporting the current big four open source ones (svn, hg, bzr, git) seems reasonable enough. 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] Change to logging Formatters: support for alternative format styles
On Tue, Oct 26, 2010 at 9:08 PM, Nick Coghlan wrote: > On Tue, Oct 26, 2010 at 12:28 AM, Vinay Sajip wrote: >> Comments welcome. Assuming there are no strong objections asking for >> reversion >> of this change, I'll publicise to the wider community in a few days. > > It strikes me as a solid, pragmatic solution to a thorny problem. > > Looking at your checkin though, I wonder if it might be worth > implementing some little formatting style classes to get rid of the > if/elif chains from the Formatter code. Something like: Some syntax highlighting may make that wall-o'-code a little easier to read: http://pastebin.com/SG0Qr3r5 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] Change to logging Formatters: support for alternative format styles
On Tue, Oct 26, 2010 at 12:28 AM, Vinay Sajip wrote:
> Comments welcome. Assuming there are no strong objections asking for reversion
> of this change, I'll publicise to the wider community in a few days.
It strikes me as a solid, pragmatic solution to a thorny problem.
Looking at your checkin though, I wonder if it might be worth
implementing some little formatting style classes to get rid of the
if/elif chains from the Formatter code. Something like:
# Style objects
class PercentStyle(object):
default_format = "%(message)"
def is_asctime_in_format(fmt):
return fmt.find("%(asctime)") >= 0
def format_record(fmt, record):
return fmt % record.__dict__
class StrFormatStyle(object):
default_format = "{message}"
def is_asctime_in_format(fmt):
return fmt.find("{asctime}") >= 0
def format_record(fmt, record):
return fmt.format(**record.__dict__)
from string import Template # Top level, embedding may cause import
deadlock issues
class StringTemplateStyle(object):
def __init__(self):
self._fmt = self._tmpl = None # Setup for format_record
default_format = "${message}"
def is_asctime_in_format(fmt):
return fmt.find("$asctime") >= 0 or fmt.find("${asctime}") >= 0
def format_record(fmt, record):
if fmt != self._fmt:
self._fmt = fmt
self._tmpl = Template(fmt)
return self._tmpl.substitute(**record.__dict__)
# Build style map
_STYLE_CODES = tuple("% { $".split())
_STYLES = PercentStyle, StrFormatStyle, StringTemplateStyle
_STYLE_MAP = dict(zip(_STYLE_CODES, _STYLES))
# Interpretation of the style parameter in Formatter.__init__
if style not in _STYLE_CODES:
# Preserve option to allow arbitrary style objects at some point in the future
raise ValueError("Style must be one of {!r}".format(_STYLE_CODES))
self._style = _STYLE_MAP[style]()
# self._fmt initialisation if/elif chain replacement
self._fmt = self._style.default_format
# Time check if/elif chain replacement
result = self._style.is_asctime_in_format(self._fmt)
# Record formatting if/elif chain replacement
s = self._style.format_record(self._fmt, record)
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 10194 - Adding a gc.remap() function
On 10/26/2010 07:04 AM, Peter Ingebretson wrote: I have a patch that adds a new function to the gc module. The gc.remap() function uses the tp_traverse mechanism to find all references to any keys in a provided mapping, and remaps these references in-place to instead point to the value corresponding to each key. What about objects that don't implement tp_traverse because they cannot take part in cycles? Changing immutable objects such as tuples and frozensets doesn't exactly sound appealing. A potentially controversial aspect of this change is that the signature of the visitproc has been modified to take (PyObject **) as an argument instead of (PyObject *) so that a visitor can modify fields visited with Py_VISIT. This sounds like a bad idea -- visitproc is not limited to visiting struct members. Visited objects can be stored in data structures where their address cannot be directly obtained. For example, in C++, you could have an std::map with PyObject* keys, and it wouldn't be legal to pass addresses of those. Various C++ bindings also implement smart_ptr-style wrappers over PyObject* that handle Python reference counting, and those will also have problems with visitproc taking PyObject **. And this is not just some oddball C++ thing. Many extensions wrap arbitrary C objects which can reach Python data through other C objects, which expose the PyObject* only through a generic "void *get_user_data()"-style accessor. For such objects to cooperate with the GC, they must be able to visit arbitrary PyObject pointers without knowing their address. PyGTK and pygobject are the obvious examples of this, but I'm sure there are many others. If you want to go this route, rather create an extended visit procedure (visitchangeproc?) that accepts a function that can change the reference. A convenience function or macro could implement this for the common case of struct member or PyObject**. ___ 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] r85838 - python/branches/py3k/.gitignore
Am 25.10.2010 19:37, schrieb victor.stinner: > Author: victor.stinner > Date: Mon Oct 25 19:37:18 2010 > New Revision: 85838 > > Log: > update gitignore > > Added: >python/branches/py3k/.gitignore This looks more like "Add gitignore". Do we really want to check in ignore files for every possible DVCS? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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
