On 4/2/06, Talin <[EMAIL PROTECTED]> wrote:
-- The __main__ module should contain a file path like importedmodules. in other words, every module should know where itcame from. In fact, I see no reason why the __main__ moduleshould have any different attributes than an imported module
other than the
Guido van Rossum wrote:
> On 4/1/06, Thomas Lotze <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I wonder what's the reason for iterating over a dict by keys:
>>
>> >>> for x in {1:"a", 2:"b"}:
>> ... print x
>> ...
>> 1
>> 2
>>
>> I find it much more intuitive for the values, "a" and "b", to be acces
On 4/1/06, Thomas Lotze <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I wonder what's the reason for iterating over a dict by keys:
>
> >>> for x in {1:"a", 2:"b"}:
> ... print x
> ...
> 1
> 2
>
> I find it much more intuitive for the values, "a" and "b", to be accessed.
> This is particularly confusing
Just in case anyone wants to play with a slightly more fleshed out, but
still simple minded (in a good way) approach to adaption, I've put up an
implementation here:
http://members.cox.net/~tim.hochberg/adaption2.py
It's adaption2, because I decided I didn't like my first try. No
guaran
On Sunday 02 April 2006 21:55, Barry Warsaw wrote:
> I use it, which shouldn't be a big suprise (though not in much public
> code). You'll probably see it get used quite a bit in a future Mailman
> release.
We've been using it at Zope Corporation recently in some of our "buildout"
framework.
On Apr 2, 2006, at 2:39 PM, Talin wrote:
...
> -- An easy way to iterate over key, value pairs in a dict in
> sorted order. Currently you have to get the list of keys,
> sort them, and then lookup each value, OR you have to
> get the list of tuples and call sorted() with a key= arg
> containin
Talin wrote:
> When I print __file__ from my __main__ module, I get the name of the
> file only, no path.
It seems to be whatever pathname you passed to the
interpreter on the command line. If that's a relative
path, it will end up in the __file__ of __main__ as
a relative path. But it will still
Talin wrote:
[...]
> For example, the suggestion of testing each member of a module with
> "is_module" is fine - except that a newbie programmer's first attempt to
> write "is_module" is probably going to be "isinstance( value, module )"
> which won't work because the word "module" isn't bound to
PEP: XXX
Title: Procedure for changing standard library modules
Version: $Revision$
Last-Modified: $Date$
Author: Georg Brandl <[EMAIL PROTECTED]>
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 02-Apr-2006
Abstract
This PEP describes the procedure for reviewing and
Talin wrote:
> -- An easy way to iterate over key, value pairs in a dict in
> sorted order. Currently you have to get the list of keys,
> sort them, and then lookup each value, OR you have to
> get the list of tuples and call sorted() with a key= arg
> containing a lambda function that extracts th
Georg Brandl wrote:
> BTW, has anyone seen string.Template being used somewhere?
I use it from time to time, usually when formatting user-provided
strings (because "%(foo)s" is not very pleasant or easy-to-explain
compared to "$foo"). However, I *never* use it internally in code,
because the o
Alex Martelli wrote:
> On Apr 2, 2006, at 4:39 PM, Walter Dörwald wrote:
>...
>> Why not make the registry identical to the protocol? The protocol is
>> just a convention anyway:
>
> Yes, a 1<->1 relationship between registries and protocols makes the
> 'registryof' function I was talking a
Georg Brandl <[EMAIL PROTECTED]> wrote:
> BTW, has anyone seen string.Template being used somewhere?
Not me. Surely it'd help if its documentation explained why on earth it has
been introduced. There are no apparent advantages over the builtin %s operator,
at first sight. Nothing worth using a n
Alex Martelli wrote:
> Do we have a "good practice document" about what you should or shouldn't
> do with metaclasses, or decorators, or, for that matter, with
> inheritance, operator overloading, and other powerful constructs and
> tools that have been with Python a long, long time?
Fair cop -
>> Not me. Surely it'd help if its documentation explained why on earth it has
>> been introduced. There are no apparent advantages over the builtin %s
operator,
>> at first sight. Nothing worth using a non-standard non-builtin substitution
>> engine, at least.
> PEP 292.
Yes, I said "documentati
Talin wrote:
> The same is true for the problem of a "plugins" dir containing modules
> to import. Yes, its only 3 lines of code to list the directory and import
> each file - but coming up with those exact 3 lines (in particular, getting
> the arguments to __import__ correct) is trickier than it l
On Sun, 2006-04-02 at 23:26 -0500, Ian Bicking wrote:
> Georg Brandl wrote:
> > BTW, has anyone seen string.Template being used somewhere?
>
> I use it from time to time, usually when formatting user-provided
> strings (because "%(foo)s" is not very pleasant or easy-to-explain
> compared to "$fo
On Mon, 2006-04-03 at 12:06 +0200, Giovanni Bajo wrote:
> Yes, I said "documentation" for a reason. Since when people have to go looking
> in PEPs for rationale of a module? string.Template introduces a very clear
> TOOWTDI conflict, I think the documentation should mention and try to explain
> it
FWIW, I went back and read PEP 246. That PEP goes to great lengths to permit
arbitrary objects to be used as protocols, with the process of checking for
compliance being a bit of a tap dance back and forth between the object and
the protocol. Great effort was also put into registering adaptabili
Barry Warsaw wrote:
> On Sun, 2006-04-02 at 23:26 -0500, Ian Bicking wrote:
>> Georg Brandl wrote:
>>> BTW, has anyone seen string.Template being used somewhere?
>> I use it from time to time, usually when formatting user-provided
>> strings (because "%(foo)s" is not very pleasant or easy-to-expla
On 4/1/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> [Monkeypatching] may just be impossible for ``classes'' that
> are actually types implemented in C, as is the case for gmpy.
> ... Rather, look (e.g.) at copy_reg for the typical kludge
> that's used to reimplement that crucial design pattern
On Mon, 2006-04-03 at 23:43 +1000, Nick Coghlan wrote:
> What do you think of a "format" builtin function that accepts the format as
> the first argument (similar to printf).
>
> The version on my harddrive permits positional arguments via $1, $2, etc, as
> well as string formatting (by stickin
On 4/1/06, Talin <[EMAIL PROTECTED]> wrote:
This is about the print / writeln debate.A somewhat tangental point, but I hope it's been decided that any function would be named writeline rather than writeln. I know writeln is a common function name, but abbreviations irritate me. Also, it might be
Barry Warsaw wrote:
> On Mon, 2006-04-03 at 23:43 +1000, Nick Coghlan wrote:
>
>
>>What do you think of a "format" builtin function that accepts the format as
>>the first argument (similar to printf).
>>
>>The version on my harddrive permits positional arguments via $1, $2, etc, as
>>well as st
Nick Coghlan wrote:
[SNIP]
>
> Tim Hochberg wrote:
>
>>In this thread, Alex has been advocating adaption where types are
>>adapted to protocols: T->P adaption for short. By contrast, my two
>>sample implementations have involved Protocol->Protocol adaption where
>>objects that implement a cert
Aren't a lot of the string formatting operations superfluous as %s does the work that type-specific operations (%i, etc) do? However, I guess I don't see how to merge the other formatting operations with $-string substitution. Could the other formatting operations be added to the str() function a
On Mon, 2006-04-03 at 11:13 -0500, Ian Bicking wrote:
> assert path.startswith(prefix), (
> "%r should start with %r" % (path, prefix))
> assert path.startswith(prefix), (
> $"${repr(path)} should start with ${repr(prefix)}")
> assert path.startswith(prefix), (
> "$path should start
Tim Hochberg writes:
> In this thread, Alex has been advocating adaption where types are
> adapted to protocols: T->P adaption for short. By contrast, my two
> sample implementations have involved Protocol->Protocol adaption
> [...] P->P adaption for short.
> However, there is a huge difference in
As an alternative to adaptation, I'd like to propose generic functions.
I think they play much the same role, except they are much simpler to
use and think about.
Though RuleDispatch offers considerably more features through predicate
dispatch, it would probably be best to just consider type
On 4/3/06, Barry Warsaw <[EMAIL PROTECTED]> wrote
> On Mon, 2006-04-03 at 11:13 -0500, Ian Bicking wrote:
>
> > assert path.startswith(prefix), (
> > "%r should start with %r" % (path, prefix))
> > assert path.startswith(prefix), (
> > $"${repr(path)} should start with ${repr(prefix)}")
>
Based on later discussion, it sounds like Alex sees adaptation as
(what I called case 2) -- The caller must make an explict call to
adapt. The advantage of adaption is that somebody other than the
caller or callee can fill in the appropriate code __adapt__ code.
Is this much correct?
If so, I s
On Mon, 2006-04-03 at 10:44 -0700, Crutcher Dunnavant wrote:
> Well, what if we added '%{expression}s' as a formating type?
> This would make your example:
>
> print _("%{user}s is not a member of the %{listname}s mailing list")
>
> or even:
>
> print _("%{utils.websafe(form.get('user'))}s is n
Michael Chermside wrote:
>Tim Hochberg writes:
>
>
>>In this thread, Alex has been advocating adaption where types are
>>adapted to protocols: T->P adaption for short. By contrast, my two
>>sample implementations have involved Protocol->Protocol adaption
>>[...] P->P adaption for short.
>>
>
Crutcher Dunnavant wrote:
> Well, what if we added '%{expression}s' as a formating type?
> This would make your example:
>
> print _("%{user}s is not a member of the %{listname}s mailing list")
>
> or even:
>
> print _("%{utils.websafe(form.get('user'))}s is not a member of the
> %{mlist.get_nam
> Crutcher Dunnavant wrote:
> >>> 1. Shouldn't there be a format method, like S.format(), or S.fmt()?
> > Why? Because:
> > 1 It is trivially cheap, format() would be the same function as __rmod__
No it shouldn't be. format() should be a varargs function; __rmod__
takes a single argument which may
On 4/3/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote:
> >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
Hmm... Let's not jump to conclusions. While I like your patch, we
Guido van Rossum wrote:
>>Crutcher Dunnavant wrote:
>>
>1. Shouldn't there be a format method, like S.format(), or S.fmt()?
>>>
>>>Why? Because:
>>>1 It is trivially cheap, format() would be the same function as __rmod__
>
>
> No it shouldn't be. format() should be a varargs function; __rmod_
Talin wrote:
> -- An easy way to make a case-insensitive, case-preserving
> dict that works with regular string keys.
Adam gave one possible implementation. Another would be a keyed
dictionary, e.g.,: KeyedDict(key=lambda s: s.lower()). A keyed
dictionary would internally call that function on
On Mon, 2006-04-03 at 13:12 -0500, Ian Bicking wrote:
> Even what Mailman
> does is potentially slightly unsafe if they were to accept input to _()
> from untrusted sources, though exploiting str() is rather hard, and
> Mailman presumably has at least a moderate amoung of trust for translators.
1463370
On 4/3/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Crutcher Dunnavant wrote:
> > >>> 1. Shouldn't there be a format method, like S.format(), or S.fmt()?
> > > Why? Because:
> > > 1 It is trivially cheap, format() would be the same function as __rmod__
>
> No it shouldn't be. format
On 4/3/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
>
> > On Apr 2, 2006, at 4:39 PM, Walter Dörwald wrote:
> >...
> >> Why not make the registry identical to the protocol? The protocol is
> >> just a convention anyway:
> >
> > Yes, a 1<->1 relationship between registrie
On 4/3/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
[snip]
> Adam gave one possible implementation. Another would be a keyed
> dictionary, e.g.,: KeyedDict(key=lambda s: s.lower()). A keyed
> dictionary would internally call that function on keys to get the "true"
> key, but things like .keys() wou
On Mon, 2006-04-03 at 13:51 -0500, Ian Bicking wrote:
> > No it shouldn't be. format() should be a varargs function; __rmod__
> > takes a single argument which may be a tuple. Also, format() could
> > take keyword args in case the string contains named format, so I can
> > write e.g. "%(foo)s".for
adam deprince wrote:
> On 4/3/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> [snip]
>
>>Adam gave one possible implementation. Another would be a keyed
>>dictionary, e.g.,: KeyedDict(key=lambda s: s.lower()). A keyed
>>dictionary would internally call that function on keys to get the "true"
>>key,
Barry Warsaw wrote:
>>Even what Mailman
>>does is potentially slightly unsafe if they were to accept input to _()
>>from untrusted sources, though exploiting str() is rather hard, and
>>Mailman presumably has at least a moderate amoung of trust for translators.
>
>
> Right, the attack vector w
I sort of lost track of the thread, then noticed a recent message where
Guido seems to be cozying up to the idea, so I thought maybe I ought to
think about it for a few minutes. As far as I can tell, the proposal is:
usage example
s.format(x, y) simple % substition, e.g
[EMAIL PROTECTED] wrote:
> I sort of lost track of the thread, then noticed a recent message where
> Guido seems to be cozying up to the idea, so I thought maybe I ought to
> think about it for a few minutes. As far as I can tell, the proposal is:
>
> usage example
> s.forma
Ian Bicking wrote:
> Barry Warsaw wrote:
>> On Mon, 2006-04-03 at 23:43 +1000, Nick Coghlan wrote:
>>
>>
>>> What do you think of a "format" builtin function that accepts the
>>> format as the first argument (similar to printf).
>>>
>>> The version on my harddrive permits positional arguments via
I've been thinking that `hash` could be an attribute (or property if it
needs to be calculated on-the-fly) rather than the current method call.
Or it could be an easy thing to add to the "won't change" PEP ...
Tim Delaney
___
Python-3000 mailing list
Py
Barry Warsaw wrote:
> I don't much like the $"" prefix
This was discussed during the last round of formatting
wars, and the conclusion was that having $ both
inside and outside the string would be too visually
confusing.
> I don't see a good
> way to marry the rich coercion of %-substitution wit
Michael Chermside wrote:
> But if we were to infer that
> anything satisfying "python.as_int" necessarily satisfied "python.as_index",
> then we would have defeated the purpose of the feature.
We just need to keep a clear distinction between "is an integer"
and "convertible to an integer". Python
Nick Coghlan wrote:
> In this case, it makes far more sense to me to move the adapter
> registration out to the individual protocols.
That would alleviate some of my concerns as well. This
seems more Pythonic: Namespaces are one honking... etc.
> In a glorious fit of self-referentiality, one of
On Mon, 2006-04-03 at 14:01 -0400, Barry Warsaw wrote:
> On Mon, 2006-04-03 at 10:44 -0700, Crutcher Dunnavant wrote:
>
> > Well, what if we added '%{expression}s' as a formating type?
> > This would make your example:
> >
> > print _("%{user}s is not a member of the %{listname}s mailing list")
>
> If I were designing a formatting system from scratch,
> I think I'd separate the issue of formatting numbers into
> strings from the issue of inserting strings into other
> strings. So instead of
>
>"Answer no. %5d is %8.3f" % (n, x)
>
> you would say something like
>
>subst("Answer no
Ian Bicking wrote:
> FWIW, I suspect I'd be much more likely to use named %'s with .format()
> than with %; which is probably good, since named markers are more
> flexible.
If we're going to encourage use of named arguments
(which I think we should) I think we also need to
get rid of the need f
[EMAIL PROTECTED] wrote:
> Multiple occurrences of **dict
> aren't supported in Python 2.4. I suppose it probably doesn't typically
> make a lot of sense, but for this it seems like it might be reasonable.
Maybe it would be better to have a general way
of combining dicts, e.g give dicts a '+' op
On Apr 3, 2006, at 11:14 AM, Guido van Rossum wrote:
...
> In fact, now that I think of it, if s.format() were available, I'd use
> it in preference over s%x, just like I already use repr(x) in favor of
> `x`. And just like `x` is slated for removal in Python 3000, we might
> consider removing
I didn't see any comments on this PEP. Is there consensus that this is
the way we should do it? I'm not sure that the order in which the
steps are to be carried out is all that important, nor that it's
necessary to do this in the same order for all modules, but otherwise
the only thing that bugs me
I was going to comment about this one "check it in, we'll add to it
later", but then I realized it's not 100% clear whether this is a
feature PEP or a meta-PEP? It focuses on features so by that yardstick
it's a feature PEP. But in its list-of-miscellany nature it
approximates a meta-PEP. Hmm, perh
Eric V. Smith wrote:
> Doesn't this violate Guido's "don't have a parameter that is always a
> constant that changes how a function operates" principle (or whatever
> its formal name is)?
It's not inconceivable that a function might want to
accept formatting parameters and pass them on to
anoth
On 4/3/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> As an alternative to adaptation, I'd like to propose generic functions.
> I think they play much the same role, except they are much simpler to
> use and think about.
Given that Phillip Eby is another proponent of generic functions I
seriously
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>
>>In this case, it makes far more sense to me to move the adapter
>>registration out to the individual protocols.
>
>
> That would alleviate some of my concerns as well. This
> seems more Pythonic: Namespaces are one honking... etc.
>
>
>>In a glor
Guido van Rossum wrote:
> On 4/3/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>> As an alternative to adaptation, I'd like to propose generic functions.
>> I think they play much the same role, except they are much simpler to
>> use and think about.
>
> Given that Phillip Eby is another proponent
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>I was going to comment about this one "check it in, we'll add to it
> later", but then I realized it's not 100% clear whether this is a
> feature PEP or a meta-PEP?
> In any case let's not let it longer for long. Real
64 matches
Mail list logo
