Re: [Python-Dev] I have submitted a patch that implement IrDA socket support .
Yingbo Qiu wrote: > Will anyone have interest in the patch? This patch comes to late for Python 2.5. It might be considered for 2.6, if anybody has time to review it. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
On Friday 14 July 2006 22:45, Jeremy Hylton wrote: > Maybe the basic question is right, but the emphasis needs to be > changed. If we had a rule that said the final release was 90 days > after the last submission that wasn't to fix a regression, we'd ask > "Is this feature important enough to warrant delaying the release > until three months from now?" I'm not sure what I think, but it > doesn't seem like an implausible policy. I really really doubt that this would work. There's always pressure for "just one more feature" - and as the release drags on, this would increase, not decrease. Note that dragging the release process out has it's own costs, as mentioned previously - either the trunk is in some sort of near-frozen state for an extended period, or else we end up in the double-applying-bugfixes state by forking much earlier. This approach would also make it extremely difficult to plan for releases. I know that my free time varies across the course of the year, and I need _some_ sort of plan for when the release will happen so I can make sure I have the time free to spend on it. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dynamic module namspaces
On Sun, Jul 16, 2006 at 11:52:48PM -0700, Josiah Carlson wrote: > Andrew Bennetts <[EMAIL PROTECTED]> wrote: [...] > > > > Have you seen the "demandload" hack that Mercurial uses? You can find it > > here: > > http://selenic.com/repo/hg?f=cb4715847a81;file=mercurial/demandload.py > > > > You can see an example use of it here: > > http://selenic.com/repo/hg?f=d276571f2c4b;file=mercurial/commands.py > > The problem with that particular method is that it requires that you use > a string to describe the set of modules you would like to import, rather > than a name. I agree, it's ugly. I'd like there to be a nicer solution. > In the py3k mailing list I recently described a mechanism (though not > implementation) for a somewhat related method to support automatic > reloading when a file has changed (for things like web frameworks), but > by removing that file change check, you get the equivalent to what you > describe, though you don't need to use strings, you can use names... > > from dynamicreload import DR > > and used like... > > DR.os.path.join(...) > > As long as you use the DR.-prefixed name, you get automatic reloading > (if desired) on access. Aside from also being ugly in its own way, a magic prefix like this would add a small performance penalty to places that use it. I believe demandload has the nice feature that once a demandloaded object is accessed, it is replaced with the actual object rather than the demandload gunk, so there's only a one-off performance penalty. > > The advantage for an interactive command line tool isn't so much memory > > consumption as speed. Why waste hundreds of milliseconds importing code > > that > > isn't used? There's an experimental branch to use the same demandload code > > in > > bzr, the reported results are "400ms for 'bzr rocks' down to 100ms, 'bzr > > root' > > from 400ms => 200ms, etc." (according to > > http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/13967) > > > > Over half the runtime wasted on importing unused code! There's a definite > > need > > for a nice solution to this, and it should be included in the standard > > batteries that come with Python. > > Well, just starting up Python without loading any modules can be time > consuming; perhaps even dwarfing the few hundred ms saved by dynamic > loading. Well, it's only about 10ms on my laptop running Ubuntu (it varies up to 90ms, but I expect that's just noise), and the "-S" switch makes no obvious difference (tested with "python -c ''"). 10ms overhead to start python I can live with. It takes about that long run "svn --version". > > If we can address related problems at the same time, like emitting > > deprecation > > warnings for accessing certain module attributes, then even better! > > __deprecated__ = ['name1', ...] > > Make your dynamic load/reload aware of the __deprecated__ attribute, and > you are done. I'm fine with that syntax. But regardless of how it's spelled, I'd really like the standard library or interpreter to have support for it, rather than having a non-standard 3rd-party system for it. I want there to "be one-- and preferably only one --obvious way to do it". -Andrew. ___ Python-Dev mailing list [email protected] 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 Style Sheets ? Re: User's complaints
Guido van Rossum wrote: > You must be misunderstanding. I don't think so. You appeared to say that the language changes too much because everyone wants different changes - that accumulate. I suggested a mechanism allowing people to see only the changes they want - or none at all - might be devised. Regards, BB > The root problem is that people > (rightly) complain that the language changes too much. And you want to > "fix" this by adding a deep and fundamental change to the language? > What planet are you from? It reminds me of Jini, which was presented > as a new standard to address the problem of too many conflicting > standard. Get it? :-) > > --Guido > > On 7/14/06, Boris Borcic <[EMAIL PROTECTED]> wrote: >> Guido van Rossum wrote: >> ... >>> This is an illustration of the dilemma of maintaining a popular >>> language: Everybody hates change (me too!) but everybody also has one >>> thing that's bothering them so much they absolutely want it to be >>> changed. If you were to implement all those personal pet peeves, you'd >>> get a language that's more different from Python than Python is from >>> Fortran. >>> >>> So where's the middle ground? >> I feel some freedom could be reclaimed with a solution in the spirit of >> Turing >> equivalence. Or, to take a less grandiose comparison, web style sheets - >> separation of content and presentation. >> >> Suppose the standard required a (possibly empty) style-defining file prefix >> that >> constrains the python source code in the file, and concurrently defined >> (mostly) >> reversible and transparent source-to-source transforms that would map any >> source >> code file to an equivalent source code file with an arbitrary chosen prefix. >> Then users could chose their style of Python and either transform all source >> files they install to their own style, or setup their editor to do it >> back-and-forth for them. The choice of python presentation style would then >> become a private choice. >> >> To illustrate the idea, this already exists in very embryonic form with >> unicode >> encoding modelines. The current standard allows to imagine a Python editor >> that >> would permit to set a "local standard encoding modeline" and then present any >> source file as if it had been written while taking maximal profit from the >> chosen encoding. Which may also be simple ascii. >> >> Cheers, BB >> -- >> "C++ is a contradiction in terms" - Lorentz, Einstein, Poincaré >> >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pronouncement on SF #1520294 sought
Barry Warsaw wrote: > Just as 2.5b2 was being release, I updated SF patch #1520294: > > https://sourceforge.net/tracker/index.php? > func=detail&aid=1520294&group_id=5470&atid=305470 > > This fixes the pydoc, inspect, and types modules for built-in types > like getset and member descriptors. I'm not sure if Georg has had a > chance to look over the latest rev of the patch (which is currently > assigned to him). I have now reviewed it and added a comment to the patch. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dynamic module namspaces
Andrew Bennetts wrote:
> On Sat, Jul 15, 2006 at 03:38:04PM -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) of which many are classes or
>> interfaces (150+)
>
> Have you seen the "demandload" hack that Mercurial uses? You can find it
> here:
> http://selenic.com/repo/hg?f=cb4715847a81;file=mercurial/demandload.py
It seems quite similar to Philips Importer, it's not completely solving the
problem I'm having, since I do something like this:
class LazyNamespace(ModuleType):
def __init__(self, realmodule, locals):
attributes = {}
for attr in realmodule._get_lazy_attribute_names():
attributes[attr] = None
def __getattribute__(_, name):
if name in attributes:
value = realmodule._construct_lazy_attribute(name)
...
return value
There are almost 1000 symbols in the gtk namespace, creating all of them at
import time wastes memory and speed, while I've been mainly looking at the
memory consumption speed will also benefit. Importing gtk at this point
quite fast actually, less than 200ms on my fairly old box.
GUI programs does not need to be as responsive as command line applications
as hg & bzr, users seems to accept that it takes a second or a few to start
up a GUI application.
--
Johan Dahlin <[EMAIL PROTECTED]>
Async Open Source
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
Anthony Baxter wrote: > On Friday 14 July 2006 22:45, Jeremy Hylton wrote: >> Maybe the basic question is right, but the emphasis needs to be >> changed. If we had a rule that said the final release was 90 days >> after the last submission that wasn't to fix a regression, we'd ask >> "Is this feature important enough to warrant delaying the release >> until three months from now?" I'm not sure what I think, but it >> doesn't seem like an implausible policy. > > I really really doubt that this would work. There's always pressure > for "just one more feature" - and as the release drags on, this would > increase, not decrease. Note that dragging the release process out > has it's own costs, as mentioned previously - either the trunk is in > some sort of near-frozen state for an extended period, or else we end > up in the double-applying-bugfixes state by forking much earlier. > > This approach would also make it extremely difficult to plan for > releases. I know that my free time varies across the course of the > year, and I need _some_ sort of plan for when the release will happen > so I can make sure I have the time free to spend on it. On the face of it, it seems to me that branching a new major release at the 1st beta would be one way of managing this. The trunk is not frozen for an extended period, and any "features" and bug fixes could probably be backported from the trunk on clearance from the RE with no more pain than is currently endured. One down side would be the possibility of a loss in emphasis in finishing the job on the release to be. I'm sure there are others... - Andrew I MacIntyre "These thoughts are mine alone..." E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dynamic module namspaces
James Y Knight wrote: > > On Jul 15, 2006, at 2:38 PM, Johan Dahlin wrote: >> What I want to ask, is it possible to have a sanctioned way to implement >> a dynamic module/namespace in python? >> >> For instance, it could be implemented to allow you to replace the >> __dict__ attribute in a module with a user provided object which >> implements the dictionary protocol. > > I'd like this, as well, although my use case is different: I'd like to > be able to deprecate attributes in a module. That is, if I have: > > foo.py: > SOME_CONSTANT = 5 > > I'd like to be able to do something such that any time anyone accessed > foo.SOME_CONSTANT, it'd emit a DeprecationWarning. Agreed, this would be another nice feature to have. I've did something similar a time ago for PyGTK aswell, while less elegant than your proposed solution, it seems that it's working fairly well: DeprecatedConstant can be found here: http://cvs.gnome.org/viewcvs/pygtk/gtk/deprecation.py?view=markup -- Johan Dahlin <[EMAIL PROTECTED]> Async Open Source ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dynamic module namspaces
Phillip J. Eby wrote: > Just as a point of reference, the Importing package does something very > similar, to support "weak" and "lazy" imports: > > http://cheeseshop.python.org/pypi/Importing Interesting, I was not aware of that, thanks for the pointer. Another reason for including this feature in the standard library ;-) > The things most likely to be problems are tools like pydoc or other > inspect-using code that expects modules to be exactly ModuleType and > don't use isinstance(). Apart from that, I've been using the technique > since the early days of Python 2.2 without encountering any problems > until the PEP 302 "reload()" bug came along, but that was fixed in > 2.3.5. I haven't seen any other problems since. I'd argue that pydoc & friends are broken if they assume that a module will always be of ModuleType and not a subclass of it. > On the other hand, the Importing package takes a much more conservative > approach than you are doing; it simply runs reload() on a module when > __getattribute__ is called (after restoring the old version of > __getattribute__). So, as soon as you touch a lazily loaded module, it > ceases to be particularly special, and it has a real __dict__. It's > possible that what you're doing could have more side-effects than what > I'm doing. This is an interesting approach, I thought of using that but I didn't quite manage to find the time to implement it properly. However, for the gtk namespace this won't be enough, since I want to avoid creating all the types when the first one is accessed; when gtk.Button is accessed it, gtk.Window will still not be created. >> What I want to ask, is it possible to have a sanctioned way to implement >> a dynamic module/namespace in python? > > That would be nice, but I think that what you and I are doing are > probably the One Obvious Ways to do the respective things we're doing. I consider __getattribute__ a hack, being able to override __dict__ is less hackish, IMHO. -- Johan Dahlin <[EMAIL PROTECTED]> Async Open Source ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
On Monday 17 July 2006 20:27, Andrew MacIntyre wrote: > On the face of it, it seems to me that branching a new major > release at the 1st beta would be one way of managing this. The > trunk is not frozen for an extended period, and any "features" and > bug fixes could probably be backported from the trunk on clearance > from the RE with no more pain than is currently endured. > > One down side would be the possibility of a loss in emphasis in > finishing the job on the release to be. I'm sure there are > others... The major one is the doubling of the workload for bugfixes. SVN is better than CVS, but it's still not great when it comes to backporting fixes between branches. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dynamic module namspaces
On Mon, 17 Jul 2006 10:29:22 -0300, Johan Dahlin <[EMAIL PROTECTED]> wrote: >I consider __getattribute__ a hack, being able to override __dict__ is less >hackish, IMHO. Why do you feel one is more "hackish" than the other? In my experience the opposite is true: certain C APIs expect __dict__ to be a "real" dictionary, and if you monkey with it they won't call the overridden functions you expect, whereas things accessing attributes will generally call through all the appropriate Python-level APIs. This makes sense to me for efficiency reasons and for clarity as well; if you're trawling around in a module's __dict__ then you'd better be ready for what you're going to get - *especially* if the module is actually a package. Even in "normal" python code, packages can have names which would be bound if they were imported, but aren't yet. ___ Python-Dev mailing list [email protected] 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 Style Sheets ? Re: User's complaints
Boris Borcic <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > You must be misunderstanding. > > I don't think so. You appeared to say that the language changes too much > because > everyone wants different changes - that accumulate. I suggested a mechanism > allowing people to see only the changes they want - or none at all - might be > devised. Let us imagine that such a system were devised and implemented. Invariably user X and Y would have different sets of changes that they want to use. Presumably, if the features were nontrivial, then they would no longer be able to exchange code because it would have been directed at a different 'version' of Python, whose syntax or semantics were different. What you are suggesting is essentially built-in language fragmentation, which is quite a bad idea. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem with super() usage
On 7/16/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > For about the third time in my life, I thought I might > have found a use for cooperative super calls, but I've > run into another problem with the concept. > > Consider: > > class A(object): >def m(self): > print "A.m" > > class B(object): >def m(self): > print "B.m" > super(B, self).m() > > class C(B, A): >def m(self): > print "C.m" > super(C, self).m() > > >>> c = C() > >>> c.m() > C.m > B.m > A.m > > Okay so far, but... what if I want to use class B on > its own, or in combination with other classes that don't > have an m() method? > > >>> b = B() > >>> b.m() > B.m > Traceback (most recent call last): >File "", line 1, in ? >File "", line 4, in m > AttributeError: 'super' object has no attribute 'm' > > In general, how is one supposed to use super() in a > class which may or may not be at the end of the mro > with respect to a particular method? One isn't. In the world where cooperative multiple inheritance originated (C++), this would be a static error. You can only use super when you're overriding a method, not when you're defining a new method. To do what you want to do in such a world, you'd have to create a base class with a dummy implementation and inherit from that. You can do that in Python, too. > The only thing I can think of is to write all my > super()-using methods defensively like this: > >def m(self): > ... > s = super(C, self) > if hasattr(s, 'm'): >s.m() > > which seems awfully tedious. Definitely don't that. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
Hi Jeroen, On Thu, Jul 13, 2006 at 02:02:22PM +0200, Jeroen Ruigrok van der Werven wrote: > He doesn't specifically need the builtin types to be extendable. It's > just nice to be able to define a single class in multiple modules. There are various simple ways to do this; the one I'm using from time to time is the "extendabletype" metaclass from: http://codespeak.net/svn/pypy/dist/pypy/annotation/pairtype.py Example: class A: __metaclass__ = extendabletype def f(...): ... Somewhere else: class __extend__(A): def g(...): ... FWIW the above 30-lines file also contains a fast double-dispatch multimethod implementation :-) A bientot, Armin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
Hi Bob, On Thu, Jul 13, 2006 at 12:58:08AM -0700, Bob Ippolito wrote: > > @main > > def whatever(): > > ... > > It would probably need to be called something else, because main is > often the name of the main function... Ah, but there is theoretically no name clash here :-) @main # <- from the built-ins def main(): # <- and only then set the global ... Just-making-a-stupid-point-and-not-endorsing-the-feature-ly yours, Armin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
On Jul 17, 2006, at 11:25 AM, Armin Rigo wrote: > Hi Bob, > > On Thu, Jul 13, 2006 at 12:58:08AM -0700, Bob Ippolito wrote: >>> @main >>> def whatever(): >>> ... >> >> It would probably need to be called something else, because main is >> often the name of the main function... > > Ah, but there is theoretically no name clash here :-) > > @main # <- from the built-ins > def main(): # <- and only then set the global > ... > > > Just-making-a-stupid-point-and-not-endorsing-the-feature-ly yours, Of course it *works*, but it's still overriding a built-in... Who knows when assignment to main will become a SyntaxError like None ;) -bob ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] logging module broken because of locale
Hi, This is reported on sourceforge: http://sourceforge.net/tracker/index.php?func=detail&aid=1524081&group_id=5470&atid=105470 I am willing to try and patch the problem, but I'd like to discuss my ideas first. The basic problem is that, in some locale, "INFO".lower() != "info". So, initializing a dictionary with keys that appear to be lower-case in English is unsafe for other locale. Now, the other problem is, people can choose to initialize the locale any time they want, and can choose to change it too. My initial approach was to create the dictionary with strings to which lower() was explicitly called. But, since priority_names is class-scoped, it gets evaluated at module import time, which is way too early in the game (most likely the locale will be set afterwards). Any thoughts on the proper way to approach this? Thanks, Misa ___ Python-Dev mailing list [email protected] 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 Style Sheets ? Re: User's complaints
Josiah Carlson wrote: > Boris Borcic <[EMAIL PROTECTED]> wrote: >> Guido van Rossum wrote: >>> You must be misunderstanding. >> I don't think so. You appeared to say that the language changes too much >> because >> everyone wants different changes - that accumulate. I suggested a mechanism >> allowing people to see only the changes they want - or none at all - might >> be >> devised. > > Let us imagine that such a system were devised and implemented. A minimal requirement to such usage of the first person plural is some effort to make sure "we" talk about the same thing. > Invariably user X and Y would have different sets of changes that they > want to use. Presumably, if the features were nontrivial, then they > would no longer be able to exchange code because it would have been > directed at a different 'version' of Python, whose syntax or semantics > were different. Of course, and that's why in my initial post I was talking of transparent reversible transforms and central control of "styles" through the standard. Means not to fall into the trap you describe. Or else I would have asked for macros ! Are you implying that /no/ measure of language variability can be dealt with by such means as standards-controlled reversible transforms ? I guess not. I am just saying : (1) be aware that "reversible source to source transforms" means that language differences can *EFFECTIVELY* be made invisible - turned to purely private choices (in the sense of "because there exists perfect automatic two-way translation between equivalent languages", *NOT* "because we don't exchange code written in incompatible languages"). (2) of course that frame limits language differences, but nevertheless it relaxes that limit relative to the current situation of "no differences", and please don't write it off without any effort to evaluate its possibilities. Regards, BB -- 666 ? - 666 ~ .666 ~ 1 - 1/3 ~ 2/3 ~ tertium non datur ~ the excluded middle ~ "either with us, or against us" ___ Python-Dev mailing list [email protected] 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 Style Sheets ? Re: User's complaints
Boris Borcic wrote: >> Boris Borcic <[EMAIL PROTECTED]> wrote: >> >> [snip..] > I am just saying : > > (1) be aware that "reversible source to source transforms" means that > language > differences can *EFFECTIVELY* be made invisible - turned to purely private > choices (in the sense of "because there exists perfect automatic two-way > translation between equivalent languages", *NOT* "because we don't exchange > code > written in incompatible languages"). > > (2) of course that frame limits language differences, but nevertheless it > relaxes that limit relative to the current situation of "no differences", and > please don't write it off without any effort to evaluate its possibilities. > > Something similar to your suggestions are already possible through third part extensions like EasyExtend or Logix. (Effectively implementing a separate compiler.) Readability (one way to do it...) are a central part of the Python philosophy. This philosophy means that it is important that code written by one developer should be readable by others. Your suggestions have little to no chance of making it into the core Python distribution. All the best, Michael Foord http://www.voidspace.org.uk/python/index.shtml > Regards, BB > -- > 666 ? - 666 ~ .666 ~ 1 - 1/3 ~ 2/3 ~ tertium non datur ~ the excluded > middle > ~ "either with us, or against us" > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > ___ Python-Dev mailing list [email protected] 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 Style Sheets ? Re: User's complaints
Boris Borcic <[EMAIL PROTECTED]> wrote: > Josiah Carlson wrote: > > Invariably user X and Y would have different sets of changes that they > > want to use. Presumably, if the features were nontrivial, then they > > would no longer be able to exchange code because it would have been > > directed at a different 'version' of Python, whose syntax or semantics > > were different. > > Of course, and that's why in my initial post I was talking of transparent > reversible transforms and central control of "styles" through the standard. > Means not to fall into the trap you describe. Or else I would have asked for > macros ! Are you implying that /no/ measure of language variability can be > dealt > with by such means as standards-controlled reversible transforms ? I guess > not. Regardless of the existance of reversable transforms, a user's ability to understand and/or maintain code is dependant on the syntax and semantics of the language. In allowing different language variants, one is changing the user-understood meaning of a block of code, which necessarily increses the burden of programming and maintenance. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Pickling objects that return string from reduce
I'm still plugging away on IronPython's cPickle, and I've stumbled
across another ambiguity in the pickle docs. From
http://docs.python.org/lib/node69.html:
"If a string is returned, it names a global variable whose contents are
pickled as normal. The string returned by __reduce__ should be the
object's local name relative to its module; the pickle module searches
the module namespace to determine the object's module."
What exactly does that last clause mean? Must the object have a
__module__ attribute? What if it doesn't? What if the module exists but
isn't currently imported?
Is something like the following close?
# Call copy_reg-registered func, obj.__reduce_ex__, or
obj.__reduce__
result = call_reduce(obj)
if type(result) == tuple:
... (do appropriate things here)
elif isinstance(result, basestring):
name = result
module = ""
try:
module = obj.__module__
found_obj = getattr(sys.modules[module], name)
except AttributeError, KeyError:
raise PicklingError(
"Can't pickle %r: it's not found as %s.%s"
% (obj, module, name)
)
if found_obj is not obj:
raise PicklingError(
"Can't pickle %r: it's not the same object as %s.%s"
% (obj, module, name)
)
emit("c%s\n%s\n" % module, name)
Thanks,
--Bruce
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] new guy
Hi my name is Matt Westerburg, I am a student and have only recently gotten into Python. But have fallen in love with the language thus far. Fantastic language and thank you very much for making it what it is today. I am looking into getting into working on Python. Still need sometime working with the language, but I am interested in both the standard library and the interpreter. Can anyone recommend a good starting place? thank you ___ Python-Dev mailing list [email protected] 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 guy
On 7/17/06, matt westerburg <[EMAIL PROTECTED]> wrote: Hi my name is Matt Westerburg, I am a student and have only recently gotten into Python. But have fallen in love with the language thus far. Fantastic language and thank you very much for making it what it is today. I am looking into getting into working on Python. Still need sometime working with the language, but I am interested in both the standard library and the interpreter. Can anyone recommend a good starting place? First, welcome!Second, in terms of a good starting point, you can read http://www.python.org/dev/intro for an introduction on how things work around here (roughly) and what it takes to get something in. Really the best way to get introduced is to read this mailing list and to dive into some source (reviewing a patch can be a good way to go about this).-Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling objects that return string from reduce
Bruce Christensen wrote: > Is something like the following close? Close, yes. > if type(result) == tuple: > ... (do appropriate things here) > elif isinstance(result, basestring): > name = result > module = "" > try: > module = obj.__module__ > found_obj = getattr(sys.modules[module], name) > except AttributeError, KeyError: > raise PicklingError( > "Can't pickle %r: it's not found as %s.%s" > % (obj, module, name) > ) If obj has no __module__ attribute (or if it is None), pickle (didn't check cPickle) also does for n, module in sys.module.items(): if "module-ignored": continue if getattr(module, result, None) is obj: break # use n as module name If obj does have a __module__ attribute, it uses __import__ to import the module, just to make sure it gets into sys.modules. Otherwise, it looks correct. Regards, Martin ___ Python-Dev mailing list [email protected] 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 guy
matt westerburg wrote: > Hi my name is Matt Westerburg, I am a student and have only recently > gotten into Python. But have fallen in love with the language thus > far. Fantastic language and thank you very much for making it what it > is today. I am looking into getting into working on Python. Still need > sometime working with the language, but I am interested in both the > standard library and the interpreter. Can anyone recommend a good > starting place? As Brett says, reviewing bugs and patches would be most appreciated. Review a patch, and either tell the submitter how the patch should be improved, or tell us that you think the patch is ready to be applied (make sure the bug has documentation and/or test suite changes as necessary). Review a bug, and determine that it is a) reproducable b) constitutes a true problem (rather than a misunderstanding on the submitter's side); if both hold, try to come up with a patch. If it is not reproducable, tell the submitter and ask for more information. If it is not the true problem, tell us that you think it deserves to be closed. If you are uncertain which bug or patch to review, select one that a) is currently unassigned b) about a year old c) in an area of your personal interests Property a) and b) combined should guarantee that nobody beats you in fixing the problem while you are researching it. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
