[Python-Dev] Re: Python 2.4 | 7.3 The for statement
It is easier if we see it beforehand: - leave = False alist = [1,2,3,3,4,5,6,7,8,9] for item in alist and not leave: if item is 1: leave = True Apart from other objections, this is valid Python now, and failing with 'TypeError: iteration over non-sequence'. self.introduce: This is not my first Python-dev message, but I never have introduced myself so far. So: I began my career as a programmer in 1990 working with C and Unify Accell/SQL, and continued with various RDBMS systems (Ingres, Oracle) creating commercial tailor-made applications (CRM and ERP, but before these terms were coined AFAIK). However, since 1986 (during school) I helped older friends (students) with C programs on Unix systems (met Unix before IBM compatible machines). And I won't mention Sinclair ZX Spectrum and Sinclair QL use as a kid :) Along programming, I worked as a sysadm for my companies' systems (and as a support sysadm for clients' systems, including SysV/68k, Ultrix, AIX, HP-UX, SCO, Irix, and various Linux distros since 2.4 kernel), so I have a thorough shell scripting background. I never liked Perl when I found out about it, so I continued my awk usage. I also had a very good knowledge of Access 97 at the time (loved the data engine, hated the program itself). Python I met in 2000 as a script to analyse LaBrea tarpit logs, and reading the code instantly clicked for me (it was very close to the language I always intended to write myself RSN :). It was love at first code viewing. I have since become a Python advocate. Personal computer-related interests include image processing (and cataloguing), database design, game solving, "interconnected" generic information storage and retrieval (attempts in which will be superseded soon --hopefully-- by Chandler... :) My current employment as part of the customer support team for SGI systems in EMEA territory leaves little time for Python (attempts at social life worsens things too), and often enough this lack of time makes my posts to comp.lang.python somewhat sloppy... Though I won't ever be a called a *bot, I surely hope I can contribute a little. Thanks for reading! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP to make file objects support non-blocking mode.
Donovan Baarda wrote: The fact that partial reads/writes are possible without non-blocking mode changes things a fair bit. Also, the lack of fnctl support in Windows needs to be taken into account too. ... [ snip ] ... The lack of support on win32 for non-blocking mode, combined with the reduced need for it, makes adding a "setblocking" method undesirable. I don't know what the best thing to do now is... I guess the readsome/writesome is probably best, but given that os.read/os.write is not that bad, perhaps it's best to just forget I even suggested this PEP :-) My EUR 0.01 is that we should aim at a higher level of abstraction. I really don't care Windows, Unix, Linux, WhateverOS provide me with a specific low level service. I care about the conceptual thing I'm trying to establish. Any abstraction that provides a means to express a solution more closely to that conceptual level is a winner. --eric ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Change 'env var BROWSER override' semantics in webbrowser.py
On Sun, Mar 20, 2005 at 11:40:27AM -0300, [EMAIL PROTECTED] wrote: > Perhaps you could focus in 728278. It addresses some of the issues you > have addressed in 754022, but it is not properly formatted. If you could > merge into your patch the result of "set(728278)-set(754022)", it would > be great. > > These two patches have the biggest number of changes, and most significant > ones. Naturally they are also the most conflicting. > > If these two are merged, then I believe *all* webbrowser.py related > patches could be addressed and closed quickly. I am working on them. I am going to consolidate these patches along with 954628 and 1166780 into one big patch. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [AST] A somewhat less trivial patch than the last one. . .
Nick Coghlan wrote: I've put a first cut at generator expressions for the AST branch on Sourceforge. It's enough to get test_grammar to pass, and tinkering at the interactive prompt appears to work. I'm going to be out of the country until late next week, so if the folks sprinting on the AST branch at PyCon want to incorporate this (or parts of it), please go ahead. I'll be interested in seeing the results of the sprint when I get back. With any luck, generator expressions and decorators will both be available in a clean checkout :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [AST] Procedure for AST Branch patches
Nick Coghlan wrote: > Brett C. wrote: > >> OK, thanks to John Ehresman here at PyCon sprint I got logistix's >> patch applied. Beyond a warning that a warning that decode_unicode() >> is never called and the parser module failing to compile under Windows >> everything should be fine for compiling the AST branch. > > > Under Linux (Suse 9.1), the parser module compiles with a couple of > warnings about implicit declaration of PyParser_SimpleParseString, but > the .so fails to load due to a missing symbol PyNode_Compile. > It's a known issue. I am just ignoring the failed compile. >> Passing the test suite, though, is another question. =) > > > Heh. I managed to get test_grammar to pass 100% last night, which is at > least a start! > Yeah, I am hoping to look at your generators patch before you get back in the country. > And I must say that the new system is rather nice to work with - it took > me a while to work out what was going on, but the multi-pass 'build > AST', 'build symbol table', 'compile AST' is much cleaner than it is > with the lists-of-lists arrangement on the trunk (which is the entire > point of the AST-branch, I guess. . .) > How the system works will be *much* clearer with the new version of Python/compile.txt, assuming everyone has not been lying to me about the clarity. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] docstring before function declaration
Oops, you're right. What I should have said is to use an empty docstring as follows: "" """Function docstring.""" def foo: ... or: """Module docstring.""" "" def foo: ... So the first docstring is the module docstring, and the next is the first class/function. And again, if there's only one, it will belong to both. --- Anthony Baxter <[EMAIL PROTECTED]> wrote: > On Monday 21 March 2005 20:08, Nicholas Jacobson > wrote: > > > How do you distinguish between a docstring at > the > > > top of a module > > > that's immediately followed by a function? Is > it > > > the module docstring > > > or the function docstring? > > > > It's both. The docstring would be assigned to > both > > the module and the function. This is a *good* > thing > > when there is a module with only one function in > it. > > i.e. there should only be one docstring for both, > and > > this saves repetition of that docstring. > > > > If a programmer wanted a docstring for the > function > > but not the module, a blank first line would do > the > > trick. A docstring for the module but not the > > function? Put a blank line between the module's > > docstring and the function. > > Yuk. This is magic taken to a ridiculous level. Note > that > "blank lines" currently have no meaning in Python, > and adding > a meaning to them is not my idea of a good thing. > > -- > Anthony Baxter <[EMAIL PROTECTED]> > It's never too late to have a happy childhood. > __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New PyPI broken package editing
I've uploaded a new package to the new PyPI. Editing this new packages gives me a unicode error. The URL is http://www.python.org/pypi?:action=submit_form&name=ll-ansistyle&version=0.6.1 The error I get is the following: --- Error... There's been a problem with your request exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 92: ordinal not in range(128) I've used the distutils from current CVS and have author=u"Walter Dörwald" in my setup.py Bye, Walter Dörwald ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New PyPI broken package editing
Zitat von Walter Dörwald <[EMAIL PROTECTED]>: > I've uploaded a new package to the new PyPI. Editing this > new packages gives me a unicode error. The URL is > > http://www.python.org/pypi?:action=submit_form&name=ll-ansistyle&version=0.6.1 I see that the package is online now, so I assume that it now worked? > I've used the distutils from current CVS and have > author=u"Walter Dörwald" > in my setup.py This isn't supposed to work yet. Are you using the register command on this? Can you tell where it decides to encode as Latin-1? PyPI will reject anything that is not UTF-8. As for the uploads: you'll have noticed that it put the sdist files into packages/2.5; this is not supposed to happen. If you delete the files, and reupload them with the current CVS, the files should go into /packages/source. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: python/dist/src/Lib/distutils/command upload.py, 1.3, 1.4
On Tue, 22 Mar 2005 12:32:46 -0800, [EMAIL PROTECTED] wrote: > Don't set the Python version for sdist uploads. Why not? I realize that version is more important for pre-compiled extension modules, but it applies even to a pure python package. Source code that uses @decoration won't work in python 1.5 Defaulting to the version used to create the package isn't perfect, and may sometimes be too conservative -- but as a default, is it really worse than nothing? -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New PyPI broken package editing
> Zitat von Walter Dörwald <[EMAIL PROTECTED]>:
>
>> I've uploaded a new package to the new PyPI. Editing this
>> new packages gives me a unicode error. The URL is
>>
>> http://www.python.org/pypi?:action=submit_form&name=ll-ansistyle&version=0.6.1
>
> I see that the package is online now, so I assume that
> it now worked?
Uploading worked, but editing the package afterwards fails.
>> I've used the distutils from current CVS and have
>> author=u"Walter Dörwald"
>> in my setup.py
>
> This isn't supposed to work yet. Are you using the
> register command on this? Can you tell where it decides
> to encode as Latin-1? PyPI will reject anything that is
> not UTF-8.
You might be right. I've tried with author=u"..." and
author=u"...".encode("utf-8"). The second version might have been the one
that worked.
> As for the uploads: you'll have noticed that it put the
> sdist files into packages/2.5; this is not supposed to
> happen. If you delete the files, and reupload them with
> the current CVS, the files should go into /packages/source.
OK, I'll try again tomorrow morning.
Bye,
Walter Dörwald
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Deprecating 2.2.1 old bugs
Going on with the old bugs checking, here are the results for 2.2.1. When I'll finish, this will be put in an informational PEP. When I verified the bug, I filled two fields: - Summary: the same subject as in SF - Group: the bug's group at verifying time. - Bug #: the bug number - Verified: is the date when I checked the bug. - Action: is what I did then. If the bug survived the verification, the next two fields are applicable (if not, I put a dash, the idea is to keep this info easily parseable): - Final: is the action took by someone who eliminated the bug from that category (closed, moved to Py2.4, etc). - By: is the someone who did the final action. So: Summary: segfault when running smtplib example Group:2.2.1 Bug #:1003195 Verified: 26-Dic-2004 Action: Deprecation alerted. I can not try it, don't have that context. Final:Closed: Won't fix. By: facundobatista Summary: sgmllib incorrectly handles entities in attributes Group:2.2.1 Bug #:779388 Verified: 26-Dic-2004 Action: Deprecation alerted. I can not try it, don't have that context. Final:Closed: Won't fix. By: facundobatista Summary: urlparse goes wrong with IP:port without scheme Group:2.2.1 Bug #:754016 Verified: 26-Dic-2004 Action: Changed to Group Py2.3: it seems a bug to me. Final:- By: - Summary: Failed assert in stringobject.c Group:2.2.1 Bug #:737947 Verified: 26-Dic-2004 Action: Closed: Fixed. The problem is solved, verified in Python 2.3.4. Final:- By: - Summary: A large block of commands after an "if" cannot be Group:2.2.1 Bug #:711268 Verified: 27-Dic-2004 Action: Changed to Group Py2.4: it seems a bug to me. Final:Re-classified as a Feature Request By: rhettinger Summary: urllib.url2pathname, pathname2url doc strings inconsistent Group:2.2.1 Bug #:649974 Verified: 26-Dic-2004 Action: Deprecation alerted. Can't discern if it's really a bug or not. Final:Changed the group to Python 2.4 By: mike_j_brown Summary: nturl2path.url2pathname() mishandles /// Group:2.2.1 Bug #:649961 Verified: 27-Dic-2004 Action: Deprecation alerted. Not sure if there's a bug, maybe in the documentation. Final:Closed: Won't fix. By: mike_j_brown Summary: print to unicode stream should __unicode Group:2.2.1 Bug #:637094 Verified: 01-Dec-2004 Action: Deprecation alerted. Can't discern if it's really a bug or not. Final:Re-classified as a Feature Request By: lemburg Summary: Unix popen does not return exit status Group:2.2.1 Bug #:608635 Verified: 26-Dic-2004 Action: Deprecation alerted. Don't know enough about the subject to be able to reproduce the issue. Final:Closed: Won't fix. By: facundobatista 608033: I can not try it, don't have that context. Summary: Implied __init__.py not copied Group:2.2.1 Bug #:608033 Verified: 01-Dic-2004 Action: Deprecation alerted. I can not try it, don't have that context. Final:Closed: Won't fix. By: facundobatista Summary: pydoc -g dumps core on Solaris 2.8 Group:2.2.1 Bug #:602627 Verified: 30-Nov-2004 Action: Deprecation alerted. I can not try it, don't have that context. Final:Closed: Won't fix. By: facundobatista Summary: makesetup fails: long Setup.local lines Group:2.2.1 Bug #:591287 Verified: 30-Nov-2004 Action: Deprecation alerted. I can not try it, don't have that context. Final:Closed: Won't fix. By: facundobatista Summary: os.tmpfile() can fail on win32 Group:2.2.1 Bug #:591104 Verified: 30-Nov-2004 Action: Deprecation alerted. Because a comment is not clear to me if the problem actually existed. Final:Closed: Won't fix. By: facundobatista Summary: pthread_exit missing in thread_pthread.h Group:2.2.1 Bug #:579116 Verified: 30-Nov-2004 Action: Deprecation alerted. I can not try it, don't have that context. Final:Closed: Won't fix. By: facundobatista Summary: cgi.py broken with xmlrpclib on Python 2 Group:2.2.1 Bug #:569316 Verified: 30-Nov-2004 Action: Deprecation alerted. Don't know enough about the subject to be able to reproduce the issue. Final:Closed: Won't fix. By: facundobatista Summary: Popen exectuion blocking w/threads Group:2.2.1 Bug #:566037 Verified: 29-Nov-2004 Action: Deprecation alerted. Can't discern if it's really a bug or not. Works in different context. Final:Closed: Won't fix. By: facundobatista Summary: fpectl build on solaris: -lsunmath Group:2.2.1 Bug #:530163 Verified: 29-Nov-2004 Action: Deprecation alerted. Can't discern if it's really a bug or not. I can not try it, don't have that context. Final:Closed: Won't fix. By: facundobatista Regards, .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://pyar.decode.com.ar/ ___ Python-Dev mailing list Python-Dev@pytho
Re: [Python-Dev] Re: python/dist/src/Lib/distutils/command upload.py, 1.3, 1.4
On Tuesday 22 March 2005 16:09, Jim Jewett wrote: > Why not? I realize that version is more important for pre-compiled > extension modules, but it applies even to a pure python package. > > Source code that uses @decoration won't work in python 1.5 This is distinct from the version of Python used to build a distribution. I've noted this as a metadata field that is needed, and plan to draft a PEP to include this and a few others. What I don't want is to conflate fields that should be separate, and end up with crufty data in PyPI. It's better to know that some data is missing than to be wrong about it. > Defaulting to the version used to create the package isn't perfect, > and may sometimes be too conservative -- but as a default, is it > really worse than nothing? Yes, because we can't tell the difference later. For now, you can include comments in the long description or on a project web page. A proper field will be added for this in the future (hopefully not too distant). -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: python/dist/src/Lib/distutils/command upload.py, 1.3, 1.4
On Tue, 22 Mar 2005 18:00:50 -0500, "Fred L. Drake, Jr." <[EMAIL PROTECTED]> wrote: > On Tuesday 22 March 2005 16:09, Jim Jewett wrote: > > Why not? I realize that version is more important for pre-compiled > > extension modules, but it applies even to a pure python package. > > Source code that uses @decoration won't work in python 1.5 > This is distinct from the version of Python used to build a distribution. In theory, yes. My suspicion is that if people are using the defaults, then they are probably also using a python version that they have tested with -- and perhaps the only one that they have tested with. > > Defaulting to the version used to create the package isn't perfect, > > and may sometimes be too conservative -- but as a default, is it > > really worse than nothing? > Yes, because we can't tell the difference later. For now, you can include > comments in the long description or on a project web page. A proper field > will be added for this in the future (hopefully not too distant). How about changing it to tack on a "(guess)" instead of just deleting it? Or does that change break too many other things/cause too much ugliness for the timeframe it will be used in? -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: python/dist/src/Lib/distutils/command upload.py, 1.3, 1.4
On Tuesday 22 March 2005 18:29, Jim Jewett wrote: > > This is distinct from the version of Python used to build a > > distribution. > > In theory, yes. > > My suspicion is that if people are using the defaults, then they are > probably also using a python version that they have tested with -- and > perhaps the only one that they have tested with. I think this varies substantially. I routinely test cross-version code with several versions of Python. > How about changing it to tack on a "(guess)" instead of just deleting it? But it's not a guess for non-source distributions. > Or does that change break too many other things/cause too much > ugliness for the timeframe it will be used in? Too much ugliness. Remember, this field is attached to the uploaded file, not the release as a whole. Many packages are going to see uploads for two or more versions of Python (PyXML for example). Getting the metadata wrong is just too evil. Now that more people have seen the code for PyPI (and understand more of it), it'll be easier to implement new fields once they've been carefully defined. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: python/dist/src/Lib/distutils/command upload.py, 1.3, 1.4
Zitat von Jim Jewett <[EMAIL PROTECTED]>: > How about changing it to tack on a "(guess)" instead of just deleting it? I think it would be confusing to users. Currently, the only version you would get into the database is 2.5, as earlier versions don't have the upload command. So we would have all sdist releases under packages/2.5, which would be too confusing, IMO. > Or does that change break too many other things/cause too much > ugliness for the timeframe it will be used in? It's also used to build the download link under python.org/packages. At the moment, changing the upload command would have no effect, since PyPI always puts sdist packages under packages/source, and clears the Python version if there is one. As Fred says, if a package has a minimum Python version, it should specify this - either in a new metadata field, or through an entry into Requires; PEP 314 somewhat suggests that you can do Depends: sys (>=2.3) Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] @decoration of classes
Good day, I just noticed that decoration of classes was not included with the @decoration syntax that made it into Python 2.4. While I understand that class decoration was not a part of PEP 318, I remember people were interested in decorating classes for all sorts of reasons, among them as a prefix notation for documenting (which seems to nearly satisfy Nicholas Jacobson) as well as a partial metaclass replacement. Is the fact that it didn't make it into 2.4 due to a pronouncement that I missed/forgot, lack of time, or was it merely forgotten? Thanks, - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] @decoration of classes
> I just noticed that decoration of classes was not included with the > @decoration syntax that made it into Python 2.4. While I understand > that class decoration was not a part of PEP 318, I remember people were > interested in decorating classes for all sorts of reasons, among them as > a prefix notation for documenting (which seems to nearly satisfy > Nicholas Jacobson) as well as a partial metaclass replacement. > > Is the fact that it didn't make it into 2.4 due to a pronouncement that > I missed/forgot, lack of time, or was it merely forgotten? I don't recall whether I pronounced or not, but it is my opinion that this isn't addressing nearly as big an issue for classes as it is for functions/methods; in particular, the main problem of having all the special handling *after* the body of the function doesn't occur for classes, where you can put all the special handling at the top of the body, perhaps aided by a crafty metaclass. It would take a lot of convincing before I would think that class @decorators are better than metaclasses. In any case the fact that it wasn't in the PEP was plenty of reason not to add it to 2.4. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] @decoration of classes
On Wednesday 23 March 2005 14:20, Guido van Rossum wrote: > It would take a lot of convincing before I would think that class > @decorators are better than metaclasses. > > In any case the fact that it wasn't in the PEP was plenty of reason > not to add it to 2.4. Minor clarification - it _was_ in the PEP, but when I did the big rewrite to match the state of the art, the class decoration stuff was ripped out. If it's thought worthwhile, someone could update the PEP to include Guido's message. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
