Re: [Python-3000] PEP Parade
> S 3121 Module Initialization and finalization von Löwis > > I like it. I wish the title were changed to "Extension Module ..." though. Done! Martin ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] [Python-Dev] PEP 30XZ: Simplified Parsing
Raymond> [Skip]
>> I use it all the time. For example, to build up (what I consider to be)
>> readable SQL queries:
>>
>> rows = self.executesql("select cities.city, state, country"
>>"from cities, venues, events, addresses"
>>"where cities.city like %s"
>>" and events.active = 1"
>>" and venues.address = addresses.id"
>>" and addresses.city = cities.id"
>>" and events.venue = venues.id",
>>(city,))
Raymond> I find that style hard to maintain. What is the advantage over
Raymond> multi-line strings?
Raymond> rows = self.executesql('''
Raymond> select cities.city, state, country
Raymond> from cities, venues, events, addresses
Raymond> where cities.city like %s
Raymond> and events.active = 1
Raymond> and venues.address = addresses.id
Raymond> and addresses.city = cities.id
Raymond> and events.venue = venues.id
Raymond> ''',
Raymond> (city,))
Maybe it's just a quirk of how python-mode in Emacs treats multiline strings
that caused me to start doing things this way (I've been doing my embedded
SQL statements this way for several years now), but when I hit LF in an open
multiline string a newline is inserted and the cursor is lined up under the
"r" of "rows", not under the opening quote of the multiline string, and not
where you chose to indent your example. When I use individual strings the
parameters line up where I want them to (the way I lined things up in my
example). At any rate, it's what I'm used to now.
Skip
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] PEP 3120 (Was: PEP Parade)
> S 3120 Using UTF-8 as the default source encoding von Löwis > > The basic idea seems very reasonable. I expect that the changes to the > parser may be quite significant though. Also, the parser ought to be > weened of C stdio in favor of Python's own I/O library. I wonder if > it's really possible to let the parser read the raw bytes though -- > this would seem to rule out supporting encodings like UTF-16. Somehow > I wonder if it wouldn't be easier if the parser operated on Unicode > input? That way parsing unicode strings (which we must support as all > strings will become unicode) will be simpler. Actually, changes should be fairly minimal. The parser already transforms all input (no matter what source encoding) to UTF-8 before doing the parsing; this has worked well (as all keywords continue to be one-byte characters). The parser also already special-cases UTF-8 as the input encoding, by not putting it through a codec. That can also stay, except that it should now check that any non-ASCII bytes are well-formed UTF-8. Untangling the parser from stdio - sure. I also think it would be desirable to read the whole source into a buffer, rather than applying a line-by-line input. That might be a bigger change, making the tokenizer a multi-stage algorithm: 1. read input into a buffer 2. determine source encoding (looking at a BOM, else a declaration within the first two lines, else default to UTF-8) 3. if the source encoding is not UTF-8, pass it through a codec (decode to string, encode to UTF-8). Otherwise, check that all bytes are really well-formed UTF-8. 4. start parsing As for UTF-16: the lexer currently does not support UTF-16 as a source encoding, as we require an ASCII superset. I'm not sure whether UTF-16 needs to be supported as a source encoding, but with above changes, it would be fairly easy to support, assuming we detect UTF-16 from the BOM (can't use the encoding declaration, because that works only for ASCII supersets). Regards, Martin ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] [Python-Dev] PEP 30XZ: Simplified Parsing
Georg Brandl wrote:
> FWIW, I'm -1 on both proposals too. I like implicit string literal
> concatenation
> and I really can't see what we gain from backslash continuation removal.
>
> Georg
-1 on removing them also. I find they are helpful.
It could be made optional in block headers that end with a ':'. It's
optional, (just more white space), in parenthesized expressions, tuples,
lists, and dictionary literals already.
>>> [1,\
... 2,\
... 3]
[1, 2, 3]
>>> (1,\
... 2,\
... 3)
(1, 2, 3)
>>> {1:'a',\
... 2:'b',\
... 3:'c'}
{1: 'a', 2: 'b', 3: 'c'}
The rule would be any keyword that starts a block, (class, def, if, elif,
with, ... etc.), until an unused (for anything else) colon, would always
evaluate to be a single line weather or not it has parentheses or line
continuations in it. These can never be multi-line statements as far as I
know.
The back slash would still be needed in console input.
The following inconsistency still bothers me, but I suppose it's an edge
case that doesn't cause problems.
>>> print r"hello world\"
File "", line 1
print r"hello world\"
^
SyntaxError: EOL while scanning single-quoted string
>>> print r"hello\
... world"
hello\
world
In the first case, it's treated as a continuation character even though
it's not at the end of a physical line. So it gives an error.
In the second case, its accepted as a continuation character, *and* a '\'
character at the same time. (?)
Cheers,
Ron
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] [Python-Dev] Implicit String Concatenation and Octal Literals Was: PEP 30XZ: Simplified Parsing
Raymond Hettinger wrote:
>>Raymond> I find that style hard to maintain. What is the advantage over
>>Raymond> multi-line strings?
>>
>>Raymond> rows = self.executesql('''
>>Raymond> select cities.city, state, country
>>Raymond> from cities, venues, events, addresses
>>Raymond> where cities.city like %s
>>Raymond> and events.active = 1
>>Raymond> and venues.address = addresses.id
>>Raymond> and addresses.city = cities.id
>>Raymond> and events.venue = venues.id
>>Raymond> ''',
>>Raymond> (city,))
>
> [Skip]
>> Maybe it's just a quirk of how python-mode in Emacs treats multiline strings
>> that caused me to start doing things this way (I've been doing my embedded
>> SQL statements this way for several years now), but when I hit LF in an open
>> multiline string a newline is inserted and the cursor is lined up under the
>> "r" of "rows", not under the opening quote of the multiline string, and not
>> where you chose to indent your example. When I use individual strings the
>> parameters line up where I want them to (the way I lined things up in my
>> example). At any rate, it's what I'm used to now.
>
>
> I completely understand. Almost any simplification or feature elimination
> proposal is going to bump-up against, "what we're used to now".
> Py3k may be our last chance to simplify the language. We have so many
> special little rules that even advanced users can't keep them
> all in their head. Certainly, every feature has someone who uses it.
> But, there is some value to reducing the number of rules, especially
> if those rules are non-essential (i.e. implicit string concatenation has
> simple, clear alternatives with multi-line strings or with the plus-operator).
>
> Another way to look at it is to ask whether we would consider
> adding implicit string concatenation if we didn't already have it.
> I think there would be a chorus of emails against it -- arguing
> against language bloat and noting that we already have triple-quoted
> strings, raw-strings, a verbose flag for regexs, backslashes inside multiline
> strings, the explicit plus-operator, and multi-line expressions delimited
> by parentheses or brackets. Collectively, that is A LOT of ways to do it.
>
> I'm asking this group to give up a minor habit so that we can achieve
> at least a few simplifications on the way to Py3.0 -- basically, our last
> chance.
>
> Similar thoughts apply to the octal literal PEP. I'm -1 on introducing
> yet another way to write the literal (and a non-standard one at that).
> My proposal was simply to eliminate it. The use cases are few and
> far between (translating C headers and setting unix file permissions).
> In either case, writing int('0777', 8) suffices. In the latter case, we've
> already provided clear symbolic alternatives. This simplification of the
> language would be a freebie (impacting very little code, simplifying the
> lexer, eliminating a special rule, and eliminating a source of confusion
> for the young amoung us who do not know about such things).
My counter argument is that these simplifications aren't simplifying
much - that is, the removals don't cascade and cause other
simplifications. The grammar file, for example, won't look dramatically
different if these changes are made. The simplification argument seems
weak to me because the change in overall language complexity is very
small, whereas the inconvenience caused, while not huge, is at least
significant.
That being said, line continuation is the only one I really care about.
And I would happily give up backslashes in exchange for a more sane
method of continuing lines. Either way avoids "spurious" grouping
operators which IMHO don't make for easier-to-read code.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP: Eliminate __del__
On 01/05/2007 18.09, Phillip J. Eby wrote: >> The alternative is to code the automatic finalization steps using >> weakref callbacks. For those used to using __del__, it takes a little >> while to learn the idiom but essentially the technique is hold a proxy >> or ref with a callback to a boundmethod for finalization: >> self.resource = resource = CreateResource() >> self.callbacks.append(proxy(resource, resource.closedown)) >> In this manner, all of the object's resources can be freed automatically >> when the object is collected. Note, that the callbacks only bind >> the resource object and not client object, so the client object >> can already have been collected and the teardown code can be run >> without risk of resurrecting the client (with a possibly invalid state). > > I'm a bit confused about the above. My understanding is that in order for > a weakref's callback to be invoked, the weakref itself *must still be > live*. That means that if 'self' in your example above is collected, then > the weakref no longer exists, so the closedown won't be called. Yes, but as far as I understand it, the GC does special care to ensure that the callback of a weakref that is *not* part of a cyclic trash being collected is always called. See this comment in gcmodule.c: * OTOH, if wr isn't part of CT, we should invoke the callback: the * weakref outlived the trash. Note that since wr isn't CT in this * case, its callback can't be CT either -- wr acted as an external * root to this generation, and therefore its callback did too. So * nothing in CT is reachable from the callback either, so it's hard * to imagine how calling it later could create a problem for us. wr * is moved to wrcb_to_call in this case. I might be wrong about the inners of GC, but I have used the weakref idiom many times and it always appeared to be working. > In principle I'm in favor of ditching __del__, as long as there's actually > a viable technique for doing so. My own experience has been that setting > up a simple mechanism to replace it (and that actually works) is really > difficult, because you have to find some place for the weakref itself to > live, which usually means a global dictionary or something of that > sort. Others suggested that such a framework could be prepared, but I have not seen one yet. It would be nice if the gc or weakref modules grew a facility to > make it easier to register finalization callbacks, and could optionally > check whether you were registering a callback that referenced the thing you > were tying the callback's life to. That'd be absolutely great! OTOH, the GC could possibly re-verify such assertion every time it kicks in (when a special debug flag is activated). -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP3099 += 'Assignment will not become anoperation'
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Terry Reedy wrote:
| > and hence '=' will not become an operator and hence '=' will not become
| > overloadable.
|
| Actually, '=' *is* overloadable in most cases,
It is not overloadable in the sense I meant, and in the sense people
occasionally request, which is to have '=' be an *operation* that invokes a
special method such as __assign__, just as the '+' operation invokes
'__add__'.
| you can arrange for a suitably customised object
| to be used as the namespace being assigned into.
| About the only case you can't hook is assignment
| to a local name in a function.
I mentioned purse classes in the appropriate place -- c.l.p.
I cannot think of any way to make plain assignment statements ('a =
object') at module scope do anything other than bind an object to a name in
the global namespace.
Back to my original point: people occasionally ask that assignment
statements become assignment expressions, as in C, by making '=' an
operation with an overloadable special method. Guido has consistently said
no. This came up again today. Since this is a much more frequent request
than some of the items already in 3099, I think it should be added their.
Terry Jan Reedy
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3132: Extended Iterable Unpacking
On 2 maj 2007, at 20.08, Guido van Rossum wrote: > [Georg] >>> a, *b, c = range(5) >>> a 0 >>> c 4 >>> b [1, 2, 3] > > > That sounds messy; only allowing *a at the end seems a bit more > manageable. But I'll hold off until I can shoot holes in your > implementation. ;-) As the patch works right now, any iterator will be exhausted, but if the proposal is constrained to only allowing the *name at the end, wouldn't a more useful behavior be to not exhaust the iterator, making it similar to: > it = iter(range(10)) > a = next(it) > b = it or would this be too surprising? //Simon ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3132: Extended Iterable Unpacking
Simon Percivall schrieb: > On 2 maj 2007, at 20.08, Guido van Rossum wrote: >> [Georg] a, *b, c = range(5) a > 0 c > 4 b > [1, 2, 3] >> >> >> That sounds messy; only allowing *a at the end seems a bit more >> manageable. But I'll hold off until I can shoot holes in your >> implementation. ;-) > > As the patch works right now, any iterator will be exhausted, > but if the proposal is constrained to only allowing the *name at > the end, wouldn't a more useful behavior be to not exhaust the > iterator, making it similar to: > > > it = iter(range(10)) > > a = next(it) > > b = it > > or would this be too surprising? IMO yes. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] [Python-Dev] Implicit String Concatenation and Octal Literals Was: PEP 30XZ: Simplified Parsing
Raymond> Another way to look at it is to ask whether we would consider Raymond> adding implicit string concatenation if we didn't already have Raymond> it. As I recall it was a "relatively recent" addition. Maybe 2.0 or 2.1? It certainly hasn't been there from the beginning. Skip ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] [Python-Dev] PEP 30XZ: Simplified Parsing
Ron Adam wrote: > The following inconsistency still bothers me, but I suppose it's an edge > case that doesn't cause problems. > > >>> print r"hello world\" >File "", line 1 > print r"hello world\" > ^ > SyntaxError: EOL while scanning single-quoted string > In the first case, it's treated as a continuation character even though > it's not at the end of a physical line. So it gives an error. No, that is unrelated to line continuation. The \" is an escape sequence, therefore there is no double-quote to end the string literal. -- Benji York http://benjiyork.com ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] Escaping in raw strings (was Re: [Python-Dev] PEP 30XZ: Simplified Parsing)
Benji York schrieb: > Ron Adam wrote: >> The following inconsistency still bothers me, but I suppose it's an edge >> case that doesn't cause problems. >> >> >>> print r"hello world\" >>File "", line 1 >> print r"hello world\" >> ^ >> SyntaxError: EOL while scanning single-quoted string > >> In the first case, it's treated as a continuation character even though >> it's not at the end of a physical line. So it gives an error. > > No, that is unrelated to line continuation. The \" is an escape > sequence, therefore there is no double-quote to end the string literal. But IMHO this is really something that can and ought to be fixed. I would let a raw string end at the first matching quote and not have any escaping available. That's no loss of functionality since there is no way to put a single " into a r"" string today. You can do r"\"", but it doesn't have the effect of just escaping the closing quote, so it's pretty useless. Is that something that can be agreed upon without a PEP? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] [Python-Dev] PEP 30XZ: Simplified Parsing
Benji York wrote: > Ron Adam wrote: >> The following inconsistency still bothers me, but I suppose it's an edge >> case that doesn't cause problems. >> >> >>> print r"hello world\" >>File "", line 1 >> print r"hello world\" >> ^ >> SyntaxError: EOL while scanning single-quoted string > >> In the first case, it's treated as a continuation character even though >> it's not at the end of a physical line. So it gives an error. > > No, that is unrelated to line continuation. The \" is an escape > sequence, therefore there is no double-quote to end the string literal. Are you sure? >>> print r'\"' \" It's just a '\' here. These are raw strings if you didn't notice. Cheers, Ron ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Escaping in raw strings (was Re: [Python-Dev] PEP 30XZ: Simplified Parsing)
On Thursday 03 May 2007, Georg Brandl wrote: > Is that something that can be agreed upon without a PEP? I expect this to be at least somewhat controversial, so a PEP is warranted. I'd like to see it fixed, though. -Fred -- Fred L. Drake, Jr. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] [Python-Dev] Implicit String Concatenation and Octal Literals Was: PEP 30XZ: Simplified Parsing
> "skip" == skip <[EMAIL PROTECTED]> writes: Raymond> Another way to look at it is to ask whether we would consider Raymond> adding implicit string concatenation if we didn't already have Raymond> it. skip> As I recall it was a "relatively recent" addition. Maybe 2.0 or skip> 2.1? It certainly hasn't been there from the beginning. Misc/HISTORY suggests this feature was added in 1.0.2 (May 1994). Apologies for my bad memory. Skip ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
On 5/3/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > I don't doubt that things like @before and @after are > handy. But being handy isn't enough for something to > get into the Python core. I hadn't thought of @before and @after as truly core; I had assumed they were decorators that would be available in a genfunc module. I'll agree that the actual timing of the super-call is often not essential, and having time-words confuses that. On the other hand, they do give you (1) The function being added as an overload doesn't have to know anything about the framework, or even that another method may ever be called at all; so long as the super-call is at one end, the registration function can take care of this. (2) The explicit version of next_method corresponds to super, but is uglier in practice, becaues their isn't inheritance involved. My strawman would boil down to... def foo():... next_method = GenFunc.dispatch(*args, after=__this_function__) Note that the overriding function foo would need to have both a reference to itself (as opposed to its name, which will often be bound to somthing else) and to the generic function from which it is being called (and it might be called from several such functions). Arranging this during the registration seems like an awaful lots of work to avoid @after -jJ ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] [Python-Dev] PEP 30XZ: Simplified Parsing
Barry Warsaw writes:
> The problem is that
>
> _("some string"
>" and more of it")
>
> is not the same as
>
> _("some string" +
>" and more of it")
Are you worried about translators? The gettext functions themselves
will just see the result of the operation. The extraction tools like
xgettext do fail, however. Translating the above to
# The problem is that
gettext("some string"
" and more of it")
# is not the same as
gettext("some string" +
" and more of it")
and invoking "xgettext --force-po --language=Python test.py" gives
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <[EMAIL PROTECTED]>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2007-05-03 23:32+0900\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <[EMAIL PROTECTED]>\n"
"Language-Team: LANGUAGE <[EMAIL PROTECTED]>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=CHARSET\n"
"Content-Transfer-Encoding: 8bit\n"
#: test.py:3
msgid "some string and more of it"
msgstr ""
#: test.py:8
msgid "some string"
msgstr ""
BTW, it doesn't work for the C equivalent, either.
> You would either have to teach pygettext and maybe gettext about
> this construct, or you'd have to use something different.
Teaching Python-based extraction tools about it isn't hard, just make
sure that you slurp in the whole argument, and eval it. If what you
get isn't a string, throw an exception. xgettext will be harder,
since apparently does not do it, nor does it even know enough to error
or warn on syntax it doesn't handle within gettext()'s argument.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] [Python-Dev] PEP 30XZ: Simplified Parsing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 3, 2007, at 10:40 AM, Stephen J. Turnbull wrote:
> Barry Warsaw writes:
>
>> The problem is that
>>
>> _("some string"
>>" and more of it")
>>
>> is not the same as
>>
>> _("some string" +
>>" and more of it")
>
> Are you worried about translators? The gettext functions themselves
> will just see the result of the operation. The extraction tools like
> xgettext do fail, however.
Yep, sorry, it is the extraction tools I'm worried about.
> Teaching Python-based extraction tools about it isn't hard, just make
> sure that you slurp in the whole argument, and eval it. If what you
> get isn't a string, throw an exception. xgettext will be harder,
> since apparently does not do it, nor does it even know enough to error
> or warn on syntax it doesn't handle within gettext()'s argument.
IMO, this is a problem. We can make the Python extraction tool work,
but we should still be very careful about breaking 3rd party tools
like xgettext, since other projects may be using such tools.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRjoBI3EjvBPtnXfVAQLg0AP/Y1ncqie1NgzRFzuZpnZapMs/+oo+5BCK
1MYqsJwucnDJnOqrUcU34Vq3SB7X7VsSDv3TuoTNnheinX6senorIFQKRAj4abKT
f2Y63t6BT97mSOAITFZvVSj0YSG+zkD/HMGeDj4dOJFLj1tYxgKpVprlhMbELzG1
AIKe+wsYjcs=
=+oFV
-END PGP SIGNATURE-
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
At 10:16 AM 5/3/2007 -0400, Jim Jewett wrote: >On 5/3/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > > > I don't doubt that things like @before and @after are > > handy. But being handy isn't enough for something to > > get into the Python core. > >I hadn't thought of @before and @after as truly core; I had assumed >they were decorators that would be available in a genfunc module. Everything in the PEP is imported from an "overloading" module. I'm not crazy enough to try proposing any built-ins at this point. >(2) The explicit version of next_method corresponds to super, but is >uglier in practice, becaues their isn't inheritance involved. My >strawman would boil down to... > > def foo():... > next_method = GenFunc.dispatch(*args, after=__this_function__) Keep in mind that the same function can be re-registered under multiple rules, so a reference to the function is insufficient to specify where to chain from. Also, your proposal appears to be *re-dispatching* the arguments. My implementation doesn't redispatch anything; it creates a chain of method objects, which each know their next method. These chains are created and cached whenever a new combination of methods is required. In RuleDispatch, the chains are actually linked as bound method objects, so that a function's next_method is bound as if it were the "self" of that function. Thus, calling the next method takes advantage of Python's "bound method" optimizations. >Note that the overriding function foo would need to have both a >reference to itself (as opposed to its name, which will often be bound >to somthing else) and to the generic function from which it is being >called (and it might be called from several such functions). >Arranging this during the registration seems like an awaful lots of >work to avoid @after Yep, it's a whole lot simpler just to provide the next_method as an extra argument. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3132: Extended Iterable Unpacking
On 5/3/07, Simon Percivall <[EMAIL PROTECTED]> wrote: > On 2 maj 2007, at 20.08, Guido van Rossum wrote: > > [Georg] > >>> a, *b, c = range(5) > >>> a > 0 > >>> c > 4 > >>> b > [1, 2, 3] > > > > > > That sounds messy; only allowing *a at the end seems a bit more > > manageable. But I'll hold off until I can shoot holes in your > > implementation. ;-) > > As the patch works right now, any iterator will be exhausted, > but if the proposal is constrained to only allowing the *name at > the end, wouldn't a more useful behavior be to not exhaust the > iterator, making it similar to: > > > it = iter(range(10)) > > a = next(it) > > b = it > > or would this be too surprising? In argument lists, *args exhausts iterators, converting them to tuples. I think it would be confusing if *args in tuple unpacking didn't do the same thing. This brings up the question of why the patch produces lists, not tuples. What's the reasoning behind that? STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3132: Extended Iterable Unpacking
Steven Bethard schrieb: > On 5/3/07, Simon Percivall <[EMAIL PROTECTED]> wrote: >> On 2 maj 2007, at 20.08, Guido van Rossum wrote: >> > [Georg] >> >>> a, *b, c = range(5) >> >>> a >> 0 >> >>> c >> 4 >> >>> b >> [1, 2, 3] >> > >> > >> > That sounds messy; only allowing *a at the end seems a bit more >> > manageable. But I'll hold off until I can shoot holes in your >> > implementation. ;-) >> >> As the patch works right now, any iterator will be exhausted, >> but if the proposal is constrained to only allowing the *name at >> the end, wouldn't a more useful behavior be to not exhaust the >> iterator, making it similar to: >> >> > it = iter(range(10)) >> > a = next(it) >> > b = it >> >> or would this be too surprising? > > In argument lists, *args exhausts iterators, converting them to > tuples. I think it would be confusing if *args in tuple unpacking > didn't do the same thing. > > This brings up the question of why the patch produces lists, not > tuples. What's the reasoning behind that? IMO, it's likely that you would like to further process the resulting sequence, including modifying it. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] PEP: Supporting Non-ASCII Identifiers
Hi, One item that I haven't seen mentioned in support of this is that there is code that uses getattr for accessing things that might be access other ways. For example the Attribute access Dictionaries (http://mail.python.org/pipermail/python-list/2007-March/429137.html), if one of the keys has a non ASCII character then will not be accessible through attribute access. (you could say the same for punctuation - but I think they are not the same thing). In pywinauto I try to let people use attribute access for accessing dialogs and controls of Windows applications e.g. your_app.DialogTitle.ControlCaption.Click() This works great for English - but for other languages people have to use item access your_app.[u'DialogTitle'].[u'ControlCaption'].Click() Anyway, just wanted to raise that option too for consideration. Thanks for the wonderful langauge, Mark ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3132: Extended Iterable Unpacking
On 5/3/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > Steven Bethard schrieb: > > On 5/3/07, Simon Percivall <[EMAIL PROTECTED]> wrote: > >> On 2 maj 2007, at 20.08, Guido van Rossum wrote: > >> > [Georg] > >> >>> a, *b, c = range(5) > >> >>> a > >> 0 > >> >>> c > >> 4 > >> >>> b > >> [1, 2, 3] [snip] > > In argument lists, *args exhausts iterators, converting them to > > tuples. I think it would be confusing if *args in tuple unpacking > > didn't do the same thing. > > > > This brings up the question of why the patch produces lists, not > > tuples. What's the reasoning behind that? > > IMO, it's likely that you would like to further process the resulting > sequence, including modifying it. Well if that's what you're aiming at, then I'd expect it to be more useful to have the unpacking generate not lists, but the same type you started with, e.g. if I started with a string, I probably want to continue using strings:: >>> first, *rest = 'abcdef' >>> assert first == 'a', rest == 'bcdef' By that same logic, if I started with iterators, I probably want to continue using iterators, e.g.:: >>> f = open(...) >>> first_line, *remaining_lines = f So I guess it seems pretty arbitrary to me to assume that a list is what people want to be using. And if we're going to be arbitrary, I don't see why we shouldn't be arbitrary in the same way as function arguments so that we only need on explanation. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3120 (Was: PEP Parade)
On 5/3/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Untangling the parser from stdio - sure. I also think it would > be desirable to read the whole source into a buffer, rather than > applying a line-by-line input. That might be a bigger change, > making the tokenizer a multi-stage algorithm: > 1. read input into a buffer > 2. determine source encoding (looking at a BOM, else a >declaration within the first two lines, else default >to UTF-8) > 3. if the source encoding is not UTF-8, pass it through >a codec (decode to string, encode to UTF-8). Otherwise, >check that all bytes are really well-formed UTF-8. > 4. start parsing So people could hook into their own "codec" that, say, replaced native language keywords with standard python keywords? Part of me says that should be an import hook instead of pretending to be a codec... -jJ ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP-3125 -- remove backslash continuation
On 5/2/07, Andrew Koenig <[EMAIL PROTECTED]> wrote: Looking at PEP-3125, I see that one of the rejected alternatives is to allow any unfinished expression to indicate a line continuation. I would like to suggest a modification to that alternative that has worked successfully in another programming language, namely Stu Feldman's EFL. EFL is a language intended for numerical programming; it compiles into Fortran with the interesting property that the resulting Fortran code is intended to be human-readable and maintainable by people who do not happen to have access to the EFL compiler. Anyway, the (only) continuation rule in EFL is that if the last token in a line is one that lexically cannot be the last token in a statement, then the next line is considered a continuation of the current line. Python currently has a rule that if parentheses are unbalanced, a newline does not end the statement. If we were to translate the EFL rule to Python, it would be something like this: The whitespace that follows an operator or open bracket or parenthesis can include newline characters. Note that if this suggestion were implemented, it would presumably be at a very low lexical level--even before the decision is made to turn a newline followed by spaces into an INDENT or DEDENT token. I think that this property solves the difficulty-of-parsing problem. Indeed, I think that this suggestion would be easier to implement than the current unbalanced-parentheses rule. Would this change alter where errors are reported by the parser? Is my x = x +# Oops. ... some other code ... going to have an error reported 15 lines below where the actual typo was made? Jerry ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] [Python-Dev] PEP 30XZ: Simplified Parsing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 3, 2007, at 12:41 PM, Stephen J. Turnbull wrote:
> Barry Warsaw writes:
>
>> IMO, this is a problem. We can make the Python extraction tool work,
>> but we should still be very careful about breaking 3rd party tools
>> like xgettext, since other projects may be using such tools.
>
> But
>
> _("some string" +
> " and more of it")
>
> is already legal Python, and xgettext is already broken for it.
Yep, but the idiom that *gettext accepts is used far more often. If
that's outlawed then the tools /have/ to be taught the alternative.
> Arguably, xgettext's implementation of -L Python should be
>
> execve ("pygettext", argv, environ);
>
>
Ouch. :)
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRjohUXEjvBPtnXfVAQLHhAQAmKNyjbPpIMIlz7zObvb09wdw7jyC2bBa
2w+rDilRgxicUXWqH/L6AeHHl3HiVOO+tELU6upTxOWBMlJG8xcY70rde/32I0gb
Wm0ylLlvDU/bAlSMyUscs77BVt82UQsBEqXyQ2+PRfQj7aOkpqgT8P3dwCYrtPaH
L4W4JzvoK1M=
=9pgu
-END PGP SIGNATURE-
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Escaping in raw strings (was Re: [Python-Dev] PEP 30XZ: Simplified Parsing)
On 5/3/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote: > On Thursday 03 May 2007, Georg Brandl wrote: > > Is that something that can be agreed upon without a PEP? > > I expect this to be at least somewhat controversial, so a PEP is warranted. > I'd like to see it fixed, though. It's too late for a new PEP. It certainly is controversial; how would you write a regexp that matches a single or double quote using r"..." or r'...'? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] [Python-Dev] PEP 30XZ: Simplified Parsing
On 5/3/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > > These are raw strings if you didn't notice. > > It's all in the implementation. The tokenizer takes it as an escape sequence > -- it doesn't specialcase raw strings -- the AST builder (parsestr() in ast.c) > doesn't. FWIW, it wasn't designed this way so as to be easy to implement. It was designed this way because the overwhelming use case is regular expressions, where one needs to be able to escape single and double quotes -- the re module unescapes \" and \' when it encounters them. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Escaping in raw strings (was Re: [Python-Dev] PEP 30XZ: Simplified Parsing)
Guido van Rossum schrieb: > On 5/3/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote: >> On Thursday 03 May 2007, Georg Brandl wrote: >> > Is that something that can be agreed upon without a PEP? >> >> I expect this to be at least somewhat controversial, so a PEP is warranted. >> I'd like to see it fixed, though. > > It's too late for a new PEP. It wouldn't be too late for a 2.6 PEP, would it? However, I'm not going to champion this. > It certainly is controversial; how would you write a regexp that > matches a single or double quote using r"..." or r'...'? You'd have to concatenate two string literals... Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3120 (Was: PEP Parade)
>> 1. read input into a buffer >> 2. determine source encoding (looking at a BOM, else a >>declaration within the first two lines, else default >>to UTF-8) >> 3. if the source encoding is not UTF-8, pass it through >>a codec (decode to string, encode to UTF-8). Otherwise, >>check that all bytes are really well-formed UTF-8. >> 4. start parsing > > So people could hook into their own "codec" that, say, replaced native > language keywords with standard python keywords? No, so that PEP 263 remains implemented. Martin ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP: Eliminate __del__
Giovanni Bajo wrote: > On 01/05/2007 18.09, Phillip J. Eby wrote: > > That means that if 'self' in your example above is collected, then > > the weakref no longer exists, so the closedown won't be called. > > Yes, but as far as I understand it, the GC does special care to ensure that > the callback of a weakref that is *not* part of a cyclic trash being > collected > is always called. It has nothing to do with cyclic GC. The point is that if the refcount of a weak reference drops to zero before that of the object being weakly referenced, the weak reference object itself is deallocated and its callback is *not* called. So having the resource-using object hold the weak ref to the resource doesn't work -- it has to be kept in some kind of separate registry. -- Greg ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3132: Extended Iterable Unpacking
Simon Percivall wrote: > if the proposal is constrained to only allowing the *name at > the end, wouldn't a more useful behavior be to not exhaust the > iterator, making it similar to: > > > it = iter(range(10)) > > a = next(it) > > b = it > > or would this be too surprising? It would surprise the heck out of me when I started with something that wasn't an iterator and ended up with b being something that I could only iterate and couldn't index. -- Greg ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3132: Extended Iterable Unpacking
Steven Bethard wrote: > This brings up the question of why the patch produces lists, not > tuples. What's the reasoning behind that? When dealing with an iterator, you don't know the length in advance, so the only way to get a tuple would be to produce a list first and then create a tuple from it. -- Greg ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP: Eliminate __del__
In all the threads about this PEP I still haven't seen a single example of how to write a finalizer. Let's take a specific example of a file object (this occurs in io.py in the p3yk branch). When a write buffer is GC'ed it must be flushed. The current way of writing this is simple: class BufferedWriter: def __init__(self, raw): self.raw = raw self.buffer = b"" def write(self, data): self.buffer += data if len(self.buffer) >= 8192: self.flush() def flush(self): self.raw.write(self.buffer) self.buffer = b"" def __del__(self): self.flush() How would I write this without using __del__(), e.g. using weak references? P.S. Don't bother arguing that the caller should use try/finally or whatever. That's not the point. Assuming we have a class like this where it has been decided that some method must be called upon destruction, how do we arrange for that call to happen? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP: Eliminate __del__
From: "Greg Ewing" <[EMAIL PROTECTED]> > It has nothing to do with cyclic GC. The point is that > if the refcount of a weak reference drops to zero before > that of the object being weakly referenced, the weak > reference object itself is deallocated and its callback > is *not* called. So having the resource-using object > hold the weak ref to the resource doesn't work -- it > has to be kept in some kind of separate registry. I'll write-up an idiomaticc approach an include it in PEP this weekend. Raymond ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] [Python-Dev] PEP 30XZ: Simplified Parsing
Barry Warsaw writes:
> IMO, this is a problem. We can make the Python extraction tool work,
> but we should still be very careful about breaking 3rd party tools
> like xgettext, since other projects may be using such tools.
But
_("some string" +
" and more of it")
is already legal Python, and xgettext is already broken for it.
Arguably, xgettext's implementation of -L Python should be
execve ("pygettext", argv, environ);
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] [Python-Dev] PEP 30XZ: Simplified Parsing
On Thursday 03 May 2007 15:40, Stephen J. Turnbull wrote: > Teaching Python-based extraction tools about it isn't hard, just make > sure that you slurp in the whole argument, and eval it. We generate our component documentation based on going through the AST generated by compiler.ast, finding doc strings (and other strings in other known/expected locations), and then formatting using docutils. Eval'ing the file isn't always going to work due to imports relying on libraries that may need to be installed. (This is especially the case with Kamaelia because we tend to wrap libraries for usage as components in a convenient way) We've also specifically moved away from importing the file or eval'ing things because of this issue. It makes it easier to have docs built on a random machine with not too much installed on it. You could special case "12345" + "67890" as a compile timeconstructor and jiggle things such that by the time it came out the parser that looked like "1234567890", but I don't see what that has to gain over the current form. (which doesn't look like an expression) I also think that's a rather nasty version. On the flip side if we're eval'ing an expression to get a docstring, there would be great temptation to extend that to be a doc-object - eg using dictionaries, etc as well for more specific docs. Is that wise? I don't know :) Michael. -- Kamaelia project lead http://kamaelia.sourceforge.net/Home ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] [Python-Dev] PEP 30XZ: Simplified Parsing
Michael Sparks writes: > We generate our component documentation based on going through the AST > generated by compiler.ast, finding doc strings (and other strings in > other known/expected locations), and then formatting using docutils. Are you talking about I18N and gettext? If so, I'm really lost > You could special case "12345" + "67890" as a compile timeconstructor and > jiggle things such that by the time it came out the parser that looked like > "1234567890", but I don't see what that has to gain over the current form. I'm not arguing it's a gain, simply that it's a case that *should* be handled by extractors of translatable strings anyway, and if it were, there would not be an I18N issue in this PEP. It *should* be handled because this is just constant folding. Any half-witted compiler does it, and programmers expect their compilers to do it. pygettext and xgettext are (very special) compilers. I don't see why that expectation should be violated just because the constants in question are translatable strings. I recognize that for xgettext implementing that in C for languages as disparate as Lisp, Python, and Perl (all of which have string concatenation operators) is hard, and to the extent that xgettext is recommended by 9 out of 10 translators, we need to worry about how long it's going to take for xgettext to get fixed (because it *is* broken in this respect, at least for Python). ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
