Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
Crutcher Dunnavant On Jul 23, 2007, at 9:55 AM, "Guido van Rossum" <[EMAIL PROTECTED]> wrote: > On 7/12/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote: >> On 7/11/07, Andy C <[EMAIL PROTECTED]> wrote: >>> The good thing about this is that it's extremely simple -- basically >>> 20 lines of C code to add a -z flag that calls a 3-line Python >>> function in the runpy module. >> >> Instead of requiring a -z flag, why not have the interpreter peak at >> the file to see if it starts with one of the ZIP magic numbers? >> >> That way it Just Works. > > I guess you wouldn't recognize a zip file if it hits you in the face. > Literally. :-) > > Zip files don't start with a magic number. Don't they end with a sentinel? If so, what would be the difference? > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > 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/crutcher%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] [Tutor] nice()
On 2/12/06, Alan Gauld <[EMAIL PROTECTED]> wrote: > >> However I do dislike the name nice() - there is already a nice() in the > >> os module with a fairly well understood function. But I'm sure some > > > Presumably it would be located somewhere like the math module. > > For sure, but let's avoid as many name clashes as we can. > Python is very good at managing namespaces but there are still a > lot of folks who favour the > > from x import * > > mode of working. Yes, and there are people who insist on drinking and driving, that doesn't mean cars should be designed with that as a motivating assumption. There are just too many places where you are going to get name clashes, where something which is _obvious_ in one context will have a different ( and _obvious_ ) meaning in another. Lets just keep the namespaces clean, and not worry about inter-module conflicts. -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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] [Tutor] nice()
On 2/14/06, Michael Walter <[EMAIL PROTECTED]> wrote: > It doesn't seem to me that math.nice has an obvious meaning. I don't disagree, I think math.nice is a terrible name. I was objecting to the desire to try to come up with interesting, different names in every module namespace. > Regards, > Michael > > On 2/14/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote: > > On 2/12/06, Alan Gauld <[EMAIL PROTECTED]> wrote: > > > >> However I do dislike the name nice() - there is already a nice() in the > > > >> os module with a fairly well understood function. But I'm sure some > > > > > > > Presumably it would be located somewhere like the math module. > > > > > > For sure, but let's avoid as many name clashes as we can. > > > Python is very good at managing namespaces but there are still a > > > lot of folks who favour the > > > > > > from x import * > > > > > > mode of working. > > > > Yes, and there are people who insist on drinking and driving, that > > doesn't mean cars should be designed with that as a motivating > > assumption. There are just too many places where you are going to get > > name clashes, where something which is _obvious_ in one context will > > have a different ( and _obvious_ ) meaning in another. Lets just keep > > the namespaces clean, and not worry about inter-module conflicts. > > > > -- > > Crutcher Dunnavant <[EMAIL PROTECTED]> > > littlelanguages.com > > monket.samedi-studios.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/michael.walter%40gmail.com > > > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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
[Python-Dev] New Module: CommandLoop
This is something I've been working on for a bit, and I think it is
more or less ready to bring up on this list. I'd like to add a module
(though probably not for 2.5).
Before you ask, this module is _not_ compatible with cmd.py, as it is
command oriented, whereas cmd.py is line oriented.
Anyway, I'm looking for feedback, feature requests before starting the
submission process.
Code available here:
http://littlelanguages.com/web/software/python/modules/cmdloop.py
Base class for writing simple interactive command loop environments.
CommandLoop provides a base class for writing simple interactive user
environments. It is designed around sub-classing, has a simple command
parser, and is trivial to initialize.
Here is a trivial little environment written using CommandLoop:
import cmdloop
class Hello(cmdloop.commandLoop):
PS1='hello>'
@cmdloop.aliases('hello', 'hi', 'hola')
@cmdloop.shorthelp('say hello')
@cmdloop.usage('hello TARGET')
def helloCmd(self, flags, args):
'''
Say hello to TARGET, which defaults to 'world'
'''
if flags or len(args) != 1:
raise cmdloop.InvalidArguments
print 'Hello %s!' % args[0]
@cmdloop.aliases('quit')
def quitCmd(self, flags, args):
'''
Quit the environment.
'''
raise cmdloop.HaltLoop
Hello().runLoop()
Here's a more complex example:
import cmdloop
class HelloGoodbye(cmdloop.CommandLoop):
PS1='hello>'
def __init__(self, default_target = 'world'):
self.default_target = default_target
self.target_list = []
@cmdloop.aliases('hello', 'hi', 'hola')
@cmdloop.shorthelp('say hello')
@cmdloop.usage('hello [TARGET]')
def helloCmd(self, flags, args):
'''
Say hello to TARGET, which defaults to 'world'
'''
if flags or len(args) > 1:
raise cmdloop.InvalidArguments
if args:
target = args[0]
else:
target = self.default_target
if target not in self.target_list:
self.target_list.append(target)
print 'Hello %s!' % target
@cmdloop.aliases('goodbye')
@cmdloop.shorthelp('say goodbye')
@cmdloop.usage('goodbye TARGET')
def goodbyeCmd(self, flags, args):
'''
Say goodbye to TARGET.
'''
if flags or len(args) != 1:
raise cmdloop.InvalidArguments
target = args[0]
if target in self.target_list:
print 'Goodbye %s!' % target
self.target_list.remove(target)
else:
print "I haven't said hello to %s." % target
@cmdloop.aliases('quit')
def quitCmd(self, flags, args):
'''
Quit the environment.
'''
raise cmdloop.HaltLoop
def _onLoopExit(self):
if len(self.target_list):
self.pushCommands(('quit',))
for target in self.target_list:
self.pushCommands(('goodbye', target))
else:
raise cmdloop.HaltLoop
HelloGoodbye().runLoop()
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
littlelanguages.com
monket.samedi-studios.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] New Module: CommandLoop
oops, error in the example: s/commandLoop/CommandLoop/g
On 2/19/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote:
> This is something I've been working on for a bit, and I think it is
> more or less ready to bring up on this list. I'd like to add a module
> (though probably not for 2.5).
>
> Before you ask, this module is _not_ compatible with cmd.py, as it is
> command oriented, whereas cmd.py is line oriented.
>
> Anyway, I'm looking for feedback, feature requests before starting the
> submission process.
>
> Code available here:
> http://littlelanguages.com/web/software/python/modules/cmdloop.py
>
> Base class for writing simple interactive command loop environments.
>
> CommandLoop provides a base class for writing simple interactive user
> environments. It is designed around sub-classing, has a simple command
> parser, and is trivial to initialize.
>
> Here is a trivial little environment written using CommandLoop:
>
> import cmdloop
>
> class Hello(cmdloop.commandLoop):
> PS1='hello>'
>
> @cmdloop.aliases('hello', 'hi', 'hola')
> @cmdloop.shorthelp('say hello')
> @cmdloop.usage('hello TARGET')
> def helloCmd(self, flags, args):
> '''
> Say hello to TARGET, which defaults to 'world'
> '''
> if flags or len(args) != 1:
> raise cmdloop.InvalidArguments
> print 'Hello %s!' % args[0]
>
> @cmdloop.aliases('quit')
> def quitCmd(self, flags, args):
> '''
> Quit the environment.
> '''
> raise cmdloop.HaltLoop
>
> Hello().runLoop()
>
> Here's a more complex example:
>
> import cmdloop
>
> class HelloGoodbye(cmdloop.CommandLoop):
> PS1='hello>'
>
> def __init__(self, default_target = 'world'):
> self.default_target = default_target
> self.target_list = []
>
> @cmdloop.aliases('hello', 'hi', 'hola')
> @cmdloop.shorthelp('say hello')
> @cmdloop.usage('hello [TARGET]')
> def helloCmd(self, flags, args):
> '''
> Say hello to TARGET, which defaults to 'world'
> '''
> if flags or len(args) > 1:
> raise cmdloop.InvalidArguments
> if args:
> target = args[0]
> else:
> target = self.default_target
> if target not in self.target_list:
> self.target_list.append(target)
> print 'Hello %s!' % target
>
> @cmdloop.aliases('goodbye')
> @cmdloop.shorthelp('say goodbye')
> @cmdloop.usage('goodbye TARGET')
> def goodbyeCmd(self, flags, args):
> '''
> Say goodbye to TARGET.
> '''
> if flags or len(args) != 1:
> raise cmdloop.InvalidArguments
> target = args[0]
> if target in self.target_list:
> print 'Goodbye %s!' % target
> self.target_list.remove(target)
> else:
> print "I haven't said hello to %s." % target
>
> @cmdloop.aliases('quit')
> def quitCmd(self, flags, args):
> '''
> Quit the environment.
> '''
> raise cmdloop.HaltLoop
>
> def _onLoopExit(self):
> if len(self.target_list):
> self.pushCommands(('quit',))
> for target in self.target_list:
> self.pushCommands(('goodbye', target))
> else:
> raise cmdloop.HaltLoop
>
> HelloGoodbye().runLoop()
>
> --
> Crutcher Dunnavant <[EMAIL PROTECTED]>
> littlelanguages.com
> monket.samedi-studios.com
>
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
littlelanguages.com
monket.samedi-studios.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] New Module: CommandLoop
Yes, I know. Hence this not being a patch. This is really meant to be a compelling alternative to cmd.Cmd, and as such I'm trying to get some discussion about it. On 2/19/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > On 2/19/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote: > > This is something I've been working on for a bit, and I think it is > > more or less ready to bring up on this list. I'd like to add a module > > (though probably not for 2.5). > > > > Before you ask, this module is _not_ compatible with cmd.py, as it is > > command oriented, whereas cmd.py is line oriented. > > > > Anyway, I'm looking for feedback, feature requests before starting the > > submission process. > > > > Code available here: > > http://littlelanguages.com/web/software/python/modules/cmdloop.py > > Just so you know, there is a basic rule that all new modules need to > have been used in the while and generally accepted and used by the > Python community before being accepted. While this is not a hard > rule, it is mostly followed so if there is no visible use of the > module by the rest of the world it will be difficult to get it > accepted. > > -Brett > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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] New Module: CommandLoop
Whoa, thanks. Incorporated the suggestions to the code.
On 2/19/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Crutcher Dunnavant]
> > Anyway, I'm looking for feedback, feature requests before starting the
> > submission process.
>
> With respect to the API, the examples tend to be visually dominated dominated
> by
> the series of decorators. The three decorators do nothing more than add a
> function attribute, so they are essentially doing the same type of action.
> Consider combining those into a single decorator and using keywords for the
> various arguments. For example, change:
>
> @cmdloop.aliases('goodbye')
> @cmdloop.shorthelp('say goodbye')
> @cmdloop.usage('goodbye TARGET')
>
> to just:
>
> @cmdloop.addspec(aliases=['goodbye'], shorthelp ='say goodbye',
> usage='goodbye TARGET')
>
> leaving the possibility of multiple decorators when one line gets to long:
>
> @cmdloop.addspec(aliases=['goodbye'], shorthelp ='say goodbye')
> @cmdloop.addspec(usage='goodbye TARGET # where TARGET is a filename
> in
> the current directory')
Well, why not support both, and leave it up to the user?
> Another thought on the API is to consider adding another decorator option to
> make commands case-insensitive so that 'help', 'HELP', and 'Help' will all
> work:
> @cmdloop.addspec(case_sensitive=True)
shouldn't this be a property of the shell, and not the individual commands?
Perhaps a CASE_SENSITIVE=False attribute on the shell?
> Also, in the absence of readline(), consider adding support for "!" style
> repeats of previous commands.
How would this work? Would it be a simple replay of the previous
command? Would it search a command history? How do we make it interact
with the _preCommand code? I'm not sure how to make this work.
> The exception hierarchy looks to be well-designed. I'm not clear on whether
> it
> is internal or part of the API. If the latter, is there an example of how to
> trap and handle specific exceptions in specific contexts?
The exceptions are part of the API, but are only meant to be thrown by
user code, and handled by the module code. There aren't any situations
when user code needs to catch modules that I know of.
> If you're interested, here are a few code comments based on my first
> read-through:
>
> 1) The "chars" variable can be eliminated and the "while chars" and
> "c=chars.pop(0)" sequence simplified to just:
> for c in reversed(str):
> . . .
chars is something of a navel. The parser went through some evolution,
and for a time, it _didn't_ consume a character every time arround.
However, the chars are not reversed, so given s/str/cmdline/g:
for c in cmdline:
...
> 2) Can the reformatDocString() function be replaced by textwrap.dedent() or do
> they do something different?
I guess so, they seem to do the same thing.
> 3) In _mapCommands(), the sort can be simplified from:
> self._cmds.sort(lambda a, b: cmp(a.aliases[0], b.aliases[0]))
> to:
> self._cmds.sort(key=operator.itemgetter(0))
> or if you want to avoid module dependencies:
> self._cmds.sort(key=lambda a: a[0])
well, almost. we are sorting on the aliases, so
self._cmds.sort(key=lambda a: a.aliases[0])
> 4) In _preCommand, the sort simplifies from:
> names = self.aliasdict.keys()
> names.sort()
> for name in names:
> to:
> for name in sorted(self.aliasdict):
>
cool.
> Raymond
>
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
littlelanguages.com
monket.samedi-studios.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] New Module: CommandLoop
s/catch modules/catch exceptions/g
On 2/19/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote:
> Whoa, thanks. Incorporated the suggestions to the code.
>
> On 2/19/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > [Crutcher Dunnavant]
> > > Anyway, I'm looking for feedback, feature requests before starting the
> > > submission process.
> >
> > With respect to the API, the examples tend to be visually dominated
> > dominated by
> > the series of decorators. The three decorators do nothing more than add a
> > function attribute, so they are essentially doing the same type of action.
> > Consider combining those into a single decorator and using keywords for the
> > various arguments. For example, change:
> >
> > @cmdloop.aliases('goodbye')
> > @cmdloop.shorthelp('say goodbye')
> > @cmdloop.usage('goodbye TARGET')
> >
> > to just:
> >
> > @cmdloop.addspec(aliases=['goodbye'], shorthelp ='say goodbye',
> > usage='goodbye TARGET')
> >
> > leaving the possibility of multiple decorators when one line gets to long:
> >
> > @cmdloop.addspec(aliases=['goodbye'], shorthelp ='say goodbye')
> > @cmdloop.addspec(usage='goodbye TARGET # where TARGET is a
> > filename in
> > the current directory')
>
> Well, why not support both, and leave it up to the user?
>
> > Another thought on the API is to consider adding another decorator option to
> > make commands case-insensitive so that 'help', 'HELP', and 'Help' will all
> > work:
> > @cmdloop.addspec(case_sensitive=True)
>
> shouldn't this be a property of the shell, and not the individual commands?
> Perhaps a CASE_SENSITIVE=False attribute on the shell?
>
> > Also, in the absence of readline(), consider adding support for "!" style
> > repeats of previous commands.
>
> How would this work? Would it be a simple replay of the previous
> command? Would it search a command history? How do we make it interact
> with the _preCommand code? I'm not sure how to make this work.
>
> > The exception hierarchy looks to be well-designed. I'm not clear on
> > whether it
> > is internal or part of the API. If the latter, is there an example of how
> > to
> > trap and handle specific exceptions in specific contexts?
>
> The exceptions are part of the API, but are only meant to be thrown by
> user code, and handled by the module code. There aren't any situations
> when user code needs to catch modules that I know of.
>
> > If you're interested, here are a few code comments based on my first
> > read-through:
> >
> > 1) The "chars" variable can be eliminated and the "while chars" and
> > "c=chars.pop(0)" sequence simplified to just:
> > for c in reversed(str):
> > . . .
>
> chars is something of a navel. The parser went through some evolution,
> and for a time, it _didn't_ consume a character every time arround.
> However, the chars are not reversed, so given s/str/cmdline/g:
>
> for c in cmdline:
> ...
>
> > 2) Can the reformatDocString() function be replaced by textwrap.dedent() or
> > do
> > they do something different?
>
> I guess so, they seem to do the same thing.
>
> > 3) In _mapCommands(), the sort can be simplified from:
> > self._cmds.sort(lambda a, b: cmp(a.aliases[0], b.aliases[0]))
> > to:
> > self._cmds.sort(key=operator.itemgetter(0))
> > or if you want to avoid module dependencies:
> > self._cmds.sort(key=lambda a: a[0])
>
> well, almost. we are sorting on the aliases, so
> self._cmds.sort(key=lambda a: a.aliases[0])
>
> > 4) In _preCommand, the sort simplifies from:
> > names = self.aliasdict.keys()
> > names.sort()
> > for name in names:
> > to:
> > for name in sorted(self.aliasdict):
> >
>
> cool.
>
> > Raymond
> >
>
>
> --
> Crutcher Dunnavant <[EMAIL PROTECTED]>
> littlelanguages.com
> monket.samedi-studios.com
>
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
littlelanguages.com
monket.samedi-studios.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] New Module: CommandLoop
On 2/19/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >> @cmdloop.aliases('goodbye')
> >> @cmdloop.shorthelp('say goodbye')
> >> @cmdloop.usage('goodbye TARGET')
> >>
> >> to just:
> >>
> >> @cmdloop.addspec(aliases=['goodbye'], shorthelp ='say goodbye',
> >> usage='goodbye TARGET')
> >>
> >> leaving the possibility of multiple decorators when one line gets to long:
> >>
> >> @cmdloop.addspec(aliases=['goodbye'], shorthelp ='say goodbye')
> >> @cmdloop.addspec(usage='goodbye TARGET # where TARGET is a
> >> filename
> >> in
> >> the current directory')
>
> > Well, why not support both, and leave it up to the user?
>
> Having only one method keeps the API simple. Also, the addspec() approach
> allows the user to choose between single and multiple lines.
>
> BTW, addspec() could be made completely general by supporting all possible
> keywords at once:
>
> def addspec(**kwds):
> def decorator(func):
> func.__dict__.update(kwds)
> return func
> return decorator
>
> With an open definition like that, users can specify new attributes with less
> effort.
Well, yes it could. But as it currently stands, there is no mechanism
for user code to manipulate commands, so that would be of limited
utility, versus throwing errors if the user specified something
unsupported.
>
>
> Raymond
>
>
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
littlelanguages.com
monket.samedi-studios.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] New Module: CommandLoop
totally agree, removed them. On 2/19/06, Terry Reedy <[EMAIL PROTECTED]> wrote: > I know it is tempting and perhaps ok in your own privatecode, but casually > masking builtins like 'str' in public library code sets a bad example ;-). > > tjr > > > > ___ > 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/crutcher%40gmail.com > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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] defaultdict proposal round three
Sorry to chime in so late, but why are we setting a value when the key isn't defined? It seems there are many situations where you want: a) default values, and b) the ability to determine if a value was defined. There are many times that I want d[key] to give me a value even when it isn't defined, but that doesn't always mean I want to _save_ that value in the dict. Sometimes I do, sometimes I don't. We should have some means of describing this in any defaultdict implementation On 2/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I'm withdrawing the last proposal. I'm not convinced by the argument > that __contains__ should always return True (perhaps it should also > insert the value?), nor by the complaint that a holy invariant would > be violated (so what?). > > But the amount of discussion and the number of different viewpoints > present makes it clear that the feature as I last proposed would be > forever divisive. > > I see two alternatives. These will cause a different kind of > philosophical discussion; so be it. I'll describe them relative to the > last proposal; for those who wisely skipped the last thread, here's a > link to the proposal: > http://mail.python.org/pipermail/python-dev/2006-February/061261.html. > > Alternative A: add a new method to the dict type with the semantics of > __getattr__ from the last proposal, using default_factory if not None > (except on_missing is inlined). This avoids the discussion about > broken invariants, but one could argue that it adds to an already > overly broad API. > > Alternative B: provide a dict subclass that implements the __getattr__ > semantics from the last proposal. It could be an unrelated type for > all I care, but I do care about implementation inheritance since it > should perform just as well as an unmodified dict object, and that's > hard to do without sharing implementation (copying would be worse). > > Parting shots: > > - Even if the default_factory were passed to the constructor, it still > ought to be a writable attribute so it can be introspected and > modified. A defaultdict that can't change its default factory after > its creation is less useful. > > - It would be unwise to have a default value that would be called if > it was callable: what if I wanted the default to be a class instance > that happens to have a __call__ method for unrelated reasons? > Callability is an elusive propperty; APIs should not attempt to > dynamically decide whether an argument is callable or not. > > - A third alternative would be to have a new method that takes an > explicit defaut factory argument. This differs from setdefault() only > in the type of the second argument. I'm not keen on this; the original > use case came from an example where the readability of > > d.setdefault(key, []).append(value) > > was questioned, and I'm not sure that > > d.something(key, list).append(value) > > is any more readable. IOW I like (and I believe few have questioned) > associating the default factory with the dict object instead of with > the call site. > > Let the third round of the games begin! > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > 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/crutcher%40gmail.com > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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] defaultdict proposal round three
I'm thinking something mutch closer to this (note default_factory gets the key): def on_missing(self, key): if self.default_factory is not None: value = self.default_factory(key) if self.on_missing_define_key: self[key] = value return value raise KeyError(key) On 2/20/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote: > Sorry to chime in so late, but why are we setting a value when the key > isn't defined? > > It seems there are many situations where you want: > a) default values, and > b) the ability to determine if a value was defined. > > There are many times that I want d[key] to give me a value even when > it isn't defined, but that doesn't always mean I want to _save_ that > value in the dict. Sometimes I do, sometimes I don't. We should have > some means of describing this in any defaultdict implementation > > On 2/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > I'm withdrawing the last proposal. I'm not convinced by the argument > > that __contains__ should always return True (perhaps it should also > > insert the value?), nor by the complaint that a holy invariant would > > be violated (so what?). > > > > But the amount of discussion and the number of different viewpoints > > present makes it clear that the feature as I last proposed would be > > forever divisive. > > > > I see two alternatives. These will cause a different kind of > > philosophical discussion; so be it. I'll describe them relative to the > > last proposal; for those who wisely skipped the last thread, here's a > > link to the proposal: > > http://mail.python.org/pipermail/python-dev/2006-February/061261.html. > > > > Alternative A: add a new method to the dict type with the semantics of > > __getattr__ from the last proposal, using default_factory if not None > > (except on_missing is inlined). This avoids the discussion about > > broken invariants, but one could argue that it adds to an already > > overly broad API. > > > > Alternative B: provide a dict subclass that implements the __getattr__ > > semantics from the last proposal. It could be an unrelated type for > > all I care, but I do care about implementation inheritance since it > > should perform just as well as an unmodified dict object, and that's > > hard to do without sharing implementation (copying would be worse). > > > > Parting shots: > > > > - Even if the default_factory were passed to the constructor, it still > > ought to be a writable attribute so it can be introspected and > > modified. A defaultdict that can't change its default factory after > > its creation is less useful. > > > > - It would be unwise to have a default value that would be called if > > it was callable: what if I wanted the default to be a class instance > > that happens to have a __call__ method for unrelated reasons? > > Callability is an elusive propperty; APIs should not attempt to > > dynamically decide whether an argument is callable or not. > > > > - A third alternative would be to have a new method that takes an > > explicit defaut factory argument. This differs from setdefault() only > > in the type of the second argument. I'm not keen on this; the original > > use case came from an example where the readability of > > > > d.setdefault(key, []).append(value) > > > > was questioned, and I'm not sure that > > > > d.something(key, list).append(value) > > > > is any more readable. IOW I like (and I believe few have questioned) > > associating the default factory with the dict object instead of with > > the call site. > > > > Let the third round of the games begin! > > > > -- > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > ___ > > 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/crutcher%40gmail.com > > > > > -- > Crutcher Dunnavant <[EMAIL PROTECTED]> > littlelanguages.com > monket.samedi-studios.com > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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] defaultdict proposal round three
in two ways: 1) dict.get doesn't work for object dicts or in exec/eval contexts, and 2) dict.get requires me to generate the default value even if I'm not going to use it, a process which may be expensive. On 2/20/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Crutcher Dunnavant ] > >> There are many times that I want d[key] to give me a value even when > >> it isn't defined, but that doesn't always mean I want to _save_ that > >> value in the dict. > > How does that differ from the existing dict.get method? > > > Raymond > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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] quit() on the prompt
I am probably the biggest proponent of magic variables, but this just
won't work.
First, commands and lines are not the same thing, so:
print \
exit
breaks your propossal.
Second, quit and exit are bindable variables, and you need to be sure
that they still mean _quit_, and not something else.
On 3/7/06, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> do {
> cmd = readline()
> do_stuff_with_cmd(cmd);
> } while (!strcmp(cmd, "quit"));
> printf("Bye!");
> exit(0);
>
> KISS?
>
> --
> mvh Björn
> ___
> 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/crutcher%40gmail.com
>
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
littlelanguages.com
monket.samedi-studios.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] String formating in python 3000
Yep, moved this there. On 4/2/06, Aahz <[EMAIL PROTECTED]> wrote: > On Sun, Apr 02, 2006, Crutcher Dunnavant wrote: > > > > But I have some questions about this for python 3000. > > Please use the python-3000 list for questions like this. > -- > Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ > > "Look, it's your affair if you want to play with five people, but don't > go calling it doubles." --John Cleese anticipates Usenet > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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
[Python-Dev] String formating in python 3000
Python currently supports 'S % X', where S is a strinng, and X is one of:
* a sequence
* a map
* treated as (X,)
But I have some questions about this for python 3000.
1. Shouldn't there be a format method, like S.format(), or S.fmt()?
2. What about using __call__ instead of / in addition to __rmod__?
* "time: %s"(time.ctime()) == "time: %s" % time.ctime()
* "%(a)s %(b)s"(a=1, b=2) == "%(a)s %(b)s" % {'a'=1, 'b'=2}
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
littlelanguages.com
monket.samedi-studios.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
[Python-Dev] SF:1463370 add .format() method to str and unicode
>From discussion on python-3000, it occured to me that this shouldn't break anything. This patch adds a .format() method to the string and unicode types. SF:1463370 -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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
[Python-Dev] Should issubclass() be more like isinstance()?
While nocking together a framework today, I ran into the amazing limitations of issubclass(). A) issubclass() throws a TypeError if the object being checked is not a class, which seems very strange. It is a predicate, and lacking a isclass() method, it should just return False. B) issubclass() won't work on a list of classs, the way isinstance() does. Is there any support for patches which fix A and/or B? -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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] Should issubclass() be more like isinstance()?
On 4/4/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Crutcher Dunnavant wrote: > > > A) issubclass() throws a TypeError if the object being checked is not > > a class, which seems very strange. > > If I ever pass a non-class to issubclass() it's almost > certainly a bug in my code, and I'd want to know about > it. Perhaps, but is it worth distorting a predicate? > On the rare occasions when I don't want this, I'm > happy to write > >isinstance(c, type) and issubclass(c, d) This doesn't work, did you mean? isinstance(c, types.ClassType) and issubclass(c, d) > > B) issubclass() won't work on a list of classs, > > the way isinstance() does. > > That sounds more reasonable. I can't think of any > reason why it shouldn't work. > > -- > Greg > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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] Should issubclass() be more like isinstance()?
On 4/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 4/4/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote: > > On 4/4/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > > > Crutcher Dunnavant wrote: > > > > > > > A) issubclass() throws a TypeError if the object being checked is not > > > > a class, which seems very strange. > > > > > > If I ever pass a non-class to issubclass() it's almost > > > certainly a bug in my code, and I'd want to know about > > > it. > > > > Perhaps, but is it worth distorting a predicate? > > Certainly. In other languages this would be a compile-time error. In other, statically typed languges. Someone hands me X, I want to know if X is a subclass of Y. Yes or No. If X is not a class, then it is not a subclass of Y, hence issubclass(X, Y) should return False. > There's no rule that predicate cannot raise an exception. No, but it makes many applications (such as using it as a test in list comprehensions) difficult enough to not be worth it. > If you're not sure whether something is a class or not, you should > first sniff it out for its class-ness before checking whether it's a > subclass of something. I recommend hasattr(x, "__bases__") which is > more likely to recognize classes than isinstance(x, type) -- the > latter only works for standard new-style classes. > > > > On the rare occasions when I don't want this, I'm > > > happy to write > > > > > >isinstance(c, type) and issubclass(c, d) > > > > This doesn't work, did you mean? > > isinstance(c, types.ClassType) and issubclass(c, d) > > > > > > > > B) issubclass() won't work on a list of classs, > > > > the way isinstance() does. > > > > > > That sounds more reasonable. I can't think of any > > > reason why it shouldn't work. > > Agreed. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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] Builtin exit, good in interpreter, bad in code.
On 4/23/06, Sean Reifschneider <[EMAIL PROTECTED]> wrote:
> A friend of mine is learning Python, and had a problem with the exit
> builtin. I like that in the interpreter it gives useful information, but
> he was writing a program in a file and tried "exit(0)", and was presented
> with the non-obvious error:
>
>TypeError: 'str' object is not callable
>
> What about something like:
>
>>>> class ExitClass:
>...def __repr__(self):
>... return('Hey, press control-D')
>...def __call__(self, value):
>... raise SyntaxError, 'You want to use sys.exit'
>...
>>>> exit = ExitClass()
>>>> exit
>Hey, press control-D
>>>> exit(1)
>Traceback (most recent call last):
> File "", line 1, in ?
> File "", line 5, in __call__
>SyntaxError: You want to use sys.exit
>
> Jerub on #python thinks that maybe it needs to subclass the string object
> instead, but in general it seems like it might be an improvement.
Why don't we just not define 'exit' in non-interactive environments?
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
littlelanguages.com
monket.samedi-studios.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] Builtin exit, good in interpreter, bad in code.
On 4/23/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Sean Reifschneider wrote: > > Thoughts? > > In Python 2.5, exit(0) exits. +1 > > 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/crutcher%40gmail.com > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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
[Python-Dev] [PATCH] Fix dictionary subclass semantics when used as global dictionaries
There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. -- Crutcher Dunnavant <[EMAIL PROTECTED]> monket.samedi-studios.com dictsubclassexec.patch Description: Binary data ___ 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] Hello
Sorry, sent a patch without an intro. My name is Crutcher Dunnavant I'm working on a doctorate in computer science (in modeling language practises). Before I got my master's degree, I used to work for Red Hat in North Carolina as an OS developer, and I now work in the San Fransisco Bay Area as a system analyst. -- Crutcher Dunnavant <[EMAIL PROTECTED]> monket.samedi-studios.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] [PATCH] Fix dictionary subclass semantics when used as global dictionaries
1402289 On 1/10/06, Aahz <[EMAIL PROTECTED]> wrote: > On Tue, Jan 10, 2006, Crutcher Dunnavant wrote: > > > > There is an inconsistancy in the way that dictionary subclasses behave > > when they are used as as namespaces in execs. > > > > Basically, while python 2.4 permits the usage of dictionary subclasses > > for local environments, it still bypasses the subclass functions and > > uses the C API for global environments. The attached patch (and > > unittest!) addresses this issue. > > Please submit the patch to SourceForge and report back with the SF ID. > -- > Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ > > "19. A language that doesn't affect the way you think about programming, > is not worth knowing." --Alan Perlis > -- Crutcher Dunnavant <[EMAIL PROTECTED]> monket.samedi-studios.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] [PATCH] Fix dictionary subclass semantics when used as global dictionaries
This is the unittest that checks it. On trunk, the global and fall
through cases will fail, but they pass with the patch.
import unittest
from test import test_support
class DictSubclass(dict):
get_notify_func = None
def __getitem__(self, key):
if self.get_notify_func:
self.get_notify_func(key)
return dict.__getitem__(self, key)
set_notify_func = None
def __setitem__(self, key, value):
if self.set_notify_func:
self.set_notify_func(key)
return dict.__setitem__(self, key, value)
del_notify_func = None
def __delitem__(self, key):
if self.del_notify_func:
self.del_notify_func(key)
return dict.__delitem__(self, key)
class DictSubclassExecTest(unittest.TestCase):
def test_subclassexec_setlocal(self):
d = DictSubclass()
l = []
d.set_notify_func = l.append
exec "a = 1" in d
d.set_notify_func = None
self.assert_(d['a'] == 1)
self.assert_('a' in l)
def test_subclassexec_getlocal(self):
d = DictSubclass()
l = []
d.get_notify_func = l.append
exec "a = 1; a" in d
d.get_notify_func = None
self.assert_(d['a'] == 1)
self.assert_('a' in l)
def test_subclassexec_dellocal(self):
d = DictSubclass()
l = []
d.del_notify_func = l.append
exec "a = 1; del a" in d
d.del_notify_func = None
self.assert_(not d.has_key('a'))
self.assert_('a' in l)
def test_subclassexec_setglobal(self):
d = DictSubclass()
l = []
d.set_notify_func = l.append
exec "a = 1\ndef foo():\n\tglobal a\n\tpass" in d
d.set_notify_func = None
self.assert_(d['a'] == 1)
self.assert_('a' in l)
def test_subclassexec_getglobal(self):
d = DictSubclass()
l = []
d.get_notify_func = l.append
exec "a = 1; a\ndef foo():\n\tglobal a\n\tpass" in d
d.get_notify_func = None
self.assert_(d['a'] == 1)
self.assert_('a' in l)
def test_subclassexec_delglobal(self):
d = DictSubclass()
l = []
d.del_notify_func = l.append
exec "a = 1; del a\ndef foo():\n\tglobal a\n\tpass" in d
d.del_notify_func = None
self.assert_(not d.has_key('a'))
self.assert_('a' in l)
def test_subclassexec_getfallthrough(self):
ld = DictSubclass()
ll = []
ld.get_notify_func = ll.append
gd = DictSubclass()
gl = []
gd.get_notify_func = gl.append
gd['a'] = 1
exec 'b = a' in gd, ld
gd.del_notify_func = None
ld.del_notify_func = None
self.assert_(ld['b'] == 1)
self.assert_('a' in ll)
self.assert_('a' in gl)
def test_main():
test_support.run_unittest(
DictSubclassExecTest,
)
if __name__ == "__main__":
test_main()
On 1/10/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote:
> 1402289
>
> On 1/10/06, Aahz <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 10, 2006, Crutcher Dunnavant wrote:
> > >
> > > There is an inconsistancy in the way that dictionary subclasses behave
> > > when they are used as as namespaces in execs.
> > >
> > > Basically, while python 2.4 permits the usage of dictionary subclasses
> > > for local environments, it still bypasses the subclass functions and
> > > uses the C API for global environments. The attached patch (and
> > > unittest!) addresses this issue.
> >
> > Please submit the patch to SourceForge and report back with the SF ID.
> > --
> > Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/
> >
> > "19. A language that doesn't affect the way you think about programming,
> > is not worth knowing." --Alan Perlis
> >
>
>
> --
> Crutcher Dunnavant <[EMAIL PROTECTED]>
> monket.samedi-studios.com
>
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
monket.samedi-studios.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] [PATCH] Fix dictionary subclass semantics when used as global dictionaries
Is there any objection to this patch? Any support? On 1/10/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote: > 1402289 > > On 1/10/06, Aahz <[EMAIL PROTECTED]> wrote: > > On Tue, Jan 10, 2006, Crutcher Dunnavant wrote: > > > > > > There is an inconsistancy in the way that dictionary subclasses behave > > > when they are used as as namespaces in execs. > > > > > > Basically, while python 2.4 permits the usage of dictionary subclasses > > > for local environments, it still bypasses the subclass functions and > > > uses the C API for global environments. The attached patch (and > > > unittest!) addresses this issue. > > > > Please submit the patch to SourceForge and report back with the SF ID. > > -- > > Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ > > > > "19. A language that doesn't affect the way you think about programming, > > is not worth knowing." --Alan Perlis > > > > > -- > Crutcher Dunnavant <[EMAIL PROTECTED]> > monket.samedi-studios.com > -- Crutcher Dunnavant <[EMAIL PROTECTED]> monket.samedi-studios.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] [PATCH] Fix dictionary subclass semantics whenused as global dictionaries
I sorta disagree about it not being broken. Adding a feature which
works for eval but not for exec seems pretty broken. It's difficult to
reason about what will happen in the exec context, so I can't see what
fixing it would endanger; but I'd deffinately like to see it for 2.5.
I've run rough timings on the code, ('test make time'), detailed in
the patch discussion, and it seems completely lost in the noise.
On 1/12/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > Is there any objection to this patch? Any support?
>
> It is assigned to me. When I have time, will go through it in detail
> (the given use cases, more detailed timings, and a close reading of the
> code).
>
> If accepted, it will be for Py2.5, as it is a new feature. There is
> nothing broken about the existing eval() version, it just doesn't apply
> as broadly as you would have liked.
>
>
>
> Raymond
>
>
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
monket.samedi-studios.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] [PATCH] Fix dictionary subclass semantics whenused as global dictionaries
Okay, but is there any reason not to include this in 2.5? There doesn't seem to be any noticeable performance impact, and it does add consistancy (and opens some really, really cool options up). Does anyone have objections to 1402289? On 1/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Crutcher Dunnavant wrote: > > I sorta disagree about it not being broken. Adding a feature which > > works for eval but not for exec seems pretty broken. > > You "seem" to have a different notion of "to be broken", then. > > Python is broken, if and only if > - the interpreter crashes, for any Python input > - the implementation does not do what the documentation says > it would do > - the BDFL pronounces it is broken > > In this specific change, the change did precisely what the requestor > of the feature wanted it to do (that eval could accept non-exact > dicts was a new feature back then also) > > > It's difficult to > > reason about what will happen in the exec context, so I can't see what > > fixing it would endanger; but I'd deffinately like to see it for 2.5. > > It would make Python code run which is currently rejected with an > exception. Therefore, it is a new feature (a behaviour change). > > Applications relying on that feature would have to specify that > they require "2.4.3"; people would find that code that runs fine > in 2.4.3 fails in 2.4.2. This is not acceptable. > > Regards, > Martin > -- Crutcher Dunnavant <[EMAIL PROTECTED]> monket.samedi-studios.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] Let's just *keep* lambda
+1 On 2/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > After so many attempts to come up with an alternative for lambda, > perhaps we should admit defeat. I've not had the time to follow the > most recent rounds, but I propose that we keep lambda, so as to stop > wasting everybody's talent and time on an impossible quest. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > 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/crutcher%40gmail.com > -- Crutcher Dunnavant <[EMAIL PROTECTED]> monket.samedi-studios.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] Let's just *keep* lambda
Which reminds me, we need to support roman numeral constants. A silly implementation follows. class RomanNumeralDict(dict): def __getitem__(self, key): if not self.has_key(key) and self.isRN(key): return self.decodeRN(key) return dict.__getitem__(self, key) def isRN(self, key): for c in key: if c not in 'MmCcXxIiDdVv': return False return True def decodeRN(self, key): val = 0 # ... do stuff ... return val On 2/5/06, Tim Peters <[EMAIL PROTECTED]> wrote: > [Guido] > > After so many attempts to come up with an alternative for lambda, > > perhaps we should admit defeat. I've not had the time to follow the > > most recent rounds, but I propose that we keep lambda, so as to stop > > wasting everybody's talent and time on an impossible quest. > > Huh! Was someone bad-mouthing lambda again? We should keep it, but > rename it to honor a different Greek letter. xi is a good one, easier > to type, and would lay solid groundwork for future flamewars between > xi enthusiasts and Roman numeral fans :-) > ___ > 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/crutcher%40gmail.com > -- Crutcher Dunnavant <[EMAIL PROTECTED]> monket.samedi-studios.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] [PATCH] Fix dictionary subclass semantics whenused as global dictionaries
I've significantly re-worked the patch to permit globals to be arbitrary mappings. The regression tests continue to all pass. http://sourceforge.net/tracker/index.php?func=detail&aid=1402289&group_id=5470&atid=305470 On 1/24/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Crutcher Dunnavant wrote: > > Okay, but is there any reason not to include this in 2.5? There > > doesn't seem to be any noticeable performance impact, and it does add > > consistancy (and opens some really, really cool options up). > > I see no reason, except perhaps the lack of volunteers to actually > patch the repository (along with the accompanying work). > > Regards, > Martin > > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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
[Python-Dev] Any interest in tail call optimization as a decorator?
Maybe someone has already brought this up, but my searching hasn't revealed it. Is there any interest in something like this for the functional module? #!/usr/bin/env python2.4 # This program shows off a python decorator which implements # tail call optimization. It does this by throwing an exception # if it is it's own grandparent, and catching such exceptions # to recall the stack. import sys class TailRecurseException: def __init__(self, args, kwargs): self.args = args self.kwargs = kwargs def tail_call_optimized(g): def func(*args, **kwargs): try: raise ZeroDivisionError except ZeroDivisionError: f = sys.exc_info()[2].tb_frame if f.f_back and f.f_back.f_back \ and f.f_back.f_back.f_code == f.f_code: raise TailRecurseException(args, kwargs) else: while 1: try: return g(*args, **kwargs) except TailRecurseException, e: args = e.args kwargs = e.kwargs func.__doc__ = g.__doc__ return func @tail_call_optimized def factorial(n, acc=1): "calculate a factorial" if n == 0: return acc return factorial(n-1, n*acc) print factorial(1) # prints a big, big number, # but doesn't hit the recursion limit. @tail_call_optimized def fib(i, current = 0, next = 1): if i == 0: return current else: return fib(i - 1, next, current + next) print fib(1) # also prints a big number, # but doesn't hit the recursion limit. -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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] The decorator(s) module
+1, and we could maybe include tail_call_optimized? http://littlelanguages.com/2006/02/tail-call-optimization-as-python.html On 2/11/06, Georg Brandl <[EMAIL PROTECTED]> wrote: > Hi, > > it has been proposed before, but there was no conclusive answer last time: > is there any chance for 2.5 to include commonly used decorators in a module? > > Of course not everything that jumps around should go in, only pretty basic > stuff that can be widely used. > > Candidates are: > - @decorator. This properly wraps up a decorator function to change the >signature of the new function according to the decorated one's. > > - @contextmanager, see PEP 343. > > - @synchronized/@locked/whatever, for thread safety. > > - @memoize > > - Others from wiki:PythonDecoratorLibrary and Michele Simionato's decorator >module at <http://www.phyast.pitt.edu/~micheles/python/documentation.html>. > > Unfortunately, a @property decorator is impossible... > > regards, > Georg > > ___ > 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/crutcher%40gmail.com > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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
