[Python-Dev] Patch Reviewing
Hello, just felt a little bored and tried to review a few (no-brainer) patches. Here are the results: * Patch #1051395 Minor fix in Lib/locale.py: Docs say that function _parse_localename returns a tuple; but for one codepath it returns a list. Patch fixes this by adding tuple(), recommending apply. * Patch #1046831 Minor fix in Lib/distutils/sysconfig.py: it defines a function to retrieve the Python version but does not use it everywhere; Patch fixes this, recommending apply. * Patch #751031 Adds recognizing JPEG-EXIF files (produced by digicams) to imghdr.py. Recommending apply. * Patch #712317 Fixes URL parsing in urlparse for URLs such as http://foo?bar. Splits at '?', so assigns 'foo' to netloc and 'bar' to query instead of assigning 'foo?bar' to netloc. Recommending apply. regards, Reinhold ___ 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] Some old patches
Hello, this time working up some of the patches with beards: - #751943 Adds the display of the line number to cgitb stack traces even when the source code is not available to cgitb. This makes sense in the case that the source is lying around somewhere else. However, the original patch generates a link to "file://?" on the occasion that the source file name is not known. I have created a new patch (#1144549) that fixes this, and also renames all local variables "file" in cgitb to avoid builtin shadowing. - #749830 Allows the mmap call on UNIX to be supplied a length argument of 0 to mmap the whole file (which is already implemented on Windows). However, the patch doesn't apply on current CVS, so I made a new patch (#1144555) that does. Recommend apply, unless this may cause problems on some Unices which I don't know about. - #547176 Allows the rlcompleter to complete on [] item access (constructs like sim[0]. could then be completed). As comments in the patch point out, this easily leads to execution of arbitrary code via __getitem__, which is IMHO a too big side effect of completing (though IPython does this). Recommend reject. - #645894 Allows the use of resource.getrusage time values for profile.py, which results in better timing resolution on FreeBSD. However, this may lead to worse timing resolution on other OS, so perhaps the patch should be changed to be restricted to this particular platform. - #697613 -- bug #670311 This handles the problem that python -i exits on SystemExit exceptions by introducting two new API functions. While it works for me, I am not sure whether this is too much overhead for fixing a glitch no one else complained about. - #802188 This adds a specific error message for invalid tokens after a '\' used as line continuation. While it may be helpful when the invalid token is whitespace, Python usually shows the exact location of the invalid token, so you can examine this line and find the error. On the other hand, the patch is no big deal, so if a specific error message is welcome, it may as well be applied. Enough for today... and best of all: I have no patch which I want to promote! Reinhold ___ 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] Re: Some old patches
Reinhold Birkenfeld wrote: > Hello, > > this time working up some of the patches with beards: No one listening? I'm sorry when patch reviews are not welcome in python-devel; in this case I'll post individual comments to the patches on SF. Reinhold ___ 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] Re: Some old patches
Aahz wrote: > On Wed, Feb 23, 2005, Reinhold Birkenfeld wrote: >> Reinhold Birkenfeld wrote: >>> >>> this time working up some of the patches with beards: >> >> No one listening? I'm sorry when patch reviews are not welcome in >> python-devel; in this case I'll post individual comments to the patches >> on SF. > > You should definitely post the patch reviews to SF no matter what; that > way there's a historical record. Patch review summaries are welcome on > python-dev, but it's the nature of the medium that they don't always get > responded to. > > BTW, it's not clear whether your e-mail address is munged or not, which > likely contributes to reluctance to respond. Well, what about trying? [I see you tried, so don't bother] I insert this "nospam" deliberately, as it keeps spam away. Perhaps it would be best to mention this in a signature. Reinhold -- Mail address is perfectly valid! ___ 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] What about CALL_ATTR?
While rummaging in the old patches, I found this: """ The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. """ (patch #709744) How is the status of this? Sounds promising, I'd say... Reinhold -- Mail address is perfectly valid! ___ 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] Legacy bugs on SF
Hello, still in 2004, this comment was added to old bugs with groups Python2.*: """ Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". """ The month is over now, so what to do with them? Note that there are other very old bugs, e.g. in the "Platform-specific" group, which I think may be closed too. Reinhold -- Mail address is perfectly valid! ___ 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] Re: @deprecated (was: Useful thread project for 2.5?)
Nick Coghlan wrote:
> Raymond Hettinger wrote:
>> Decorators like this should preserve information about the underlying
>> function:
>>
>>
>>>def deprecated(func):
>>>"""This is a decorator which can be used to mark functions
>>>as deprecated. It will result in a warning being emmitted
>>>when the function is used."""
>>>def newFunc(*args, **kwargs):
>>>warnings.warn("Call to deprecated function.")
>>>return func(*args, **kwargs)
>>
>> newFunc.__name__ = func.__name__
>> newFunc.__doc__ = func.__doc__
>> newFunc.__dict__.update(func.__dict__)
>>
>>>return newFunc
>
> A utility method on function objects could simplify this:
>newFunc.update_info(func)
+1. This is really good for 90% of all decorator uses. But maybe a
better name should be found, perhaps "update_meta".
Reinhold
--
Mail address is perfectly valid!
___
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] Re: Adding any() and all()
Guido van Rossum wrote: > See my blog: http://www.artima.com/forums/flat.jsp?forum=106&thread=98196 > > Do we even need a PEP or is there a volunteer who'll add any() and all() for > me? There is an interesting proposal in the forum: """ He proposes that [x in list if x > 0] (which is currently undefined) be exactly equal to: [x for x in list if x > 0] """ What about that? And, don't you want to save any() and all() for junctions, like those in Perl 6? Reinhold -- Mail address is perfectly valid! ___ 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] Re: Change 'env var BROWSER override' semantics in webbrowser.py
Martin v. Löwis wrote: > Rodrigo Dias Arruda Senra wrote: >> I propose a small change in webbrowse.py module. > > I think I'm generally in favour of such a change. However: > > - please don't post patches to python-dev, unless you *want* >them to be ignored. Typically, nobody will pick up patches >from python-dev and apply them, except for rare cases (e.g. >urgent bug fixes of serious breakages); post to SF instead. > - please accompany your change with a documentation patch. >It may be that the exact search procedure for browsers is >not specified yet; take that chance and specify it so >clearly that the code without your patch would actually >conflict with the documentation, so that readers of >the new code can verify that this is indeed the >documentation-mandated behaviour. > - consider integration of test cases. As this involves >startup code and environment variables, I would be willing >to waive the test case requirement here as unimplementable. >However, do consider writing test cases. Additionally, there are several patches on SF that pertain to webbrowser.py; perhaps you can review some of them... Reinhold -- Mail address is perfectly valid! ___ 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] Re: Shorthand for lambda
Ka-Ping Yee wrote: > It dawned on me that you could use this idea to make the whole > filter/lambda experience vastly more pleasant. I whipped up a quick > implementation: > > >>> from placeholder import _ > >>> numbers = [5, 9, 56, 34, 1, 24, 37, 89] > >>> filter(_ < 30, numbers) > [5, 9, 1, 24] > >>> map(_ + 10, numbers) > [15, 19, 66, 44, 11, 34, 47, 99] > >>> > > Look ma, no lambdas! What does you implementation do for this: >>> somevar = False >>> filter(_ and False, numbers) Reinhold ___ 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] Re: Shorthand for lambda
Ka-Ping Yee wrote: > On Wed, 23 Mar 2005, Reinhold Birkenfeld wrote: >> What does you implementation do for this: >> >> >>> somevar = False >> >>> filter(_ and False, numbers) > > It fails. (For the same reason that __len__ doesn't work -- > Python insists that __nonzero__ must return an int.) Though > i must say i have no idea what you are trying to do here. > If you filter on False, you'll always get an empty list. I know; I just wanted to show that this approach can be very misleading as and/or can't be overloaded. Reinhold -- Mail address is perfectly valid! ___ 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] Re: webbrowser.py
Rodrigo Dias Arruda Senra wrote: > | > On Thu, Mar 24, 2005 at 11:36:41AM -0300, Rodrigo Dias Arruda Senra > wrote: > | > > Edit libwebbrowser.tex as you see fit, then send it to me > | > > and I'll TeXify it back to you. > | > > | >Uploaded to http://python.org/sf/754022 . I am not a native English > | > speaker, and this is the first time I've edited a TeX file. Please > | > correct my grammar, spelling, TeX, whatever... > > Outstanding work Oleg. I read it through and wouldn't change a bit. > I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. > They are Ok regarding grammar, TeX and ... whatever . > I recommend to apply both files. FWIW, same judgement from me. Reinhold -- Mail address is perfectly valid! ___ 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] Re: anonymous blocks
Guido van Rossum wrote: >> What was your opinion on "where" as a lambda replacement? i.e. >> >> foo = bar(callback1, callback2) where: >> def callback1(x): >> print "hello, " >> def callback2(x): >> print "world!" > > I don't recall seeing this proposed, but I might have -- I thought of > pretty much exactly this syntax in the shower a few days ago. Gee, the time machine again! Lots of proposals on c.l.py base on the introduction of "expression suites", that is, suites embedded in arbitrary expressions. My opinion is that one will never find a suitable (;-) syntax, there's always the question of where to put the code that follows the suite (and is part of the same statement). yours, Reinhold -- Mail address is perfectly valid! ___ 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] Re: anonymous blocks
Nick Coghlan wrote: > Interestingly, with this approach, "for dummy in my_resource()" would still > wrap > the block of code in the entrance/exit code (because my_resource *is* a > generator), but it wouldn't get the try/finally semantics. > > An alternative would be to replace the 'yield None' with a 'break' or > 'continue', and create an object which supports the resource protocol and NOT > the iterator protocol. Something like: > > def my_resource(): >print "Hi!" # Do entrance code >continue # Go on with the contents of the 'with' block >print "Bye!" # Do exit code > > (This is currently a SyntaxError, so it isn't ambiguous in any way) Oh, it is ambiguous, as soon as you insert a for/while statement in your resource function and want to call continue in there. Other than that, it's very neat. Maybe "yield" alone (which is always a SyntaxError) could be used. Reinhold -- Mail address is perfectly valid! ___ 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] Re: anonymous blocks
Guido van Rossum wrote: > [Greg Ewing] >> I like the general shape of this, but I have one or two >> reservations about the details. > > That summarizes the feedback so far pretty well. I think we're on to > something. And I'm not too proud to say that Ruby has led the way here > to some extent (even if Python's implementation would be fundamentally > different, since it's based on generators, which has some different > possibilities and precludes some Ruby patterns). Five random thoughts: 1. So if break and continue are allowed in with statements only when there is an enclosing loop, it would be a inconsistency; consider for item in seq: with gen(): continue when the generator gen catches the ContinueFlow and does with it what it wants. It is then slightly unfair not to allow with x: continue Anyway, I would consider both counterintuitive. So what about making ReturnFlow, BreakFlow and ContinueFlow "private" exceptions that cannot be caught in user code and instead introducing a new statement that allows passing data to the generator? 2. In process of handling this, would it be reasonable to (re)introduce a combined try-except-finally statement with defined syntax (all except before finally) and behavior (finally is always executed)? 5. What about the intended usage of 'with' as in Visual B.. NO, NO, NOT THE WHIP! (not that you couldn't emulate this with a clever "generator": def short(x): yield x with short(my.long["object"]reference()) as _: _.spam = _.ham = _.eggs() yours, Reinhold -- Mail address is perfectly valid! ___ 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] Re: anonymous blocks
Nick Coghlan wrote: > Guido van Rossum wrote: > [snip] >> - I think there's a better word than Flow, but I'll keep using it >> until we find something better. > > How about simply reusing Iteration (ala StopIteration)? > >Pass in 'ContinueIteration' for 'continue' >Pass in 'BreakIteration' for 'break' >Pass in 'AbortIteration' for 'return' and finalisation. > > And advise strongly *against* intercepting AbortIteration with anything other > than a finally block. Hmmm... another idea: If break and continue return keep exactly the current semantics (break or continue the innermost for/while-loop), do we need different exceptions at all? AFAICS AbortIteration (+1 on the name) would be sufficient for all three interrupting statements, and this would prevent misuse too, I think. yours, Reinhold -- Mail address is perfectly valid! ___ 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] Re: PEP 340 - possible new name for block-statement
Guido van Rossum wrote: >> Another possibility just occurred to me. How about "using"? > > Blah. I'm beginning to like block just fine. With using, the choice of > word for the generator name becomes iffy IMO; and it almost sounds > like it's a simple renaming: "using X as Y" could mean "Y = X". FWIW, the first association when seeing block something: is with the verb "to block", and not with the noun, which is most displeasing. Reinhold -- Mail address is perfectly valid! ___ 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] Pre-PEP: Unifying try-except and try-finally
Hello,
after proposing this here (albeit deep in the PEP 340 thread) and
getting a somewhat affirmatory response from Guido, I have written
something that could become a PEP if sufficiently hatched...
---
PEP: XXX
Title: Unifying try-except and try-finally
Version: $Revision: $
Last-Modified: $Date: $
Author: Reinhold Birkenfeld <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 04-May-2005
Post-History:
Abstract
This PEP proposes a change in the syntax and semantics of try
statements to allow combined try-except-finally blocks. This
means in short that it would be valid to write
try:
except Exception:
finally:
Rationale/Proposal
There are many use cases for the try-except statement and
for the try-finally statement per se; however, often one needs
to catch exceptions and execute some cleanup code afterwards.
It is slightly annoying and not very intelligible that
one has to write
f = None
try:
try:
f = open(filename)
text = f.read()
except IOError:
print 'An error occured'
finally:
if f:
f.close()
So it is proposed that a construction like this
try:
except Ex1:
else:
finally:
be exactly the same as the legacy
try:
try:
except Ex1:
else:
finally:
This is backwards compatible, and every try statement that is
legal today would continue to work.
Changes to the grammar
The grammar for the try statement, which is currently
try_stmt: ('try' ':' suite (except_clause ':' suite)+
['else' ':' suite] | 'try' ':' suite 'finally' ':' suite)
would have to become
try_stmt: ('try' ':' suite (except_clause ':' suite)+
['else' ':' suite] ['finally' ':' suite] |
'try' ':' suite (except_clause ':' suite)*
['else' ':' suite] 'finally' ':' suite)
Implementation
As the PEP author currently does not have sufficient knowledge
of the CPython implementation, he is unfortunately not able
to deliver one.
References
None yet.
Copyright
This document has been placed in the public domain.
---
Reinhold
--
Mail address is perfectly valid!
___
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] PEP 340: Breaking out.
Paul Moore wrote: > On 5/4/05, Alex Martelli <[EMAIL PROTECTED]> wrote: >> >> On May 4, 2005, at 01:57, Paul Moore wrote: >> > >> > I can't think of a reasonable condition which wouldn't involve reading >> > the file - which either involves an inner loop (and we already can't >> > break out of two loops, so the third one implied by the opening block >> > makes things no worse), or needs the whole file reading (which can be >> >> Looking for a file with a certain magicnumber in its 1st two bytes...? >> >> for name in filenames: >> opening(name) as f: >> if f.read(2) == 0xFEB0: break >> >> This does seem to make real-life sense to me... > > Yes, that'd do. I can't say I think it would be common, but it's a > valid case. And the workaround is the usual messy flag variable: > > for name in filenames: > found = False > opening(name) as f: > if f.read(2) == 0xFEB0: found = True > if found: break Is there anything we could do about this? Reinhold -- Mail address is perfectly valid! ___ 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] "begin" as keyword for pep 340
Adam Souzis wrote: > I'm a bit surpised that no one has yet [1] suggested "begin" as a > keyword instead "block" as it seems to express the intent of blocks > and is concise and readable. For example, here are the examples in > PEP 340 rewritten using "begin": > > begin locking(): >... I don't know, but I always would expect "end" to follow each begin somewhere... the-good-old-pascal-days-ly yours, Reinhold PS: What about "using"? Too C#-ish? -- Mail address is perfectly valid! ___ 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] PEP 340 -- loose ends
Rodrigo Dias Arruda Senra wrote:
> [ Guido ]:
> > 1. Decide on a keyword to use, if any.
>
> Shouldn't be the other way around ?
> Decide to use *no* keyword, if that could be avoided.
[...]
> Following the PEP and this thread, it seems to me that __no keyword__
> is less preferable than __some keyword__(=='block' so far), and I wonder
> why is not the reverse. Perhaps I missed something ?
There is one problem with using no keyword: You cannot use arbitrary expressions
in the new statement. Consider:
resource = opening("file.txt")
block resource:
(...)
resource = opening("file.txt")
resource:
(...)
The latter would have to be forbidden.
(Seeing these examples, I somehow strongly dislike "block";
"with" or "using" seem really better)
Reinhold
--
Mail address is perfectly valid!
___
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] PEP 340 -- loose ends
Noam Raphael wrote:
> On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>>
>> There is one problem with using no keyword: You cannot use arbitrary
>> expressions
>> in the new statement. Consider:
>>
>> resource = opening("file.txt")
>> block resource:
>> (...)
>>
>> resource = opening("file.txt")
>> resource:
>> (...)
>>
>> The latter would have to be forbidden.
>
> Can you explain why it would have to be forbidden please?
Well, with it you could create suites with _any_ introducing
identifier. Consider:
with:
(...)
synchronized:
(...)
try:
(...)
transaction:
(...)
Do you understand my concern? It would be very, very hard to discern
these "user-defined statements" from real language constructs.
Reinhold
--
Mail address is perfectly valid!
___
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] Pre-PEP: Unifying try-except and try-finally
Tim Peters wrote: > [Guido] >> I'm +1 on accepting this now -- anybody against? > > I'm curious to know if you (Guido) remember why you removed this > feature in Python 0.9.6? From the HISTORY file: > > """ > New features in 0.9.6: > - stricter try stmt syntax: cannot mix except and finally clauses on 1 try > """ > > IIRC (and I may well not), half of people guessed wrong about whether > an exception raised in an "except:" suite would or would not skip > execution of the same-level "finally:" suite. With the arrival of Java and C#, which both have this feature, I think the wrong guesses are minimized. I think the behaviour of the "else" clause is much harder to guess, mainly when used with the looping constructs. > try: > 1/0 > except DivisionByZero: > 2/0 > finally: > print "yes or no?" > > The complementary question is whether an exception in the "finally:" > suite will be handled by the same-level "except:" suites. No, as except clauses can only occur before the finally clause, and execution should not go backwards. > There are obvious answers to both, of course. The question is whether > they're the _same_ obvious answers across responders <0.7 wink>. Reinhold -- Mail address is perfectly valid! ___ 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] PEP 340 -- loose ends
Ka-Ping Yee wrote: > Reinhold Birkenfeld wrote: >> Well, with it you could create suites with _any_ introducing >> identifier. Consider: >> >> with: >> (...) >> >> synchronized: >> (...) >> >> try: >> (...) >> >> transaction: >> (...) >> >> Do you understand my concern? It would be very, very hard to discern >> these "user-defined statements" from real language constructs. > > I think part of the debate is about whether that's good or bad. > I happen to agree with you -- i think a keyword is necessary -- > but i believe some people see an advantage in having the flexibility > to make a "real-looking" construct. Yes. But it would only be crippled, as the "keyword" would have to be a pre-constructed generator instance which cannot be easily reused as a library export (at least, it is not intended this way). > As i see it the argument boils down to: Python is not Lisp. > > There are good reasons why the language has keywords, why it > distinguishes statements from expressions, uses indentation, and > so on. All of these properties cause Python programs to be made > of familiar and easily recognizable patterns instead of degenerating > into a homogeneous pile of syntax. Big ACK. Reinhold -- Mail address is perfectly valid! ___ 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] PEP 340 -- loose ends
Shane Hathaway wrote:
> For each block statement, it is necessary to create a *new* iterator,
Right.
> since iterators that have stopped are required to stay stopped. So at a
> minimum, used-defined statements will need to call something, and thus
> will have parentheses. The parentheses might be enough to make block
> statements not look like built-in keywords.
>
> PEP 340 seems to punish people for avoiding the parentheses:
>
> transaction = begin_transaction()
>
> transaction:
> db.execute('insert 3 into mytable')
>
> transaction:
> db.execute('insert 4 into mytable')
>
> I expect that only '3' would be inserted in mytable. The second use of
> the transaction iterator will immediately raise StopIteration.
Yes, but wouldn't you think that people would misunderstand it in this way?
Reinhold
--
Mail address is perfectly valid!
___
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] Pre-PEP: Unifying try-except and try-finally
Tim Peters wrote: > [Reinhold Birkenfeld] >> ... >> I think the behaviour of the "else" clause is much harder to guess, >> mainly when used with the looping constructs. > > No, that's obvious . OK, I'm persuaded. Well you wield the Force, master. > What about `else` mixed with try/except/finally? > > try: > A > except: > B > else: > C > finally: > D > > If A executes without exception, does D execute before or after C? Given the order of the clauses, is it so ambiguous? Reinhold -- Mail address is perfectly valid! ___ 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] PEP 340: Breaking out.
Aahz wrote: > On Wed, May 04, 2005, Paul Moore wrote: >> >> Yes, that'd do. I can't say I think it would be common, but it's a >> valid case. And the workaround is the usual messy flag variable: >> >> for name in filenames: >> found = False >> opening(name) as f: >> if f.read(2) == 0xFEB0: found = True >> if found: break > > My standard workaround is using exceptions, but I'm not sure how that > interacts with a block: > > try: > for name in filenames: > with opened(name) as f: > if f.read(2) == 0xFEB0: > raise Found > except Found: > pass >From a naive point of view, it should definitely work as expected. >From the PEP point of view, no clue. *hope* Reinhold -- Mail address is perfectly valid! ___ 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] Pre-PEP: Unifying try-except and try-finally
Guido van Rossum wrote: > [François Pinard] >> It happens once in a while that I want to comment out the except clauses >> of a try statement, when I want the traceback of the inner raising, for >> debugging purposes. Syntax forces me to also comment the `try:' line, >> and indent out the lines following the `try:' line. And of course, the >> converse operation once debugging is done. This is slightly heavy. > > I tend to address this by substituting a different exception. I don't > see the use case common enough to want to allow dangling try-suites. Easy enough, adding "raise" at the top of the except clause also solves the problem. >> P.S. - Another detail, while on this subject. On the first message I've read >> on this topic, the original poster wrote something like: >> >> f = None >> try: >> f = action1(...) >> ... >> finally: >> if f is not None: >> action2(f) >> >> The proposed syntax did not repeat this little part about "None", quoted >> above, so suggesting an over-good feeling about syntax efficiency. >> While nice, the syntax still does not solve this detail, which occurs >> frequently in my experience. Oh, I do not have solutions to offer, but >> it might be worth a thought from the mighty thinkers of this list :-) > > I don't understand your issue here. What is the problem with that > code? Perhaps it ought to be rewritten as > > f = action1() > try: > ... > finally: > action2(f) > > I can't see how this would ever do something different than your version. Well, in the original the call to action1 was wrapped in an additional try-except block. f = None try: try: f = action1() except: print "error" finally: if f is not None: action2(f) Reinhold -- Mail address is perfectly valid! ___ 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] Request for dev permissions
Hello, would anybody mind if I was given permissions on the tracker and CVS, for fixing small things like bug #1202475. I feel that I can help you others out a bit with this and I promise I won't change the interpreter to accept braces... Reinhold -- Mail address is perfectly valid! ___ 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] Request for dev permissions
Raymond Hettinger wrote: > [Reinhold Birkenfeld] >> would anybody mind if I was given permissions on the tracker and CVS, > for >> fixing small >> things like bug #1202475. I feel that I can help you others out a bit > with >> this and >> I promise I won't change the interpreter to accept braces... > > Let's start out with CVS tracker permissions. > When you have a patch that is really to apply, > upload it to the tracker and assign to me. OK, thanks. Reinhold -- Mail address is perfectly valid! ___ 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] Closing old bugs
Raymond Hettinger wrote: >> I've seen some systems that solve this problem by allowing users to > "vote" >> for favorite bugs... then you can tell the "important" bugs because > they >> are more likely to have lots of votes. As I see it, Facundo is using a >> variant of that system. He is asking whether there is *ONE PERSON* out >> there who cares enough about a bug to subscribe to it and then to > respond >> to his inquiry. If there's not even one such person, then he's > closing >> the bug (but if one such person comes along later, they can re-report > it). > > -1 This is both silly and harmful. It in no way resembles a > professional approach to bug resolution. It throws away valuable > information based on some vague theory of developer marketing (i.e. > threatening to close a bug will cause a qualified, interested developer > to suddenly have both the time and inclination to address it properly). ACK so far. > If the real goal is to "kick some life" into bug resolution, then do > something that directly fulfills that goal. Host a bug day. Make a > newsgroup posting requesting thoughts on your favorite ten bugs. Write > email to people who you think are capable of addressing the particular > issue in question. Go recruit some qualified developers. Or just find > a bug that interests you and fix it. Well, to "fix it" is not so easy for most people. You have to post a patch or attach it to the bug and then wait for someone to check it in. It's not sure that this is done anytime soon (no complaint; time is short, I know). Even fixes that are agreed upon by several people are not always checked in for a long time. Reinhold -- Mail address is perfectly valid! ___ 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] sys.path in interactive session
While looking at bug #779191, I saw that sys.path's first element is '' in interactive sessions, but the current dir otherwise. Is this intentional? Reinhold -- Mail address is perfectly valid! ___ 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] Thoughts on stdlib evolvement
Hello, I am currently having some thoughts about the standard library, with regard to Python 2.5 and 3.0. Since I don't want to withhold them from you, here are they ;) - Flat namespace: Should we tend to a more hierarchic library (e.g. inet.url, inet.http, inet.nntp)? This would increase clarity when searching for a module. - 3rd party modules: There are many superb modules out there, some of which really do have a "standard" character. Examples include PIL, numarray, ElementTree, [wxPython - I know this is a hairy issue], - User interface: Tkinter may be "the" standard, but other Toolkits deserve notice, notably wxPython and PyGtk, the latter of which might be even easier to package. Reinhold, please don't hit me! -- Mail address is perfectly valid! ___ 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] Thoughts on stdlib evolvement
Skip Montanaro wrote: > Tim> On 6/6/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote: > > >> - Flat namespace: Should we tend to a more hierarchic library (e.g. > >> inet.url, inet.http, inet.nntp)? This would increase clarity when > >> searching for a module. > > Tim> -1. I feel the opposite way: when trying to figure out where > Tim> something "lives", I prefer Python's flat namespace to (for > Tim> example) Java's com.company.baz.bar.foo hierarchy. > > I think Reinhold's suggestion (e.g., inet.*) was for a flatter namespace > than Java's scheme, but for a slightly more structured namespace than the > current standard library provides. Some amount of structure helps to > collect modules together whose names don't obviously suggest who their > neighbors are in the functionality space. For example, to the naive user it > might not be obvious that these groups of modules and packages are related: > > * getopt and optparse > * bsddb, gdbm and anydbm > * email, mhlib, quopri > * heapq, collections > * user, site, sitecustomize > * profile, hotshot, pstats > * pipes, subprocess, os Yep, exactly. Java's namespaces are ugly, that's right, but a flatter version certainly improves readability. """Namespaces are one honking great idea -- let's do more of those!""" > I wouldn't mind a stdlib that defined a set of top-level packages (some of > which might be wholly unpopulated by modules in the standard distribution) > It might, for example, define a gui package and gui.Tkinter and gui._tkinter > modules, leaving the remainder of gui namespace available for 3rd party > modules. Such a scheme would probably work best if there was some fairly > lightweight registration/approval process in the community to avoid needless > collisions. For example, it might be a bit confusing if two organizations > began installing their packages in a subpackage named gui.widgets. An > unsuspecting person downloading an application that used one version of > gui.widgets into environment with the conflicting gui.widgets would run into > trouble. Is the CPAN namespace wide open? If I wanted to create a Perl > module to fit into the HTML namespace is there some procedure involved or is > it an example of squatters' rights? Personally, I think that CPAN is one of the greatest strengths of Perl. The language is a mess, and the quality of many modules is questionable, but it's incredibly easy to find a module for handling a special problem, and the namespaces are IMHO well thought out. Additionally, the docs > >> - 3rd party modules: There are many superb modules out there, some of > >> which really do have a "standard" character. Examples include PIL, > >> numarray, ElementTree, [wxPython - I know this is a hairy issue], > > Tim> I think the most important question for each of these is "is the > Tim> module's release schedule at least as stable as Python's?". For > Tim> many of these, I suspect the answer is "no". > > If you provide the necessary namespace structure for them to nestle into, I > suspect most of them could be maintained outside the stdlib just fine. Exactly! There needn't be such a big separation between stdlib and 3rd party. Access to the net is standard nowadays, though it wouldn't be of any harm making a big distribution with all modules available, for downloading and burning on CD, for example. PJE's great EasyInstall and Python Eggs will be a perfect starting point for this, I think. Reinhold -- Mail address is perfectly valid! ___ 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] Thoughts on stdlib evolvement
Fernando Perez wrote: > Skip Montanaro wrote: > >> I wouldn't mind a stdlib that defined a set of top-level packages (some of >> which might be wholly unpopulated by modules in the standard distribution) >> It might, for example, define a gui package and gui.Tkinter and gui._tkinter >> modules, leaving the remainder of gui namespace available for 3rd party >> modules. Such a scheme would probably work best if there was some fairly >> lightweight registration/approval process in the community to avoid needless >> collisions. For example, it might be a bit confusing if two organizations >> began installing their packages in a subpackage named gui.widgets. An >> unsuspecting person downloading an application that used one version of >> gui.widgets into environment with the conflicting gui.widgets would run into >> trouble. > > I've wondered if it wouldn't be better if the std lib were all stuffed into > its > own namespace: > > from std import urllib > > If a more structured approach is desired, it could be > > from std.www import urllib One may want to look at the "py.std" approach of "the py lib", found at http://codespeak.net/py/current/doc/misc.html#the-py-std-hook Reinhold -- Mail address is perfectly valid! ___ 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] Recommend accepting PEP 312 -- Simple Implicit Lambda
Kay Schluehr wrote: > Reduction provides often the advantage to make expressions/statements > scriptable what they are not in Python. Python is strong in scripting > classes/objects ( a big plus of the language ) but you can't simply use > the language to prove that > > lambda x,y: x+y*y > lambda x,y: y**2+x > > are essentialy the same functions with different implementations [1]. Except that they are not. Think of __pow__, think of __add__ and __radd__. Reinhold -- Mail address is perfectly valid! ___ 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] Recommend accepting PEP 312 -- Simple Implicit Lambda
Kay Schluehr wrote: > Reinhold Birkenfeld wrote: > >>> >>>lambda x,y: x+y*y >>>lambda x,y: y**2+x >>> >>> are essentialy the same functions with different implementations [1]. >> >> >> Except that they are not. Think of __pow__, think of __add__ and __radd__. > > You know the difference between the concept of a function and it's > infinitely many representations? That's why formal definitions exist. I must say that I don't understand what you're after. Reinhold -- Mail address is perfectly valid! ___ 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] Some RFE for review
Hi,
while bugs and patches are sometimes tricky to close, RFE can be very easy
to decide whether to implement in the first place. So what about working a
bit on this front? Here are several RFE reviewed, perhaps some can be
closed ("should" is always from submitter's point of view):
1193128:
str.translate(None, delchars) should be allowed and only delete delchars
from the string.
Review: may be a good feature, although string._idmap can be passed as the
first parameter too.
1226256:
The "path" module by Jason Orendorff should be in the standard library.
http://www.jorendorff.com/articles/python/path/
Review: the module is great and seems to have a large user base. On c.l.py
there are frequent praises about it.
1216944:
urllib(2) should gain a dict mapping HTTP status codes to the correspondig
status/error text.
Review: I can't see anything speaking against it.
1214675:
warnings should get a removefilter() method. An alternative would be to
fully document the "filters" attribute to allow direct tinkering with it.
Review: As mwh said in a comment, this isn't Java, so the latter may be
the way to go.
1205239:
Shift operands should be allowed to be negative integers, so e.g.
a << -2 is the same as a >> 2.
Review: Allowing this would open a source of bugs previously well identifiable.
1152248:
In order to read "records" separated by something other than newline, file
objects
should either support an additional parameter (the separator) to (x)readlines(),
or gain an additional method which does this.
Review: The former is a no-go, I think, because what is read won't be lines.
The latter is further complicating the file interface, so I would follow the
principle that not every 3-line function should be builtin.
1110010:
A function "attrmap" should be introduced which is used as follows:
attrmap(x)['att'] == getattr(x, 'att')
The submitter mentions the use case of new-style classes without a __dict__ used
at the right of %-style string interpolation.
Review: I don't know whether this is worth it.
1052098:
An environment variable should be supported to set the default encoding.
Review: If one wants this for a single application, he can still implement it
himself.
985094:
getattr should support a callable as the second argument, used as follows:
getattr(obj, func) == func(obj)
Review: Highly unintuitive to me.
That's all for today; sorry if it was too much ;)
Reinhold
--
Mail address is perfectly valid!
___
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] Adding the 'path' module (was Re: Some RFE for review)
Phillip J. Eby wrote: > At 06:57 PM 6/26/2005 +0200, Reinhold Birkenfeld wrote: >>1226256: >>The "path" module by Jason Orendorff should be in the standard library. >>http://www.jorendorff.com/articles/python/path/ >>Review: the module is great and seems to have a large user base. On c.l.py >>there are frequent praises about it. [...] > Aside from all these concerns, I'm +1 on adding the module. > > Here's my list of suggested changes: [...] I agree with your changes list. One more issue is open: the one of naming. As "path" is already the name of a module, what would the new object be called to avoid confusion? pathobj? objpath? Path? Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python/dist/src/Lib Cookie.py, 1.17, 1.18
Tim Peters wrote: > [EMAIL PROTECTED] >> Update of /cvsroot/python/python/dist/src/Lib >> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4891/Lib >> >> Modified Files: >>Cookie.py >> Log Message: >> bug [ 1108948 ] Cookie.py produces invalid code [...] > I assume this accounts for the current failure of test_cookie: You're right, I forgot to checkin the change to the output file. Thanks, Reinhold -- Mail address is perfectly valid! ___ 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] Adding the 'path' module (was Re: Some RFE for review)
Michael Hoffman wrote: > On Sun, 26 Jun 2005, Phillip J. Eby wrote: > >> At 08:19 PM 6/26/2005 +0100, Michael Hoffman wrote: >>> On Sun, 26 Jun 2005, Phillip J. Eby wrote: >>> * drop getcwd(); it makes no sense on a path instance >>> >>> Personally I use path.getcwd() as a class method all the time. It >>> makes as much sense as fromkeys() does on a dict instance, which is >>> technically possible but non-sensical. >> >> It's also duplication with os.path; I'm -1 on creating a new staticmethod >> for it. > > os.getcwd() returns a string, but path.getcwd() returns a new path > object. Almost everything in path is a duplication of os.path--the > difference is that the path methods start and end with path objects. +1. Reinhold -- Mail address is perfectly valid! ___ 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] Adding the 'path' module (was Re: Some RFE for review)
Phillip J. Eby wrote: > At 08:20 AM 6/27/2005 +0100, Michael Hoffman wrote: >>os.getcwd() returns a string, but path.getcwd() returns a new path >>object. > > In that case, I'd expect it to be 'path.fromcwd()' or 'path.cwd()'; i.e. a > constructor classmethod by analogy with 'dict.fromkeys()' or > 'datetime.now()'. 'getcwd()' looks like it's getting a property of a path > instance, and doesn't match stdlib conventions for constructors. > > So, +1 as long as it's called cwd() or something better (i.e. clearer > and/or more consistent with stdlib constructor conventions). You're right. +1 for calling it fromcwd(). With that settled, should I rewrite the module? Should I write a PEP? Reinhold -- Mail address is perfectly valid! ___ 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] Adding the 'path' module (was Re: Some RFEforreview)
Michael Hoffman wrote: > On Wed, 29 Jun 2005, Tony Meyer wrote: > >> Maybe this has already been answered somewhere (although I don't >> recall seeing it, and it's not in the sourceforge tracker) but has >> anyone asked Jason Orendorff what his opinion about this (including >> the module in the stdlib) is? > > I e-mailed Jason earlier this week before submitting the RFE. He said > that "I'd like to see path (or something like it) in the standard > library." He also said he didn't have time to write a PEP at the > moment, but that I should feel free to do so. > > As for me, I'm happy for Reinhold to do it if he wants. Well, as it is your RFE... ;) I'm not eager to write a PEP right now, though I think I said so in a post. I just wanted to start a discussion here, so that you can write a better PEP . Reinhold -- Mail address is perfectly valid! ___ 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] reducing self.x=x; self.y=y; self.z=z boilerplate code
Nick Coghlan wrote:
[...]
> If the right hand side of 'as' permitted the same forms as are going
> to be permitted for the 'as' clause in 'with' statements, then Ralf's
> situation could be handled via:
>
>def __init__(self as s, x as s.x, y as s.y, z as s.z):
> pass
>
> Essentially, it allows arguments to be given two names - a public name
> (before the 'as', used for keyword arguments), and a private name
> (after the 'as', not used for keyword arguments, allows easy shorthand
> aliasing of self, unpacking of tuple arguments, and easy assignment of
> instance variables).
There once was a suggestion like this on c.l.py, expanding this to other
statements, like:
if re.match('a.*b', text) as m:
# do something
What has become of this? It seems to be a wanted feature, and while I concur
that classic 'C-style' assignment-as-expression is undesirable (because of
the =/== bug-source), this would be a way, wouldn't it?
Reinhold
--
Mail address is perfectly valid!
___
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] 'With' context documentation draft (was Re: Terminology for PEP 343
Paul Moore wrote: > On 7/6/05, Michael Chermside <[EMAIL PROTECTED]> wrote: >> Paul Moore writes: >> > I also like the fact that it offers a neat 1-word name for the >> > generator decorator, "@context". >> >> Well, ok... does anyone *else* agree? I too saw this and thought "neat! >> a simple one-word name!". But then I started worrying that it's not >> defining the *context*, but rather the *context manager*. While >> "context manager" is a term I could easily imagine associating only >> with 'with' statements, "context" is too general a term... even after >> Python supports 'with' statements I will continue to use "context" >> to mean lots of different things (eg: decimal.context). > > Actually, you're starting to persuade me... Although I generally > prefer decorator names which are single words. Along with the at-sign, > underscores make the whole thing look a little too "punctuation-heavy" > for me (and don't suggest camel case, please!). Anything against @contextmanager in analogy to @staticmethod ? Reinhold -- Mail address is perfectly valid! ___ 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] Possible context managers in stdlib
Hi, I compiled a list of some possible new context managers that could be added to the stdlib. Introducing a new feature should IMO also show usage of it in the distribution itself. That wasn't done with decorators (a decorators module is compiled at the moment, if I'm right), but with context managers, there's certainly room to add some. Of course, my list is excessive, it's only some ideas I got by flying over the stdlib docs. * builtins: with open/file * sys: with sys.redirected_std[in|out|err] with sys.trace with sys.excepthook * warnings: with warnings.filter * pprint: with pprint.printer (used for print) * codecs: with codecs.open with codecs.EncodedFile * decimal: with decimal.Context * os: with os.current_directory with os.modified_env with os.umask/uid/gid etc. with os.popen with os.tmpfile * subprocess: with subprocess.Popen * mutex: with mutexobj * curses: with curses.wrapper * tempfile: with tempfile.[Named]TemporaryFile etc. * locale: with locale.differentlocale * logging: with logging.ignored with logging.Logger * signal: with signal.handler * socket: with socket.socket * threading: with threading.Lock with threading.Condition with threading.Event * mmap: with mmap.mmap * bz2/zipfile/tarfile: with ...open * dl: with dl.open * tty: with tty.raw with tty.cbreak * cgitb: with cgitb.enabled * urllib/urllib2: with urllib.urlopen etc. * httplib: with httplib.HTTPConnection * ftplib: with ftplib.FTP * poplib: with poplib.POP3 * imaplib: with imaplib.IMAP4 * nttplib: with nntplib.NNTP * smtplib: with smtplib.SMTP * telnetlib: with telnetlib.Telnet * xmlrpclib: with xmlrpclib.ServerProxy Reinhold -- Mail address is perfectly valid! ___ 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] Possible context managers in stdlib
Phillip J. Eby wrote: > At 10:24 PM 7/8/2005 +0200, Reinhold Birkenfeld wrote: >>with sys.trace > > Note that it's currently not possible to inspect the trace/profile hooks > from Python code, only from C, so that might be, um, interesting to implement. That was beyond my short view... if it can't be implemented, it won't. >>* pprint: with pprint.printer (used for print) > > Interesting; I'm not sure if I like it. > >>* os: with os.current_directory > > What does this do? Oh, I get it. The name's not very obvious. I would've > expected a more imperative name, something like 'with os.setcwd()' or 'with > os.pushdir()'. I didn't think about the names too long. ;) >> with os.modified_env >> with os.umask/uid/gid etc. > > Yeah, again I would expect more verbish names, but these are at least > easier to grasp than current_directory was. Names can be found, of course. >>* curses: with curses.wrapper >>with logging.Logger >>* tty: with tty.raw >>with tty.cbreak >>* cgitb: with cgitb.enabled > > What do these do? curses: curses.wrapper currently is a function which restores sane terminal settings after the curses program bails out. It could be a context manager too. Similar is tty.raw and tty.cbreak. These switch terminal modes, and in case of an uncaught exception the terminal will stay in this state. Context managers would restore the "sane" mode on exit. logging.Logger: hm, I didn't think about that properly. cgitb: enables or disables the full traceback view (Ok, it wouldn't be so useful). Reinhold -- Mail address is perfectly valid! ___ 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] Possible context managers in stdlib
Raymond Hettinger wrote: >> > I compiled a list of some possible new context managers that could > be >> > added to the stdlib. Introducing a new feature should IMO also show >> > usage of it in the distribution itself. That wasn't done with >> > decorators (a decorators module is compiled at the moment, if I'm >> right), >> > but with context managers, there's certainly room to add some. Of >> course, >> > my list is excessive, it's only some ideas I got by flying over the >> stdlib >> > docs. > > The PEP contains plenty of examples. If you're really feeling the need, > add something to the demo directory. > > For the most part, the applications need to work themselves out over > time through wikis, individual patch submissions, ASPN recipes, > third-party apps, etc. > > The natural evolution of best practices tends to get thwarted by > prematurely using the standard library to cast a particular solution in > stone. > > This doesn't preclude individual patches such as a context manager for > decimal.Context objects. Each proposal should be considered on its own > merits rather than as a part of an overall effort to ram a bunch of > these into the standard library.Over time, plenty of these will > sprout-up. As with decorators? Sure, plenty have sprouted up, but delivering them one release after the feature itself (if the decorators module makes it into 2.5) seems a little bit like lagging behind -- especially when good and useful examples exist. Of course, not all of these in my list are good ideas to implement. Reinhold -- Mail address is perfectly valid! ___ 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] Triple-quoted strings and indentation
Guido van Rossum wrote: > On 7/5/05, Andrew Durdin <[EMAIL PROTECTED]> wrote: >> I have written a patch that changes the way triple-quoted strings are >> scanned so that leading whitespace is ignored in much the same way >> that pep 257 handles it for docstrings. Largely this was for a >> learning experience in hacking the parser, but it would be very nice >> IMO if something of this sort could be implemented in a future version >> of Python. > > I don't think so. It smells too much of DWIM, which is very unpythonic. EIBTI. Another idea, which is much more conservative: textwrap.dedent is highly under- rated and hidden. Why not make it builtin or a string method? Reinhold -- Mail address is perfectly valid! ___ 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] Triple-quoted strings and indentation
Terry Reedy wrote: > "Andrew Durdin" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> Very likely. But given the number of times that similar proposals have >> been put forth in the past, it is reasonable to expect that they will >> be brought up again in the future by others, if this is rejected--and >> in that case, these other can simply be pointed to a thorough (but >> rejected) PEP that discusses the proposal and variants and reasons for >> rejection. > > I agree that this would be useful. I also agree with Bob Ippolito that a > new prefex might be better. Why using a new syntax construct when you can do it with existing features? We do already have str.split(), which is often used to postprocess string literals (in the perl qw() style), why not introduce str.dedent()? Reinhold -- Mail address is perfectly valid! ___ 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 patch #1214889 - file.encoding support
Hi, would anyone care to comment about this patch of mine -- https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470 It makes file.encoding read-write and lets the write() and writelines() methods obey it. Reinhold -- Mail address is perfectly valid! ___ 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] SF patch #1214889 - file.encoding support
M.-A. Lemburg wrote: > Reinhold Birkenfeld wrote: >> Hi, >> >> would anyone care to comment about this patch of mine -- >> https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470 >> >> It makes file.encoding read-write and lets the write() and writelines() >> methods >> obey it. > > Done. Please see SF. > > PS: Please don't use "-nospam" or the like email addresses when posting > to this list. Thanks. Why? This address is perfectly valid (as is written in my signature), and almost completely spam-free. Reinhold -- Mail address is perfectly valid! ___ 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] Python on PyPI
Hi, to whom it may concern: the Python package on PyPI is at version 2.3.2. Reinhold -- Mail address is perfectly valid! ___ 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] Some RFE for review
Reinhold Birkenfeld wrote:
> Hi,
>
> while bugs and patches are sometimes tricky to close, RFE can be very easy
> to decide whether to implement in the first place. So what about working a
> bit on this front? Here are several RFE reviewed, perhaps some can be
> closed ("should" is always from submitter's point of view):
Aren't there opinions to the RFE other than the "path module" one?
Reinhold
--
Mail address is perfectly valid!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python/dist/src/Doc/lib emailutil.tex,1.11,1.12
[EMAIL PROTECTED] wrote:
> Update of /cvsroot/python/python/dist/src/Doc/lib
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20654
>
> Modified Files:
> emailutil.tex
> Log Message:
> Note that usegmt is new in 2.4. Closes #1239681.
>
>
> Index: emailutil.tex
> ===
> RCS file: /cvsroot/python/python/dist/src/Doc/lib/emailutil.tex,v
> retrieving revision 1.11
> retrieving revision 1.12
> diff -u -d -r1.11 -r1.12
> --- emailutil.tex 1 Nov 2004 03:59:24 - 1.11
> +++ emailutil.tex 17 Jul 2005 11:47:46 - 1.12
> @@ -103,7 +103,8 @@
> Optional \var{usegmt} is a flag that when \code{True}, outputs a
> date string with the timezone as an ascii string \code{GMT}, rather
> than a numeric \code{-}. This is needed for some protocols (such
> -as HTTP). This only applies when \var{localtime} is \code{False}
> +as HTTP). This only applies when \var{localtime} is \code{False}.
> +New in Python 2.4.
> \end{funcdesc}
>
> \begin{funcdesc}{make_msgid}{\optional{idstring}}
Wouldn't that be \versionadded{2.4}?
Reinhold
--
Mail address is perfectly valid!
___
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 filter function
Ruslan Spivak wrote: > Hello. > > I was reading source code for bltinmodule.c and found probably erroneus > stuff in filter function. I'm newbie to python inners and don't know if > attached code is worth for a patch submission. > > I would appreciate if someone could take a look at it and if it's ok > then i'll make submission, otherwise just drop it. > TIA This is indeed a bug in the function, and could have caused memory leaks because of not releasing the preallocated tuple. Since this is evident, I fixed it by now (Python/bltinmodule.c r2.318.2.1 and r2.322), but in the future you should always post patches to SourceForge to avoid crowding python-dev. But above all, thank you for spotting this issue and helping to make Python more bug-free! Reinhold -- Mail address is perfectly valid! ___ 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 filter function
Reinhold Birkenfeld wrote: > Ruslan Spivak wrote: >> Hello. >> >> I was reading source code for bltinmodule.c and found probably erroneus >> stuff in filter function. I'm newbie to python inners and don't know if >> attached code is worth for a patch submission. >> >> I would appreciate if someone could take a look at it and if it's ok >> then i'll make submission, otherwise just drop it. >> TIA > > This is indeed a bug in the function, and could have caused memory leaks > because of not releasing the preallocated tuple. Correction: should have been "not releasing the iterator". (However, the bug would have been triggered only if the tuple could not be allocated, which is a very unlikely case). Reinhols -- Mail address is perfectly valid! ___ 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] PEP 348: Exception Reorganization for Python 3.0
Raymond Hettinger wrote: > 2. There is a lesson to be taken from a story in the ACM risks forum > where a massive phone outage was traced to a single line of C code that > ran a "break" to get out of a nested if-statement. The interesting part > is that this was known to be mission critical code yet the error > survived multiple, independent code reviews. The problem was that the > code created an optical illusion. We risk the same thing when an > "except Exception" doesn't catch ControlFlowExceptions. The > recovery/logging handler will look like it ought to catch everything, > but it won't. That is a disaster for fault-tolerant coding and for > keeping your sales demo from exploding in front of customers. I think that ControlFlowException should inherit from Exception, because it is an exception. As Raymond says, it's hard to spot this when in a hurry. But looking at the current PEP 348, why not rename BaseException to Exception and Exception to Error? That way, you could say "except Error:" instead of most of today's bare "except:" and it's clear that StopIteration or GeneratorExit won't be caught because they are not errors. Reinhold -- Mail address is perfectly valid! ___ 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] Generalised String Coercion
Guido van Rossum wrote: > The main problem for a smooth Unicode transition remains I/O, in my > opinion; I'd like to see a PEP describing a way to attach an encoding > to text files, and a way to decide on a default encoding for stdin, > stdout, stderr. FWIW, I've already drafted a patch for the former. It lets you write to file.encoding and honors this when writing Unicode strings to it. http://www.python.org/sf/1214889 Reinhold -- Mail address is perfectly valid! ___ 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] Deprecating builtin id (and moving it to sys())
Christian Robottom Reis wrote: > In Launchpad (mainly because SQLObject is used) we end up with quite a > few locals named id. Apart from the fact that naturally clobbering > builtins is a bad idea, we get quite a few warnings when linting > throughout the codebase. I've fixed these as I've found them, but today > Andrew pointed out to me that this is noted in: > > http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.ppt > > I wonder: is moving id() to sys doable in the 2.5 cycle, with a > deprecation warning being raised for people using the builtin? We'd then > phase it out in one of the latter 2.x versions. > > I've done some searching through my code and id() isn't the most-used > builtin, so from my perspective the impact would be limited, but of > course others might think otherwise. > > Is it worth writing a PEP for this, or is it crack? As I can see, this is not going to happen before Py3k, as it is completely breaking backwards compatibility. As such, a PEP would be unnecessary. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python/dist/src/Doc/tut tut.tex,1.276,1.277
[EMAIL PROTECTED] wrote:
I'm not a native speaker, but...
> @@ -114,7 +114,7 @@
> programs, or to test functions during bottom-up program development.
> It is also a handy desk calculator.
>
> -Python allows writing very compact and readable programs. Programs
> +Python enables programs to written compactly and readably. Programs
> written in Python are typically much shorter than equivalent C or
> \Cpp{} programs, for several reasons:
> \begin{itemize}
...shouldn't it be "programs to be written compactly"?
> @@ -1753,8 +1753,8 @@
>
> \begin{methoddesc}[list]{pop}{\optional{i}}
> Remove the item at the given position in the list, and return it. If
> -no index is specified, \code{a.pop()} returns the last item in the
> -list. The item is also removed from the list. (The square brackets
> +no index is specified, \code{a.pop()} removes and returns the last item
> +in the list. The item is also removed from the list. (The square brackets
> around the \var{i} in the method signature denote that the parameter
> is optional, not that you should type square brackets at that
> position. You will see this notation frequently in the
Thats twice the same the same (removal from list).
> @@ -1985,7 +1987,9 @@
> \section{The \keyword{del} statement \label{del}}
>
> There is a way to remove an item from a list given its index instead
> -of its value: the \keyword{del} statement. This can also be used to
> +of its value: the \keyword{del} statement. Unlike the \method{pop()})
> +method which returns a value, the \keyword{del} keyword is a statement
> +and can also be used to
> remove slices from a list (which we did earlier by assignment of an
> empty list to the slice). For example:
The del keyword is a statement?
> @@ -2133,8 +2137,8 @@
> keys. Tuples can be used as keys if they contain only strings,
> numbers, or tuples; if a tuple contains any mutable object either
> directly or indirectly, it cannot be used as a key. You can't use
> -lists as keys, since lists can be modified in place using their
> -\method{append()} and \method{extend()} methods, as well as slice and
> +lists as keys, since lists can be modified in place using methods like
> +\method{append()} and \method{extend()} or modified with slice and
> indexed assignments.
Is the second "modified" necessary?
> @@ -5595,8 +5603,8 @@
> to round it again can't make it better: it was already as good as it
> gets.
>
> -Another consequence is that since 0.1 is not exactly 1/10, adding 0.1
> -to itself 10 times may not yield exactly 1.0, either:
> +Another consequence is that since 0.1 is not exactly 1/10,
> +summing ten values of 0.1 may not yield exactly 1.0, either:
>
> \begin{verbatim}
> >>> sum = 0.0
Is it clear from context that the "0.1 is not exactly 1/10" refers to
floating point only?
> @@ -5637,7 +5645,7 @@
> you can perform an exact analysis of cases like this yourself. Basic
> familiarity with binary floating-point representation is assumed.
>
> -\dfn{Representation error} refers to that some (most, actually)
> +\dfn{Representation error} refers to fact that some (most, actually)
> decimal fractions cannot be represented exactly as binary (base 2)
> fractions. This is the chief reason why Python (or Perl, C, \Cpp,
> Java, Fortran, and many others) often won't display the exact decimal
"...refers to the fact..."?
Reinhold
--
Mail address is perfectly valid!
___
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] Docs/Pointer to Tools/scripts?
Hi, after adding Oleg Broytmann's findnocoding.py to Tools/scripts, I wonder whether the Tools directory is documented at all. There are many useful scripts there which many people will not find if they are not listed anywhere in the docs. Just a thought. Reinhold -- Mail address is perfectly valid! ___ 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] Bare except clauses in PEP 348
Raymond Hettinger wrote: >> Deprecation means your code will still work I hope every book that >> documents "except:" also adds "but don't use this except under very >> special circumstances". >> >> I think you're overreacting (again), Raymond. 3.0 will be much more >> successful if we can introduce many of its features into 2.x. Many of >> those features are in fact improvements of the language even if they >> break old code. We're trying to balance between breaking old code and >> introducing new features; deprecation is the accepted way to do this. > Fredrik, please speak up. Someone should represent the users here. I'm > reached my limit on how much time I can devote to thinking out the > implications of these proposals. Someone else needs to "overreact". Perhaps I may add a pragmatic POV (yes, I know that "pragmatic" is usually attributed to another language ;-). If "except:" issues a deprecation warning in 2.5, many people will come and say "woohoo, Python breaks backwards compatibility" and "I knew it, Python is unreliable, my script issues 1,233 warnings now" and such. You can see this effect looking at the discussion that broke out when Guido announced that map, filter and reduce would vanish (as builtins) in 3.0. People spoke up and said, "if that's going to be the plan, I'll stop using Python" etc. That said, I think that unless it is a new feature (like with statements) transitions to Python 3.0 shouldn't be enforced in the 2.x series. With 3.0, everyone expects a clear cut and a compatibility breach. Reinhold -- Mail address is perfectly valid! ___ 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] operator.c for release24-maint and test_bz2 on Python 2.4.1
A.B., Khalid wrote:
> Hello there,
>
>
> The release24-maint check-ins for today contained this typo:
>
> ===
> RCS file: /cvsroot/python/python/dist/src/Modules/operator.c,v
> retrieving revision 2.29
> retrieving revision 2.29.4.1
> diff -u -d -r2.29 -r2.29.4.1
> --- operator.c 4 Dec 2003 22:17:49 - 2.29
> +++ operator.c 26 Aug 2005 06:43:16 - 2.29.4.1
> @@ -267,6 +267,9 @@
> itemgetterobject *ig;
> PyObject *item;
>
> + if (!_PyArg_NoKeywords("itemgetter()", kdws)) <- kdws should be kwds
> + return NULL;
> +
> if (!PyArg_UnpackTuple(args, "itemgetter", 1, 1, &item))
> return NULL;
Thank you, that is corrected now.
> However, and in Python 2.4.1 the following happens when the test is not
> invoked from an interpreted session:
>
> $ python ../Lib/test/test_bz2.py
> testBug1191043 (__main__.BZ2FileTest) ... ERROR
> ERROR
[...]
> ==
> ERROR: testBug1191043 (__main__.BZ2FileTest)
> --
> Traceback (most recent call last):
> File "../Lib/test/test_bz2.py", line 255, in testBug1191043
>lines = bz2f.readlines()
> RuntimeError: wrong sequence of bz2 library commands used
>
> ==
> ERROR: testBug1191043 (__main__.BZ2FileTest)
> --
> Traceback (most recent call last):
> File "../Lib/test/test_bz2.py", line 47, in tearDown
>os.unlink(self.filename)
> OSError: [Errno 13] Permission denied: '@test'
>
> --
> Ran 33 tests in 6.210s
>
> FAILED (errors=2)
> Traceback (most recent call last):
> File "../Lib/test/test_bz2.py", line 357, in ?
>test_main()
> File "../Lib/test/test_bz2.py", line 353, in test_main
>FuncTest
> File "G:\PROJS\PY24\PYTHON\DIST\SRC\lib\test\test_support.py", line 290, in
> run_unittest
>run_suite(suite, testclass)
> File "G:\PROJS\PY24\PYTHON\DIST\SRC\lib\test\test_support.py", line 274, in
> run_suite
>raise TestFailed(msg)
> test.test_support.TestFailed: errors occurred; run in verbose mode for
> details
Are you sure that you are calling the newly-built python.exe? It is strange that
the test should pass in interactive mode when it doesn't in normal mode.
For a confirmation, can you execute this piece of code both interactively and
from a file:
data =
'BZh91AY&SY\xd9b\x89]\x00\x00\x00\x03\x80\x04\x00\x02\x00\x0c\x00
\x00!\x9ah3M\x13<]\xc9\x14\xe1BCe\x8a%t'
f = open('test.bz2', "wb")
f.write(data)
f.close()
bz2f = BZ2File('test.bz2')
lines = bz2f.readlines()
bz2f.close()
assert lines == ['Test']
bz2f = BZ2File('test.bz2)
xlines = list(bz2f.xreadlines())
bz2f.close()
assert lines == ['Test']
os.unlink('test.bz2')
Reinhold
--
Mail address is perfectly valid!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python/dist/src/Lib/test test_bz2.py, 1.18, 1.19
Tim Peters wrote: > [EMAIL PROTECTED] >> Update of /cvsroot/python/python/dist/src/Lib/test >> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4822/Lib/test >> >> Modified Files: >>test_bz2.py >> Log Message: >> Add list() around xreadlines() >> >> >> >> Index: test_bz2.py >> === >> RCS file: /cvsroot/python/python/dist/src/Lib/test/test_bz2.py,v >> retrieving revision 1.18 >> retrieving revision 1.19 >> diff -u -d -r1.18 -r1.19 >> --- test_bz2.py 21 Aug 2005 14:16:04 - 1.18 >> +++ test_bz2.py 26 Aug 2005 13:23:54 - 1.19 >> @@ -191,7 +191,7 @@ >> def testSeekBackwardsFromEnd(self): >> # "Test BZ2File.seek(-150, 2)" >> self.createTempFile() >> -bz2f = BZ2File(self.filename) >> +)bz2f = BZ2File(self.filename) > > Note that this added a right parenthesis to the start of the line. > That creates a syntax error, so this test could not have been tried > before checking in. It also causes test_compiler to fail. Thank you for correcting. The parenthesis must have been accidentally slipped in while I was reviewing the change for correctness. Reinhold -- Mail address is perfectly valid! ___ 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] Remove str.find in 3.0?
Bill Janssen wrote: >> There are basically two ways for a system, such as a >> Python function, to indicate 'I cannot give a normal response." One (1a) >> is to give an inband signal that is like a normal response except that it >> is not (str.find returing -1). A variation (1b) is to give an inband >> response that is more obviously not a real response (many None returns). >> The other (2) is to not respond (never return normally) but to give an >> out-of-band signal of some sort (str.index raising ValueError). >> >> Python as distributed usually chooses 1b or 2. I believe str.find and >> .rfind are unique in the choice of 1a. > > Doubt it. The problem with returning None is that it tests as False, > but so does 0, which is a valid string index position. Heh. You know what the Perl6 folks would suggest in this case? return 0 but true; # literally! > Might add a boolean "str.contains()" to cover this test case. There's already __contains__. Reinhold -- Mail address is perfectly valid! ___ 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] test_bz2 on Python 2.4.1
A.B., Khalid wrote: > #--- Python 2.5a0 from CVS -# > # Result: passes > $ /g/projs/py25/python/dist/src/MinGW/python testbz2.py > > > #--- Python 2.4.1 from CVS -# > # Result: fails > $ /g/projs/py24/python/dist/src/MinGW/python testbz2.py > Traceback (most recent call last): > File "testbz2.py", line 9, in ? > lines = bz2f.readlines() > RuntimeError: wrong sequence of bz2 library commands used I don't understand this. The sources for the bz2 modules are exactly equal in both branches. How do you check out the 2.4.1 from CVS? Reinhold -- Mail address is perfectly valid! ___ 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] Remove str.find in 3.0?
Raymond Hettinger wrote: > [Martin] >> For another example, file.read() returns an empty string at EOF. > > When my turn comes for making 3.0 proposals, I'm going to recommend > nixing the "empty string at EOF" API. That is a carry-over from C that > made some sense before there were iterators. Now, we have the option of > introducing much cleaner iterator versions of these methods that use > compact, fast, and readable for-loops instead of multi-statement > while-loop boilerplate. I think for char in iter(lambda: f.read(1), ''): pass is not bad, too. Reinhold -- Mail address is perfectly valid! ___ 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] test_bz2 on Python 2.4.1
A.B., Khalid wrote: >>>#--- Python 2.4.1 from CVS -# [test_bz2] >>>RuntimeError: wrong sequence of bz2 library commands used >> >>I don't understand this. The sources for the bz2 modules are exactly equal >>in both branches. > > I know. Even the tests are equal. I didn't say that these files are to > blame, I just said that the test is failing in Python 2.4.1 on Windows. > cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/python login > cvs -z7 -d :pserver:[EMAIL PROTECTED]:/cvsroot/python update -dP > -r release24-maint python > > And it is, more or less, the same way I check out other branches. No problem here, just eliminating possibilities. Could anyone else on Windows please try the test_bz2, too? Reinhold -- Mail address is perfectly valid! ___ 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] Proof of the pudding: str.partition()
Bill Janssen wrote:
>> >(*) Regular Expressions
>>
>> This can be orthogonally added to the 're' module, and definitely should
>> not be part of the string method.
>
> Sounds right to me, and it *should* be orthogonally added to the 're'
> module coincidentally simultaneously with the change to the string
> object :-).
>
> I have to say, it would be nice if
>
>"foo bar".partition(re.compile('\s'))
>
> would work. That is, if the argument is an re pattern object instead
> of a string, it would be nice if it were understood appropriately,
> just for symmetry's sake. But it's hardly necessary.
And it's horrible, for none of the other string methods accept a RE.
In Python, RE functionality is in the re module and nowhere else, and this
is a Good Thing. There are languages which give REs too much weight by
philosophy
(hint, hint), but Python isn't one of them. Interestingly, Python programmers
suffer less from the "help me, my RE doesn't work" problem.
Reinhold
--
Mail address is perfectly valid!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
Greg Ewing wrote: > Charles Cazabon wrote: > >> Perhaps py3k could have a py2compat module. Importing it could have the >> effect of (for instance) putting compile, id, and intern into the global >> namespace, making print an alias for writeln, > > There's no way importing a module could add something that > works like the old print statement, unless some serious > magic is going on... You'd have to enclose print arguments in parentheses. Of course, the "trailing comma" form would be lost. Reinhold -- Mail address is perfectly valid! ___ 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] Replacement for print in Python 3.0
Guido van Rossum wrote: > [Charles Cazabon] >> >> Perhaps py3k could have a py2compat module. Importing it could have the >> >> effect of (for instance) putting compile, id, and intern into the global >> >> namespace, making print an alias for writeln, > > [Greg Ewing] >> > There's no way importing a module could add something that >> > works like the old print statement, unless some serious >> > magic is going on... > > [Reinhold Birkenfeld] >> You'd have to enclose print arguments in parentheses. Of course, the >> "trailing >> comma" form would be lost. > > And good riddance! The print statement harks back to ABC and even > (unvisual) Basic. Out with it! Here I have to agree with Barry. print is very handy, and print>> is, too. I'd rather see exec and assert becoming a function. > A transitional strategy could be to start designing the new API and > introduce it in Python 2.x. Here's my strawman: > > (1) Add two new methods the the stream (file) API and extend write(): > stream.write(a1, a2, ...) -- equivalent to map(stream.write, map(str, > [a1, a2, ...])) > stream.writeln(a1, a2, ...) -- equivalent to stream.write(a1, a2, ..., "\n") > stream.writef(fmt, a1, a2, ...) -- equivalent to stream.write(fmt % > (a1, a2, ...)) Do we really need writef()? It seems to be not much better than its %-formatting equivalent. > (2) Add builtin functions write(), writeln(), writef() that call the > corresponding method on sys.stdout. (Note: these should not just be > the bound methods; assignment to sys.stdout should immediately affect > those, just like for print. There's an important use case for this.) If write* is introduced, this is absolutely necessary. Reinhold -- Mail address is perfectly valid! ___ 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] Replacement for print in Python 3.0
Raymond Hettinger wrote: >> Do we really need writef()? It seems to be not much better than its %- >> formatting >> equivalent. > > Actually, formatting needs to become a function. The overloading of the > arithmetic mod operator has proven to be unfortunate (if only because of > precedence issues). But then, a format() function would be necessary (equivalent to sprintf) > Also, the format coding scheme itself needs to be revisited. There is > no shortage of people who have taken issue with the trailing s in > %(myvar)s. That's a nuisance, right. Reinhold -- Mail address is perfectly valid! ___ 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] Tools directory (Was RE: Replacement for print in Python 3.0)
Brett Cannon wrote: > On 9/8/05, Tony Meyer <[EMAIL PROTECTED]> wrote: >> [finding Tools/i18n/pygettext.py] >> > You're right, I think Tools is probably a bad place for >> > anything. If it's not part of the stdlib, I'll likely never >> > find it. >> >> Agreed. Maybe with the introduction of -m in Python 2.4, some of the Tools/ >> scripts could be put in __main__ sections of appropriate modules? So that >> "python -m gettext" would be equivilant to "python Tools/i18n/pygettext.py"? Questionable. Most scripts don't correspond to a single library module. >> (However, pyggettext.py is 22KB, which is a big addition to the module; not >> everything in Tools/Scripts might be used enough for this, or have an >> appopriate module to be put in either). >> >> Are there other ideas about how Tools/ could be improved? Either moving >> things, or making it more likely that people will look there for scripts? >> > > I assume that the Windows installer includes the Tools/ directory. If > it doesn't that is one problem. =) > > Otherwise it is mostly a lack of advertisement and them not being > installed by ``make install``. If you just download the soure and > install you will never know the directory even exists. It needs to be > made obvious to people that it is even there. +1. Most non-Windows users with distribution-supplied Pythons will never get the Tools directory on their installs though there is a number of really useful scripts there. Question is, if ``make install`` should install it, where? Has the time come for /usr/share/python? Or /usr/lib/pythonX.Y/Tools (without __init__.py)? > Probably the only way is to document the directory. I think so, too. The tools are worth a top-level documentation entry. Reinhold -- Mail address is perfectly valid! ___ 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] speeding up list append calls
Martin v. Löwis wrote: > Neal Norwitz wrote: >> This code doesn't really work in general. It assumes that any append >> function call is a list method, which is obviously invalid. But if a >> variable is known to be a list (ie, local and assigned as list >> (BUILD_LIST) or a list comprehension), could we do something like this >> as a peephole optimization? > > Alternatively, couldn't LIST_APPEND check that this really is a list, > and, if it isn't, fall back to PyObject_CallMethod? Are there any other optimizations which solely act on the name of a method? This seems a step too far. Reinhold -- Mail address is perfectly valid! ___ 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] Term unification
Hi, looking at bug #1283289, I saw that the term "keyword parameter" is used in Python/getargs.c, mixed with "keyword argument". Grepping through the source, "keyword parameter" had 43 matches, while "keyword argument" had 430. Should the "parameter" form be extinguished? Reinhold (And BTW, should bug #1283289 be fixed as the poster suggests?) -- Mail address is perfectly valid! ___ 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] Term unification
Ah, ok. Then I guess everything's fine. It was just the /* make sure there are no duplicate values for an argument; its not clear when to use the term "keyword argument vs. keyword parameter in messages */ that disturbed me. Reinhold Guido van Rossum wrote: > Correct usage is argument for the call site but parameter for the > function/method definition. So you can't just count occurrences. > > On 9/14/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote: >> Hi, >> >> looking at bug #1283289, I saw that the term "keyword parameter" is used in >> Python/getargs.c, mixed with "keyword argument". >> >> Grepping through the source, "keyword parameter" had 43 matches, while >> "keyword argument" had 430. Should the "parameter" form be extinguished? >> >> Reinhold >> >> (And BTW, should bug #1283289 be fixed as the poster suggests?) -- Mail address is perfectly valid! ___ 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] str.dedent
Hi, some time ago, I proposed a string method "dedent" (which currently is in the textwrap module). The RFE is at http://python.org/sf/1237680. Any opinions? If I don't get positive comments, I'll reject it. Reinhold -- Mail address is perfectly valid! ___ 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] str.dedent
Okay. I consider it rejected. Reinhold Guido van Rossum wrote: >>From the sound of it, it's probably not worth endowing every string > object with this method and hardcoding its implementation forever in C > code. There are so many corner cases and variations on the > functionality of "dedenting" a block that it's better to keep it as > Python source code. > > On 9/14/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote: >> Hi, >> >> some time ago, I proposed a string method "dedent" (which currently is in the >> textwrap module). The RFE is at http://python.org/sf/1237680. >> >> Any opinions? If I don't get positive comments, I'll reject it. >> >> Reinhold > -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python/dist/src/Lib urllib.py, 1.165.2.1, 1.165.2.2
[EMAIL PROTECTED] wrote: > Update of /cvsroot/python/python/dist/src/Lib > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31892 > > Modified Files: > Tag: release24-maint > urllib.py > Log Message: > Sync-up with patches to the head. > Includes SF 1016880: urllib.urlretrieve silently truncates downloads > and the performance fix-ups. This last patch includes a new exception, are you sure that this can be safely backported? If so, the documentation changes must be backported, too. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python/dist/src/Lib urllib.py, 1.165.2.1, 1.165.2.2
Raymond Hettinger wrote:
> [Reinhold Birkenfeld]
>> This last patch includes a new exception, are you sure that this can
> be
>> safely backported?
>
> Not too worried about it. Better to have the exception reported than
> the silent failure that confused the heck out of everyone who tried to
> figure-out what caused the OP's problem.
>
>
>
>> If so, the documentation changes must be backported, too.
>
> Maybe. My thought is the new message is akin to an improved error
> message. However, adding it to the Py2.4 docs suggests that you could
> catch and handle the exception, but that cannot be done portably across
> Py2.4 versions. If you really feel the need, go ahead and add to the
> docs with \versionadded{2.4.2}. My preference is to leave it be.
Makes sense. It'll be best to leave it be.
Reinhold
--
Mail address is perfectly valid!
___
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] possible memory leak on windows (valgrind report)
Neal Norwitz wrote: > I ran 2.4.x through valgrind and found two small problems on Linux > that have been fixed. There may be some other issues which could > benefit from more eyes (small, probably one time memory leaks). The > entire run is here: > > http://python.org/valgrind-2.4.2.out > > (I need to write a lot more suppression rules for gentoo.) > > I think I see a memory leak in win32_startfile. Since I don't run > windows I can't test it. > filepath should be allocated with the et flag to PyArgs_ParseTuple(), > but it wasn't freed without this patch. Does this make sense? See > the attached patch. Applied the patch, this was my fault. Reinhold -- Mail address is perfectly valid! ___ 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] "and" and "or" operators in Py3.0
Raymond Hettinger wrote: > I propose that in Py3.0, the "and" and "or" operators be simplified to > always return a Boolean value instead of returning the last evaluated > argument. No, please not. It's useful sometimes and doesn't hurt most times. > 1) The construct can be error-prone. When an error occurs it can be > invisible to the person who wrote it. I got bitten in published code > that had survived testing and code review: > > def real(self): > 'Return a vector with the real part of each input element' > # do not convert integer inputs to floats > return self.map(lambda z: type(z)==types.ComplexType and z.real or > z) I'm surprised you wrote that in the first place. The "and/or conditional" is one of the few occurences where one will carefully look for false values in the "and" part. > The code fails silently when z is (0+4i). It took a good while to trace > down a user reported error (when Matlab results disagreed with my matrix > module results) and determine that the real() method contained an error. > Even when traced down, I found it hard to see the error in the code. > Now that I know what to look for, it has not happened again, but I do > always have to stare hard at any "and/or" group to mentally verify each > case. [...] > P.S. Simplifying "and" and "or" may create a need to introduce a > conditional operator but that is a discussion for another day. Exactly. A conditional was turned down some time ago, for good reasons. Reinhold -- Mail address is perfectly valid! ___ 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] Adding a conditional expression in Py3.0
Guido van Rossum wrote: > Given this realization, I'm now -1 on Raymond's idea, and +1 on adding > a conditional expression. I believe (y if x else z) was my favorite > last time, wasn't it? I've changed the subject accordingly. As the PEP states, I'm not sure if changing the customary order of "arguments" in conditional expressions is good. Also, I assume the thing will be short-circuiting, and it's confusing to grasp that y in (y if x else z) will possibly never be evaluated. Reinhold -- Mail address is perfectly valid! ___ 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] Adding a conditional expression in Py3.0
Jason Orendorff wrote: > Honestly, I think I would prefer this syntax. Examples from real > code, before and after: > > lines = [line for line in pr.block.body > if line.logical_line.strip() != ''] > lines = [for line in pr.block.body: > if line.logical_line.strip() != '': > line] > > row.values = \ > [line[col.start:col.end].strip() for col in columns] > row.values = \ > [for col in columns: line[col.start:col.end].rstrip()] > > return [p for p in self.listdir(pattern) if p.isdir()] > return [for p in self.listdir(pattern): if p.isdir(): p] -1. Too much similarity with the for/if statement. People would say "why can we put a for statement in brackets but not a try statement". Reinhold -- Mail address is perfectly valid! ___ 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] IMPORTANT: release24-maint branch is FROZEN from 2005-09-21 00:00 UTC for 2.4.2
Anthony Baxter wrote: > Starting in about 11 hours time, the release24-maint branch is FROZEN > for the 2.4.2c1 release. The freeze will last for around a day, and > then we're in a state of mostly-frozen for another week, until 2.4.2 > (final). During that week, please don't check things into the branch > unless you check with me first. Let's make this a nice painless > release. > > I'll send another message once 2.4.2 is done. Do you think the patch at https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298449&group_id=5470 could go in before 2.4.2 final? It's a rather major issue within cStringIO.writelines(). Reinhold -- Mail address is perfectly valid! ___ 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] Adding a conditional expression in Py3.0
Sokolov Yura wrote: > Sorry for looking in every hole. > Just a suggestion. > > A= condition and first or second > problem is in case when first in (None,0,[],""). > May be invent new operator 'take'. > take - returns right operator when left evals to True and stops > computing condidtional expression. > Then we could write: > > A = condition take first or second. > A = x==y take w or s > A = z is not None and q!=12 take [] or allowable(z,q) take [(z,q)] or > "Impossible" > > Ok, it might looks ugly. But may be not. One of the advantages of (if x then y else z) is that it doesn't require the introduction of a new keyword (I think the "then" could be special- cased like "as" in the import statement). Reinhold -- Mail address is perfectly valid! ___ 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] inplace operators and __setitem__
Hi, a general question. Consider: class A(list): def __setitem__(self, index, item): # do something with index and item return list.__setitem__(self, index, item) lst = A([1,set()]) lst[0] |= 1 lst[1] |= set([1]) Do we want lst.__setitem__ to be called in the second inplace assignment? A case where this matters is here: http://python.org/sf/1306777 Reinhold -- Mail address is perfectly valid! ___ 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] inplace operators and __setitem__
Phillip J. Eby wrote: >>A case where this matters is here: http://python.org/sf/1306777 > > I've closed it as invalid; the behavior is as-defined. > > In principle, there *could* be an optimization to avoid rebinding the > lvalue in the case where the __i*__ form did return self. But using it for > the purpose of allowing augmented assignment to tuple members seems dubious > at best, and likely to create confusion about the mutability or lack > thereof of tuples. IMO it's better to have augmented assignment to tuple > members always fail, so that the code has to be a little more specific > about its intent. Okay. I assume that we must accept that s = set() t = (s,) t[0] |= set([1]) changes s in spite of raising TypeError. Reinhold -- Mail address is perfectly valid! ___ 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] Tests and unicode
Hi, I looked whether I could make the test suite pass again when compiled with --disable-unicode. One problem is that no Unicode escapes can be used since compiling the file raises ValueErrors for them. Such strings would have to be produced using unichr(). Is this the right way? Or is disabling Unicode not supported any more? Reinhold -- Mail address is perfectly valid! ___ 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] Tests and unicode
Martin v. Löwis wrote: > Reinhold Birkenfeld wrote: >> One problem is that no Unicode escapes can be used since compiling >> the file raises ValueErrors for them. Such strings would have to >> be produced using unichr(). > > You mean, in Unicode literals? There are various approaches, depending > on context: > - you could encode the literals as UTF-8, and decode it when the > module/test case is imported. See test_support.TESTFN_UNICODE > for an example. > - you could use unichr > - you could use eval, see test_re for an example Okay. I can fix this, but several library modules must be fixed too (mostly simple fixes), e.g. pickletools, gettext, doctest or encodings. >> Is this the right way? Or is disabling Unicode not supported any more? > > There are certainly tests that cannot be executed when Unicode is not > available. It would be good if such tests get skipped instead of being > failing, and it would be good if all tests that do not require Unicode > support run even when Unicode support is missing. That's my approach too. > Whether "it is supported" is a tricky question: your message indicates > that, right now, it is *not* supported (or else you wouldn't have > noticed a problem). Well, the core builds without Unicode, and any code that doesn't use unicode should run fine too. But the tests fail at the moment. > Whether we think it should be supported depends > on who "we" is, as with all these minor features: some think it is > a waste of time, some think it should be supported if reasonably > possible, and some think this a conditio sine qua non. It certainly > isn't a release-critical feature. Correct. I'll see if I have the time. Reinhold -- Mail address is perfectly valid! ___ 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] Extending tuple unpacking
Greg Ewing wrote: > Guido van Rossum wrote: > >> BTW, what should >> >> [a, b, *rest] = (1, 2, 3, 4, 5) >> >> do? Should it set rest to (3, 4, 5) or to [3, 4, 5]? > > Whatever type is chosen, it should be the same type, always. > The rhs could be any iterable, not just a tuple or a list. > Making a special case of preserving one or two types doesn't > seem worth it to me. I don't think that [a, b, c] = iterable is good style right now, so I'd say that [a, b, *rest] = iterable should be disallowed or be the same as with parentheses. It's not intuitive that rest could be a list here. >> ? And then perhaps >> >> *rest = x >> >> should mean >> >> rest = tuple(x) >> >> Or should that be disallowed > > Why bother? What harm would result from the ability to write that? > >> There certainly is a need for doing the same from the end: >> >> *rest, a, b = (1, 2, 3, 4, 5) > > I wouldn't mind at all if *rest were only allowed at the end. > There's a pragmatic reason for that if nothing else: the rhs > can be any iterable, and there's no easy way of getting "all > but the last n" items from a general iterable. > >> Where does it stop? > > For me, it stops with *rest only allowed at the end, and > always yielding a predictable type (which could be either tuple > or list, I don't care). +1. Tuple is more consistent. >> BTW, and quite unrelated, I've always felt uncomfortable that you have to >> write >> >> f(a, b, foo=1, bar=2, *args, **kwds) >> >> I've always wanted to write that as >> >> f(a, b, *args, foo=1, bar=2, **kwds) > > Yes, I'd like that too, with the additional meaning that > foo and bar can only be specified by keyword, not by > position. That would be a logical consequence. But one should also be able to give default values for positional parameters. So: foo(a, b, c=1, *args, d=2, e=5, **kwargs) ^ positionalonly with kw or with kw Reinhold -- Mail address is perfectly valid! ___ 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] Autoloading? (Making Queue.Queue easier to use)
Sokolov Yura wrote: > May be allow modules to define __getattr__ ? > > def __getattr__(thing): > try: > return __some_standart_way__(thing) > except AttributeError: > if thing=="Queue": >import sys >from Queue import Queue >setattr(sys.modules[__name__],"Queue",Queue) >return Queue > raise I proposed something like this in the RFE tracker a while ago, but no one commented on it. Reinhold -- Mail address is perfectly valid! ___ 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] Divorcing str and unicode (no more implicit conversions).
Martin Blais wrote:
> On 10/3/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
>> Martin Blais <[EMAIL PROTECTED]> writes:
>>
>> > How hard would that be to implement?
>>
>> import sys
>> reload(sys)
>> sys.setdefaultencoding('undefined')
>
> Hmmm any particular reason for the call to reload() here?
Yes. setdefaultencoding() is removed from sys by site.py. To get it
again you must reload sys.
Reinhold
--
Mail address is perfectly valid!
___
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] Definining properties - a use case for class decorators?
Michele Simionato wrote:
> As other explained, the syntax would not work for functions (and it is
> not intended to).
> A possible use case I had in mind is to define inlined modules to be
> used as bunches
> of attributes. For instance, I could define a module as
>
> module m():
> a = 1
> b = 2
>
> where 'module' would be the following function:
>
> def module(name, args, dic):
> mod = types.ModuleType(name, dic.get('__doc__'))
> for k in dic: setattr(mod, k, dic[k])
> return mod
Wow. This looks like an almighty tool. We can have modules, interfaces,
classes and properties all the like with this.
Guess a PEP would be nice.
Reinhold
___
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] a different kind of reduce...
Raymond Hettinger wrote: > [Martin Blais] >> > I'm always--literally every time-- looking for a more functional > form, >> > something that would be like this: >> > >> ># apply dirname() 3 times on its results, initializing with p >> >... = repapply(dirname, 3, p) > > [Greg Ewing] >> Maybe ** should be defined for functions so that you >> could do things like >> >>up3levels = dirname ** 3 > > Hmm, using the function's own namespace is an interesting idea. It > might also be a good place to put other functionals: > >results = f.map(data) >newf = f.partial(somearg) And we have solved the "map, filter and reduce are going away! Let's all weep together" problem with one strike! Reinhold -- Mail address is perfectly valid! ___ 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] something is wrong with test___all__
Hi, on my machine, "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. I can only suspect some AST bug here. Reinhold -- Mail address is perfectly valid! ___ 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] Python 3
Hi, don't know if this is known here, but it seems we have quite a long way to go: http://kuerzer.de/python3 Reinhold ___ 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] something is wrong with test___all__
Guido van Rossum wrote: > Has this been handled yet? If not, perhaps showing the good and bad > bytecode here would help trigger someone's brain into understanding > the problem. I've created a tracker item at www.python.org/sf/1370322. Reinhold -- Mail address is perfectly valid! ___ 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] PEP 8 updates/clarifications
Ian Bicking wrote: > Guido van Rossum wrote: >> On 12/14/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: >> >>>On Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote: >>> >>> The only thing I strongly disagree with is the promotion of javaNaming to equal footing with python_naming. >>> >>>Actually, they're not on equal footing atm. I happen to agree with you >>>though. >> >> >> It doesn't matter. Many large projects are adopting the camelCase >> convention, either by choice or by accident. I did a brief review of >> Zope 3 and Chandler, and while neither is consistent, camelCase >> prevails (Chandler also has a lot of CapWords method names, wihch >> suggests they didn't get this from Java -- maybe from C++?). > > Everything that touches wx seems to adopt CapWords method names -- in > part (hopefully) or in whole. Wx's API comes from Windows, and the > Microsoft method conventions. Bad, that. While the Windows API names once made sense when they referred to standalone functions, not methods, they now look ugly in wx or .NET. Reinhold -- Mail address is perfectly valid! ___ 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
