Re: [Python-Dev] Copyright notices in modules
Guido van Rossum wrote: 2009/1/20 Raymond Hettinger : I'm at a loss of why the notice needs to be there at all. There's a difference between contributing a whole file and contributing a patch. Patches do not require copyright notices. Whole files do. This is not affected by later edits to the file. In my comment, I postulated the situation where the patch consisted of merging in another, independently copyrighted, 'whole file'. Perhaps this has mostly been a non-existent situation and therefor moot. One real situation I was thinking of, unconnected to Google as far as I am aware, is the case of two third-party IP6 modules and the suggestion that they be merged into one stdlib module. If that were accomplished by committing one and merging the other in a patch, it would be unfair (and untrue) to have just one copyright notice. Of course, in this case, I hope the two authors work everything out between themselves first before any submission. I completely understand about strongly preferring programming to lawyer consultation ;-). tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3142: Add a "while" clause to generator expressions
Steven D'Aprano wrote: Another argument against the PEP was that it breaks the correspondence between the generator expression and the equivalent for-loop. I had never even noticed such correspondence before, because to my eyes the most important term is the yielded expression, not the scaffolding around it. This was a major reason to add comprehensions. Your not noticing a primary design principle is hardly a reason to abandon it. Indeed, I claim that your ignorance shows its validity ;-). > In a generator expression, we have: yielded-expr for-clause if-clause while the corresponding nested statements are: for-clause if-clause yielded-expr The three clauses are neither in the same order, nor are they in reverse order. They are in the same order but rotated, with the last brought around to the front to emphasize it. Did you really not notice that either? >I don't know how important that correspondence is to language implementers, but as a Python programmer, I'd gladly give up that correspondence (which I don't find that great) in order to simplify exiting a generator expression early. So I like the proposed change. I find it elegant and very Pythonic. +1 for me. Ironically, in a thread cross-posted on c.l.p and elsewhere, someone just labeled Python's comprehension syntax as "ad hoc syntax soup". That currently is completely wrong. It is a carefully designed 1 to 1 transformation between multiple nested statements and a single expression. But this proposal ignores and breaks that. Using 'while x' to mean 'if x: break' *is*, to me, 'ad hoc'. So I detest the proposed change. I find it ugly and anti-Pythonic. Terry Jan Reedy ___ 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] Copyright notices in modules
I would be all for cleaning up, if the lawyers agree, but I've spent enough time talking to lawyers for the rest of my life. You know where to reach Van Lindberg. On Tue, Jan 20, 2009 at 5:20 PM, Raymond Hettinger wrote: > > [Raymond Hettinger] >>> >>> I'm at a loss of why the notice needs to be there at all. > > [GvR] >> >> There's a difference between contributing a whole file and >> contributing a patch. Patches do not require copyright notices. Whole >> files do. This is not affected by later edits to the file. > > That makes sense. In general though, I think if a contributor isn't > required by their company to add a copyright, then this sort of thing > should be left out of the source code. Most of the contributors here > don't seem to copyright-up everything they do (with the exception > of big packages or externally maintained resources). > > If everyone making a significant contribution has a contributor agreement > on file, perhaps we can build a list of those in a single file rather than > scattering notices throughout the code. I don't see that those benefit > anyone (maintainers, the original contributor, or the contributor's > company). > > At least these notices are somewhat innocuous. The ones that were > the most irritating are the ones requiring a literal copy of the notice > to be placed in the docs. A while back, I spent a day getting us in > compliance with those. > > FWIW, I'm not picking on anyone. I would just like to see a practice > emerge where these stop getting added and perhaps start getting removed > unless they are actually necessary for some reason (i.e. a company requires > it). > > AFAICT, little notices like the one atop numbers.py don't confer property > rights to anyone. The original purpose of a copyright notice has been lost. > It has become useless boilerplate, a toothless warning sign about a > unclaimable > property claim on donated code. > > > Raymond > > > P.S. It seems silly that the copyright on PEP3141 says, "this document has > been placed in the public domain" but the code itself has a company > copyright. > The former seems like something someone would care more about as a > creative expression or original research. > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Copyright notices in modules
[Raymond Hettinger] I'm at a loss of why the notice needs to be there at all. [GvR] There's a difference between contributing a whole file and contributing a patch. Patches do not require copyright notices. Whole files do. This is not affected by later edits to the file. That makes sense. In general though, I think if a contributor isn't required by their company to add a copyright, then this sort of thing should be left out of the source code. Most of the contributors here don't seem to copyright-up everything they do (with the exception of big packages or externally maintained resources). If everyone making a significant contribution has a contributor agreement on file, perhaps we can build a list of those in a single file rather than scattering notices throughout the code. I don't see that those benefit anyone (maintainers, the original contributor, or the contributor's company). At least these notices are somewhat innocuous. The ones that were the most irritating are the ones requiring a literal copy of the notice to be placed in the docs. A while back, I spent a day getting us in compliance with those. FWIW, I'm not picking on anyone. I would just like to see a practice emerge where these stop getting added and perhaps start getting removed unless they are actually necessary for some reason (i.e. a company requires it). AFAICT, little notices like the one atop numbers.py don't confer property rights to anyone. The original purpose of a copyright notice has been lost. It has become useless boilerplate, a toothless warning sign about a unclaimable property claim on donated code. Raymond P.S. It seems silly that the copyright on PEP3141 says, "this document has been placed in the public domain" but the code itself has a company copyright. The former seems like something someone would care more about as a creative expression or original research. ___ 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] Copyright notices in modules
2009/1/20 Raymond Hettinger : > I'm at a loss of why the notice needs to be there at all. There's a difference between contributing a whole file and contributing a patch. Patches do not require copyright notices. Whole files do. This is not affected by later edits to the file. > AFAICT, we've > had tons of contributions from googlers and only one has put a Google > copyright notice in the source. I count 28 .py files with a Google copyright and 127 with other copyrights (not counting the 47 PSF copyrights :-). Why are you picking on Google? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
Luke Kenneth Casson Leighton wrote: this is a fairly important issue for python development interoperability - martin mentioned that releases of mingw-compiled python, if done with a non-interoperable version of msvcrt, would cause much mayhem. well, compiling python on mingw with msvcr80 _can_ be done; using it can also be a simple matter of creating a python.exe.manifest file, but i can't actually do any testing because it doesn't work under wine. so, pending any further advice and guidance from anyone which allows me to successfully proceed, i'm not going to continue to compile - or release - python2.5 *or* python2.6 builds (when i get round to that) using msvcr80 or msvcr9X. one issue in favour of this decision is that the DLL that's produced by the autoconf build process is "libpython2.5.dll.a" - not "python2.5.dll". it has a different name. it should be abundantly clear to users and developers that "if name equals libpython2.5.dll.a then duh build equals different". additionally, the setup.py distutils all goes swimmingly well and lovely - using libpython2.5.dll.a. the only issue which _is_ going to throw a spanner in the works is that people who download win32-built precompiled c-based modules are going to find that hey, "it don't work!" and the answer will have to be "go get a version of that module, compiled with mingw, not MSVC". of course - if python for win32 ENTIRELY DROPPED msvc as a development platform, and went for an entirely free software development toolchain, then this problem goes away. thoughts, anyone? As I understand the above, you listed or implied 3 paths other than you completely giving up, which you are not ready to do yet. 1. You release non-interoperable binary, with a modified name to alleviate, but not prevent confusion. 2. You get some sort of help from someone to release an interoperable binary. 3. The devs drop msvc (wink missing ;-). Not surprisingly to me, people on pydev followed herring #3 to explain why not. If you want responses to path 2, a post leaving out 3 and giving more detail might be more successful. All I could do is unzip stuff into a temp directory and run the test suite on my XP mechine. Terry Jan Reedy ___ 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] Copyright notices in modules
On Tue, Jan 20, 2009 at 5:36 PM, Raymond Hettinger wrote: > [Terry Reedy] >> >> Bottom line to me. The current notion of copyright does not work too well >> with evolving, loosely collective works (which eventually become >> 'folklore'). > > I'm at a loss of why the notice needs to be there at all. AFAICT, we've > had tons of contributions from googlers and only one has put a Google > copyright notice in the source. Oh? Grepping through the source shows no less than 30 copyright notices from Google. -- Regards, Benjamin ___ 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] Copyright notices in modules
[Terry Reedy] Bottom line to me. The current notion of copyright does not work too well with evolving, loosely collective works (which eventually become 'folklore'). I'm at a loss of why the notice needs to be there at all. AFAICT, we've had tons of contributions from googlers and only one has put a Google copyright notice in the source. Raymond ___ 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 3142: Add a "while" clause to generator expressions
Gerald Britton wrote: I wonder if this is a bug? It is a known glitch reported last summer. Devs decided not to fix because doing so would, in the patches tried, slow list comps significantly. Also, the documented intent and expected usage of StopIteration is this "exception StopIteration Raised by builtin next() and an iterator‘s __next__() method to signal that there are no further values." The second clause includes usage in the body of a generator function since that body becomes the __next__ method of the generator-iterator produced by calling the generator function. The meaning of any other usage, such as in the body of a standard function other than next(),(as in the example producing the glitch), is undefined and leads to undefined behavior, which could be different in other implementations and change in future implementations. Terry Jan Reedy ___ 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] Copyright notices in modules
On 2009-01-20 16:54, Stephen J. Turnbull wrote:
> M.-A. Lemburg writes:
> > On 2009-01-20 11:02, Michael Foord wrote:
>
> > > Mere collections of facts are not copyrightable as they are not
> > > creative (the basis of copyright)
>
> That's incorrect in the U.S.; what is copyrightable is an *original
> work of expression fixed in some medium*. "Original" is closely
> related to "creative", but it's not the same. The emphasis is on
> novelty, not on the intellectual power involved. So, for example, you
> can copyright a set of paint splashes on paper, as long as they're
> *new* paint splashes.
>
> The real issue here, however, is "expression". What's important is
> whether there are different ways to say it. So you can indeed
> copyright the phone book or a dictionary, which *does* protect such
> things as unusual use of typefaces or color to aid understanding.
> What you can't do is prevent someone from publishing another phone
> book or dictionary based on the same facts, and since "put it in
> alphabetical order" hasn't been an original form of expression since
> Aristotle or so, they can alphabetize their phone book or dictionary,
> and it is going to look a lot like yours.
The above argument is what makes copyright so complicated. Computer
software has been given the same status as a piece of literary work,
so all conventions for such works apply.
However, this doesn't necessarily mean that all computer software
is copyrightable per-se. The key problem is defining the threshold of
originality needed for a work to become copyrightable at all and
that's where different jurisdictions use different definitions or
guidelines based on case law.
http://en.wikipedia.org/wiki/Threshold_of_originality
E.g. in Germany it is common not to grant copyright on logos that
are used as trademarks. OTOH, use of a logo in the trademark
sense automatically makes it a trademark (even without registration).
> On the other hand, ABCs are not a "mere collection of facts". They are
> subject to various forms of organization (top down, bottom up,
> alphabetical order, etc), and that organization will in general be
> copyrightable. Also, unless your ABCs are all independent of each
> other, you will be making choices about when to derive and when to
> define from scratch. That aspect of organization is expressive, and
> once written down ("fixed in a medium") it is copyrightable.
>
> > > I recommend his book by the way - I'm about half way through so far and
> > > it is highly readable
>
> Larry Rosen's book is also good.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jan 20 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
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] Copyright notices in modules
M.-A. Lemburg wrote: On 2009-01-20 00:56, Raymond Hettinger wrote: Why does numbers.py say: # Copyright 2007 Google, Inc. All Rights Reserved. # Licensed to PSF under a Contributor Agreement. Because that's where that file originated, I guess. This is part of what you have to do for things that are licensed to the PSF under a contributor agreement: http://www.python.org/psf/contrib/contrib-form/ """ Contributor shall identify each Contribution by placing the following notice in its source code adjacent to Contributor's valid copyright notice: "Licensed to PSF under a Contributor Agreement." """ Weren't there multiple contributors including non-google people? The initial contribution was done by Google (Jeffrey Yasskin AFAIK) and that's where the above lines originated from. Thank you for the explanation, here and below, as far as it goes. But what about the copyrightable and therefore copywrited contributions of others? Does Google (in this case) get an automatic transfer of copyright to Google? A single copyright notice seems to imply that. In the case of minor edits of the original work, perhaps yes. When, for instance, I send an author notice of a typo or a suggested rephasing of a sentence, I consider that a donation to the author. In the case of new work, added to the file by PSF so that the file become a compilation or anthology of the work of several people, I should think not. If there is any copyright notice, then perhaps there should be several -- one for each 'major' (new section) contributor and one for the PSF for the compilation. I have occasional seen such things in printed works. Does Google want to be associated with code that was submitted with no tests? Only Google can comment on this. Do we want this sort of stuff in the code? Yes, it is required by the contrib forms. Then it seems to me that there should/could be a notice for each major contributor of independent and separately copyrightable sections. If someone signs a contributor agreement, can we forgo the external copyright comments? No. See above. Only the copyright owner can remove such notices. Do we want to make a practice of every contributor commenting in the name of the company they were working for at the time (if so, I would have to add the comment to a lot of modules)? That depends on the contract a contributor has with the company that funded the work. It's quite common for such contracts to include a clause stating that all IP generated during work time is owned by the employer. Does the copyright concept even apply to an abstract base class (I thought APIs were not subject to copyright, just like database layouts and language definitions)? It applies to the written program text. You are probably thinking about other IP rights such as patents or designs. Bottom line to me. The current notion of copyright does not work too well with evolving, loosely collective works (which eventually become 'folklore'). Terry Jan Reedy ___ 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 3142: Add a "while" clause to generator expressions
On Wed, 21 Jan 2009 03:56:06 am Antoine Pitrou wrote: > Alexey G. Shpagin udmvt.ru> writes: > > Example will look like > > g = (n for n in range(100) if n*n < 50 or else_break()) > > Please don't suggest any hack involving raising StopIteration as part > of a conditional statement in a generator expression. It might work > today, but it might as well break tomorrow as it's only a side-effect > of the implementation, not an official property of the language. If that's the case, then that is a point in favour of the PEP. Personally, I find the proposed syntax change very readable and intuitive. Some have argued that it makes Python harder to learn because it adds one more thing to learn, but that's a trivial objection. It's an extension to the existing syntax, but an obvious one. The difficulty in becoming proficient in a language is not learning the syntax, but in becoming experienced with the libraries, and on that regard the PEP is a win because it simplifies the itertools module by removing takewhile (which unfortunately I find neither readable or intuitive). Another argument against the PEP was that it breaks the correspondence between the generator expression and the equivalent for-loop. I had never even noticed such correspondence before, because to my eyes the most important term is the yielded expression, not the scaffolding around it. In a generator expression, we have: yielded-expr for-clause if-clause while the corresponding nested statements are: for-clause if-clause yielded-expr The three clauses are neither in the same order, nor are they in reverse order. I don't know how important that correspondence is to language implementers, but as a Python programmer, I'd gladly give up that correspondence (which I don't find that great) in order to simplify exiting a generator expression early. So I like the proposed change. I find it elegant and very Pythonic. +1 for me. -- Steven D'Aprano ___ 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] Strategies for debugging buildbot failures?
Thanks for all the feedback. [Michael Foord] > At Resolver Systems we regularly extend the test framework purely > to provide more diagnostic information in the event of test failures. > We do a lot of functional testing through the UI, which is particularly > prone to intermittent and hard to diagnose failures. Seems like a sound approach in general. It seems awkward to apply the method to this particular failure, though. I guess one would need extra code in regrtest.py to catch the invalid signal, for a start. [Martin v. Löwis] > Buildbot also supports submission of patches directly to the > slaves. This is currently not activated, and clearly requires > some authentication/authorization; if you want to use that, > I'd be happy to experiment with setting it up, though. > [...] > In the past, for the really difficult problems, we arranged to > have the developers get access to the buildbot slaves. Thanks, Martin. I think I've pretty much run out of time to pursue this particular problem for the moment; I may return to it later. It's good to know that these options are available, though. Mark ___ 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] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
>> That's a non-starter for anyone who incorporates Python in an existing >> MSVC-based development environment. > > surely incorporating libpython2.5.dll.a or libpython2.6.dll.a, along > with the .def and the importlib that's generated with dlldump, unless > i'm missing something, would be a simple matter, yes? Not exactly sure what this is, but I believe Python *already* includes such a thing. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
Luke Kenneth Casson Leighton wrote: > i'd say "great" - but given a choice of "impressive profile guided > optimisation plus a proprietary compiler, proprietary operating system > _and_ being forced to purchase a system _capable_ of running said > proprietary compiler, said proprietary operating system, _and_ giving > up free software principles _and_ having to go through patch-pain, > install-pain _and_ being forced to use a GUI-based IDE for > compilation" or "free software tools and downloads the use of which > means i am beholden to NOONE", it's a simple choice for me to make - > maybe not for other people. It only becomes a problem when someone wants to both support Windows users of their extension modules with pre-built binaries, but *also* doesn't want to set up the appropriate environment for building such binaries (currently a minimum bar of Visual Studio Express on a Windows VM instance). The most common reaction I've seen to this problem from package developers is "I don't run Windows, so if users want pre-built binaries, someone with a Windows environment is going to have to volunteer to provide them". And that seems like a perfectly reasonable way to handle the situation to me. On POSIX systems, GCC does a great job, on Windows, MSVC is better (from a performance point of view). The closed source vs open source, free vs non-free philosophical arguments don't really play a significant part in the decision. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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 3142: Add a "while" clause to generator expressions
Gerald Britton wrote: > I wonder if this is a bug? Nope, it's part of the defined behaviour. Avoiding the overhead of the GE machinery is actually the main advantage in using a comprehension over the equivalent generator expression. Deliberately raising StopIteration is about the only way to notice the small semantics difference (in Py3k anyway - in 2.x there are scoping differences as well). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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 3142: Add a "while" clause to generator expressions
Antoine Pitrou wrote: > Alexey G. Shpagin udmvt.ru> writes: >> Example will look like >> g = (n for n in range(100) if n*n < 50 or else_break()) > > Please don't suggest any hack involving raising StopIteration as part of a > conditional statement in a generator expression. It might work today, but it > might as well break tomorrow as it's only a side-effect of the implementation, > not an official property of the language. As RDM noted, it actually is documented behaviour due to the equivalence between generator expressions and the corresponding generator functions. Writing a separate generator function is typically going to be cleaner and more readable though. Cheers, Nick. P.S. Here's another cute hack for terminating an iterator early: >>> list(iter((n for n in range(10)).next, 5)) [0, 1, 2, 3, 4] (it's nowhere near as flexible as itertools.takewhile, of course) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] __del__ and tp_dealloc in the IO lib
On Sun, Jan 18, 2009 at 11:49 PM, Adam Olsen wrote: > On Sun, Jan 18, 2009 at 9:32 PM, Guido van Rossum wrote: >> On Sun, Jan 18, 2009 at 5:38 PM, Gregory P. Smith wrote: >>> +1 on getting rid of the IOBase __del__ in the C rewrite in favor of >>> tp_dealloc. >>> >>> On Sun, Jan 18, 2009 at 11:53 PM, Christian Heimes wrote: Brett Cannon schrieb: > Fine by me. People should be using the context manager for guaranteed > file closure anyway IMO. >>> >>> Yes they should. (how I really really wish i didn't have to use 2.4 anymore >>> ;) >> >> Come on, the open-try-use-finally-close idiom isn't *that* bad... >> >>> But lets at least be clear that is never acceptable for a python >>> implementation to leak file descriptors/handles (or other system resources), >>> they should be closed and released whenever the particular GC implementation >>> gets around to it. >> >> I would like to make a stronger promise. I think that for files open >> for *writing*, all data written to the file should be flushed to disk >> before the fd is closed. This is the real reason for having the >> __del__: closing the fd is done by the C implementation of FileIO, but >> since (until the rewrite in C) the buffer management is all in Python >> (both the binary I/O buffer and the additional text I/O buffer), I >> felt the downside of having a __del__ method was preferable over the >> possibility of output files not being flushed (which is always >> nightmarish to debug). >> >> Of course, once both layers of buffering are implemented in C, the >> need for __del__ to do this goes away, and I would be fine with doing >> it all in tp_alloc. >> You make a very good point! Perhaps we should stop promising that files get closed as soon as possible and encourage people in using the with statement. Christian >>> >>> eegads, do we actually -promise- that somewhere? If so I'll happily go >>> update those docs with a caveat. >> >> I don't think we've promised that ever since the days when JPython >> (with a P!) was young... >> >>> I regularly point out in code reviews that the very convenient and common >>> idiom of open(name, 'w').write(data) doesn't guarantee when the file will be >>> closed; its up to the GC implementation details. Good code should never >>> depend on the GC for a timely release of scarce external resources (file >>> descriptors/handles). >> >> And buffer flushing. While I don't want to guarantee that the buffer >> is flushed ASAP, I do want to continue promising that it is flushed >> before the object is GC'ed and before the fd is closed. > > Could we add a warning if the file has not been explicitly flushed? > Consider removing the implicit flush later, if there's a sufficient > implementation benefit to it. No, I really want to keep the implicit flush, even if it's hard for the implementation. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3142: Add a "while" clause to generator expressions
On Tue, 20 Jan 2009 at 16:56, Antoine Pitrou wrote: Alexey G. Shpagin udmvt.ru> writes: Example will look like g = (n for n in range(100) if n*n < 50 or else_break()) Please don't suggest any hack involving raising StopIteration as part of a conditional statement in a generator expression. It might work today, but it might as well break tomorrow as it's only a side-effect of the implementation, not an official property of the language. Doing the above is, by definition, no different from raising StopIteration in a for loop inside a generator function. The language reference does document the raising of a StopIteration as signaling the exhaustion of the generator. In addition, the 3.0 docs (but, oddly, not the 2.6 docs) say in the 'for' loop documentation: "When the items are exhausted (which is immediately when the list is empty or an iterator raises a StopIteration exception)"). The difference in behavior between raising StopIteration in a list comprehension versus a generator expression are consistent with the above, by the way. If you raise StopIteration in a function whose definition is the same as the list comprehension but you are building the list as you go and only returning it when it is complete, then the StopIteration would propagate upward with no values returned (ie: in a for loop it would look like an empty list). I don't know about other people, but I have certainly assumed that raising StopIteration was a legitimate way to terminate an iterator, and have written code accordingly. If this is not true, it should probably be explicitly documented in the language reference somewhere. --RDM ___ 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 3142: Add a "while" clause to generator expressions
On Tue, Jan 20, 2009 at 12:46 PM, Gerald Britton wrote: > I wonder if this is a bug? I don't think so, but its interesting nonetheless. passing a generator expression to list() involves two loops: the list construction and the generator expression. So, a StopIteration from whatever the GE is iterating over is caught by the GE mechanics, and anything else in the clauses can be caught by the list constructor. If the same thing is done in a LC, such an exception from the clause has nothing to catch it. It is not raised as part of iterating over something. I don't think we'd want to just start swallowing errors here, as it would change defined behavior. > On Tue, Jan 20, 2009 at 11:32 AM, Vitor Bosshard wrote: >> - Mensaje original >>> De: "python-3...@udmvt.ru" >>> Para: Gerald Britton >>> CC: python-dev@python.org >>> Enviado: martes, 20 de enero, 2009 11:18:24 >>> Asunto: Re: [Python-Dev] PEP 3142: Add a "while" clause to generator >>> expressions >>> >>> May I suggest you this variant? >>> >>> def raiseStopIteration(): >>> raise StopIteration >>> >>> g = (n for n in range(100) if n*n < 50 or raiseStopIteration()) >>> >>> Well, there are more characters... >>> >>> But it is not using any syntax changes and does not require any approval >>> to be functional. Yet it is as fast as the proposed variant, does not >>> require >>> modules and, I hope, will not confuse you or anyone else. >>> >> >> This works as a generator, but not as a list comprehension. The exception is >> propagated instead of just cutting short the loop: >> > def r(): raise StopIteration > print [i for i in range(10) if i**2 < 50 or r()] >> Traceback (most recent call last): >> File "", line 1, in >> print [i for i in range(10) if i**2 < 50 or r()] >> File "", line 1, in r >> def r(): raise StopIteration >> StopIteration > >> >> >> Vitor >> >> >> ¡Todo sobre la Liga Mexicana de fútbol! Estadisticas, resultados, >> calendario, fotos y más:< >> http://espanol.sports.yahoo.com/ >> > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ironfroggy%40gmail.com > -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy ___ 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 3142: Add a "while" clause to generator expressions
I wonder if this is a bug? On Tue, Jan 20, 2009 at 11:32 AM, Vitor Bosshard wrote: > - Mensaje original >> De: "python-3...@udmvt.ru" >> Para: Gerald Britton >> CC: python-dev@python.org >> Enviado: martes, 20 de enero, 2009 11:18:24 >> Asunto: Re: [Python-Dev] PEP 3142: Add a "while" clause to generator >> expressions >> >> May I suggest you this variant? >> >> def raiseStopIteration(): >> raise StopIteration >> >> g = (n for n in range(100) if n*n < 50 or raiseStopIteration()) >> >> Well, there are more characters... >> >> But it is not using any syntax changes and does not require any approval >> to be functional. Yet it is as fast as the proposed variant, does not require >> modules and, I hope, will not confuse you or anyone else. >> > > This works as a generator, but not as a list comprehension. The exception is > propagated instead of just cutting short the loop: > def r(): raise StopIteration print [i for i in range(10) if i**2 < 50 or r()] > Traceback (most recent call last): > File "", line 1, in > print [i for i in range(10) if i**2 < 50 or r()] > File "", line 1, in r > def r(): raise StopIteration > StopIteration > > > Vitor > > > ¡Todo sobre la Liga Mexicana de fútbol! Estadisticas, resultados, > calendario, fotos y más:< > http://espanol.sports.yahoo.com/ > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3142: Add a "while" clause to generator expressions
On Tue, Jan 20, 2009 at 12:00 PM, Vitor Bosshard wrote: > > > - Mensaje original >> De: Gerald Britton >> Para: Vitor Bosshard >> CC: python-3...@udmvt.ru; python-dev@python.org >> Enviado: martes, 20 de enero, 2009 13:40:07 >> Asunto: Re: [Python-Dev] PEP 3142: Add a "while" clause to generator >> expressions >> >> Right, but the PEP is only about generator expressions. >> > > Yes, but consistency with list comprehensions would be a nice thing to have, > which is absent from both the "or raise()" idiom and the takewhile one (which > is, by definition, a generator). The new syntax wouldn't have this issue. > > I'm not in favor of the change, just pointing this out. I saw this to, and do want to throw in my two cents that it should be consistent between them. We should not add something to one and not the other. If the PEP, even if its rejected, doesn't change to reflect that its suggestion is for both generator expressions and list comprehensions, I think it should be considered invalid from the start. We should never add syntax that makes list(<...>) != [<...>] (where <...> is my stupid expression placeholder). > Vitor > > > ¡Todo sobre la Liga Mexicana de fútbol! Estadisticas, resultados, > calendario, fotos y más:< > http://espanol.sports.yahoo.com/ > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ironfroggy%40gmail.com > -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy ___ 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 3142: Add a "while" clause to generator expressions
- Mensaje original > De: Gerald Britton > Para: Vitor Bosshard > CC: python-3...@udmvt.ru; python-dev@python.org > Enviado: martes, 20 de enero, 2009 13:40:07 > Asunto: Re: [Python-Dev] PEP 3142: Add a "while" clause to generator > expressions > > Right, but the PEP is only about generator expressions. > Yes, but consistency with list comprehensions would be a nice thing to have, which is absent from both the "or raise()" idiom and the takewhile one (which is, by definition, a generator). The new syntax wouldn't have this issue. I'm not in favor of the change, just pointing this out. Vitor ¡Todo sobre la Liga Mexicana de fútbol! Estadisticas, resultados, calendario, fotos y más:< http://espanol.sports.yahoo.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3142: Add a "while" clause to generator expressions
Alexey G. Shpagin udmvt.ru> writes: > > Example will look like > g = (n for n in range(100) if n*n < 50 or else_break()) Please don't suggest any hack involving raising StopIteration as part of a conditional statement in a generator expression. It might work today, but it might as well break tomorrow as it's only a side-effect of the implementation, not an official property of the language. Regards Antoine. ___ 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] Copyright notices in modules
Stephen J. Turnbull wrote:
M.-A. Lemburg writes:
> On 2009-01-20 11:02, Michael Foord wrote:
> > Mere collections of facts are not copyrightable as they are not
> > creative (the basis of copyright)
That's incorrect in the U.S.; what is copyrightable is an *original
work of expression fixed in some medium*. "Original" is closely
related to "creative", but it's not the same. The emphasis is on
novelty, not on the intellectual power involved. So, for example, you
can copyright a set of paint splashes on paper, as long as they're
*new* paint splashes.
No but expression is more strongly related to creative.
The real issue here, however, is "expression". What's important is
whether there are different ways to say it. So you can indeed
copyright the phone book or a dictionary, which *does* protect such
things as unusual use of typefaces or color to aid understanding.
What you can't do is prevent someone from publishing another phone
book or dictionary based on the same facts, and since "put it in
alphabetical order" hasn't been an original form of expression since
Aristotle or so, they can alphabetize their phone book or dictionary,
and it is going to look a lot like yours.
On the other hand, ABCs are not a "mere collection of facts". They are
subject to various forms of organization (top down, bottom up,
alphabetical order, etc), and that organization will in general be
copyrightable. Also, unless your ABCs are all independent of each
other, you will be making choices about when to derive and when to
define from scratch. That aspect of organization is expressive, and
once written down ("fixed in a medium") it is copyrightable.
As you say - mere ordering does not render something copyrightable.
Phone books and maps deliberately insert fictitious data in order to be
eligible for copyright under these terms.
On the other hand I'm inclined to believe that there is enough original
expression in the ABCs to be copyrightable. It's a basically irrelevant
point though. :-)
Michael
> > I recommend his book by the way - I'm about half way through so far and
> > it is highly readable
Larry Rosen's book is also good.
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
___
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 3142: Add a "while" clause to generator expressions
Right, but the PEP is only about generator expressions. On Tue, Jan 20, 2009 at 11:32 AM, Vitor Bosshard wrote: > - Mensaje original >> De: "python-3...@udmvt.ru" >> Para: Gerald Britton >> CC: python-dev@python.org >> Enviado: martes, 20 de enero, 2009 11:18:24 >> Asunto: Re: [Python-Dev] PEP 3142: Add a "while" clause to generator >> expressions >> >> May I suggest you this variant? >> >> def raiseStopIteration(): >> raise StopIteration >> >> g = (n for n in range(100) if n*n < 50 or raiseStopIteration()) >> >> Well, there are more characters... >> >> But it is not using any syntax changes and does not require any approval >> to be functional. Yet it is as fast as the proposed variant, does not require >> modules and, I hope, will not confuse you or anyone else. >> > > This works as a generator, but not as a list comprehension. The exception is > propagated instead of just cutting short the loop: > def r(): raise StopIteration print [i for i in range(10) if i**2 < 50 or r()] > Traceback (most recent call last): > File "", line 1, in > print [i for i in range(10) if i**2 < 50 or r()] > File "", line 1, in r > def r(): raise StopIteration > StopIteration > > > Vitor > > > ¡Todo sobre la Liga Mexicana de fútbol! Estadisticas, resultados, > calendario, fotos y más:< > http://espanol.sports.yahoo.com/ > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3142: Add a "while" clause to generator expressions
- Mensaje original > De: "python-3...@udmvt.ru" > Para: Gerald Britton > CC: python-dev@python.org > Enviado: martes, 20 de enero, 2009 11:18:24 > Asunto: Re: [Python-Dev] PEP 3142: Add a "while" clause to generator > expressions > > May I suggest you this variant? > > def raiseStopIteration(): > raise StopIteration > > g = (n for n in range(100) if n*n < 50 or raiseStopIteration()) > > Well, there are more characters... > > But it is not using any syntax changes and does not require any approval > to be functional. Yet it is as fast as the proposed variant, does not require > modules and, I hope, will not confuse you or anyone else. > This works as a generator, but not as a list comprehension. The exception is propagated instead of just cutting short the loop: >>> def r(): raise StopIteration >>> print [i for i in range(10) if i**2 < 50 or r()] Traceback (most recent call last): File "", line 1, in print [i for i in range(10) if i**2 < 50 or r()] File "", line 1, in r def r(): raise StopIteration StopIteration >>> Vitor ¡Todo sobre la Liga Mexicana de fútbol! Estadisticas, resultados, calendario, fotos y más:< http://espanol.sports.yahoo.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3142: Add a "while" clause to generator expressions
On 1/20/2009 4:45 PM, Gerald Britton wrote: OK, so your suggestion: g = (n for n in range(100) if n*n < 50 or raiseStopIteration()) really means "return in in the range 0-99 if n-squared is less than 50 or the function raiseStopIteration() returns True". How would this get the generator to stop once n*n >=50? It looks instead like the first time around, StopIteration will be raised and (presumably) the generator will terminate. I still find it odd to invent new syntax for simple things like def quit(): raise StopIteration gen = itertools.imap( lambda x: x if x <= 50 else quit(), (i for i in range(100)) ) for i in gen: print i Sturla Molden ___ 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 3142: Add a "while" clause to generator expressions
Yup, I tried your idea and it does work as I intended. It looks a little better than using takewhile, but not (to me anyway) as nice as my original suggestion. Still, if my idea is ultimately rejected (looks that way at the moment), this is a good alternative. On Tue, Jan 20, 2009 at 10:57 AM, Alexey G. Shpagin wrote: > On Tue, Jan 20, 2009 at 10:45:27AM -0500, Gerald Britton wrote: >> OK, so your suggestion: >> >> g = (n for n in range(100) if n*n < 50 or raiseStopIteration()) >> >> really means "return in in the range 0-99 if n-squared is less than 50 >> or the function raiseStopIteration() returns True". >> >> How would this get the generator to stop once n*n >=50? It looks >> instead like the first time around, StopIteration will be raised and >> (presumably) the generator will terminate. > > Just test it. After the generator is terminated, no one will call > range(100).next() > method, if I really understand you. > > Maybe (as suggested before with 'if ... else break`) we should rename > function raiseStopIteration() to else_break(), > since it looks to me being a 'if ... else break's implementation with > functions. > > Example will look like > g = (n for n in range(100) if n*n < 50 or else_break()) > > That's to the matter of taste, I think. > > -- > Alexey G. Shpagin > ___ 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 3142: Add a "while" clause to generator expressions
On Tue, Jan 20, 2009 at 10:45:27AM -0500, Gerald Britton wrote: > OK, so your suggestion: > > g = (n for n in range(100) if n*n < 50 or raiseStopIteration()) > > really means "return in in the range 0-99 if n-squared is less than 50 > or the function raiseStopIteration() returns True". > > How would this get the generator to stop once n*n >=50? It looks > instead like the first time around, StopIteration will be raised and > (presumably) the generator will terminate. Just test it. After the generator is terminated, no one will call range(100).next() method, if I really understand you. Maybe (as suggested before with 'if ... else break`) we should rename function raiseStopIteration() to else_break(), since it looks to me being a 'if ... else break's implementation with functions. Example will look like g = (n for n in range(100) if n*n < 50 or else_break()) That's to the matter of taste, I think. -- Alexey G. Shpagin ___ 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] Copyright notices in modules
M.-A. Lemburg writes:
> On 2009-01-20 11:02, Michael Foord wrote:
> > Mere collections of facts are not copyrightable as they are not
> > creative (the basis of copyright)
That's incorrect in the U.S.; what is copyrightable is an *original
work of expression fixed in some medium*. "Original" is closely
related to "creative", but it's not the same. The emphasis is on
novelty, not on the intellectual power involved. So, for example, you
can copyright a set of paint splashes on paper, as long as they're
*new* paint splashes.
The real issue here, however, is "expression". What's important is
whether there are different ways to say it. So you can indeed
copyright the phone book or a dictionary, which *does* protect such
things as unusual use of typefaces or color to aid understanding.
What you can't do is prevent someone from publishing another phone
book or dictionary based on the same facts, and since "put it in
alphabetical order" hasn't been an original form of expression since
Aristotle or so, they can alphabetize their phone book or dictionary,
and it is going to look a lot like yours.
On the other hand, ABCs are not a "mere collection of facts". They are
subject to various forms of organization (top down, bottom up,
alphabetical order, etc), and that organization will in general be
copyrightable. Also, unless your ABCs are all independent of each
other, you will be making choices about when to derive and when to
define from scratch. That aspect of organization is expressive, and
once written down ("fixed in a medium") it is copyrightable.
> > I recommend his book by the way - I'm about half way through so far and
> > it is highly readable
Larry Rosen's book is also good.
___
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 3142: Add a "while" clause to generator expressions
OK, so your suggestion: g = (n for n in range(100) if n*n < 50 or raiseStopIteration()) really means "return in in the range 0-99 if n-squared is less than 50 or the function raiseStopIteration() returns True". How would this get the generator to stop once n*n >=50? It looks instead like the first time around, StopIteration will be raised and (presumably) the generator will terminate. On Tue, Jan 20, 2009 at 10:38 AM, Alexey G. Shpagin wrote: > On Tue, Jan 20, 2009 at 09:24:32AM -0500, Gerald Britton wrote: >> hmmm...doesn't: >> >> if n*n < 50 or raise StopIteration() >> >> really mean, "Return an integer in the range 0-99 if n-squared is less >> than fifty or the statement 'raise StopIteration()' returns True" ? >> >> I'm not sure that that will work. > Well, your variant will trigger syntax error (and will not work surely). > > To make it work we need a function, that raises StopIteration. > exactly as I have suggested. > >> >> On Tue, Jan 20, 2009 at 9:18 AM, wrote: >> > On Mon, Jan 19, 2009 at 10:10:00AM -0500, Gerald Britton wrote: >> >> Please find below PEP 3142: Add a "while" clause to generator >> >> expressions. I'm looking for feedback and discussion. >> >> >> > ... >> >> g = (n for n in range(100) while n*n < 50) >> > >> > May I suggest you this variant? >> > > >> >def raiseStopIteration(): >> >raise StopIteration >> > >> >g = (n for n in range(100) if n*n < 50 or raiseStopIteration()) > > -- > Alexey G. Shpagin > ___ 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] Questions/comments on documentation formatting
On Tue, Jan 20, 2009 at 8:39 AM, Paul Moore wrote: > 2009/1/20 Benjamin Peterson : >> We might be opening a can of worms, though. Do we document everything >> that takes a dictionary argument with collections.Mapping or >> everything that takes a integer numbers.Rationale? What if multiple >> types are possible? > > No. Only document things as taking an ABC argument if they actually > *do* only take that ABC. > >def f(dct): >return dct['a'] > > does not require a collections.Mapping argument, just something that > implements indexing-by-strings. Even with ABCs available, I thought > that duck typing was still expected to be the norm. That's exactly why I don't think ABCs would do much good. There are almost no functions which absolutely require a certain interface. So use of annotations would be rare. > > If a function does a type-test for an ABC, it makes sense to document > it as requiring that ABC (to flag to users that they may need to > register their own types with the ABC), Otherwise, it does not. > > Paul. > -- Regards, Benjamin ___ 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 3142: Add a "while" clause to generator expressions
On Tue, Jan 20, 2009 at 09:24:32AM -0500, Gerald Britton wrote: > hmmm...doesn't: > > if n*n < 50 or raise StopIteration() > > really mean, "Return an integer in the range 0-99 if n-squared is less > than fifty or the statement 'raise StopIteration()' returns True" ? > > I'm not sure that that will work. Well, your variant will trigger syntax error (and will not work surely). To make it work we need a function, that raises StopIteration. exactly as I have suggested. > > On Tue, Jan 20, 2009 at 9:18 AM, wrote: > > On Mon, Jan 19, 2009 at 10:10:00AM -0500, Gerald Britton wrote: > >> Please find below PEP 3142: Add a "while" clause to generator > >> expressions. I'm looking for feedback and discussion. > >> > > ... > >> g = (n for n in range(100) while n*n < 50) > > > > May I suggest you this variant? > > > >def raiseStopIteration(): > >raise StopIteration > > > >g = (n for n in range(100) if n*n < 50 or raiseStopIteration()) -- Alexey G. Shpagin ___ 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] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
On Tue, Jan 20, 2009 at 6:18 AM, Luke Kenneth Casson Leighton wrote: > > yeah they said the same thing about "gas ovens", too. not the nazi > gas ovens, the phrase my mother used to say "if someone stuck their > head in a gas oven, would you do the same?". I don't know who is forcing you to use a platform that you hate so much, but I respectfully suggest that this person is not on any of these mailing lists. -- Curt Hagenlocher c...@hagenlocher.org ___ 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] Adapt test suite for other Python impls
Hi all, There is a pending patch issue at http://bugs.python.org/issue4242 which proposes to tag, in the CPython test suite, which tests are general language tests (the vast majority) and which ones are specific to CPython. The patch would add a couple of helpful functions to test_support.py (http://bugs.python.org/file12718/test-impl-details-2.diff). A bientot, Armin. ___ 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] bundlebuilder broken in 2.6
On 18 Jan, 2009, at 18:10, Barry Scott wrote: While the build should be fixed for 2.6+ (I'll send a patch), note that bundlebuilder is gone in 3.0. What is the replacement for bundlebuilder for 3.0? Lack of bundlebuilder becomes a serious porting problem for me. I deliver pysvn WOrkbench as a bundle to simplify installation by my users. py2app, which hasn't been ported to python 3.0 yet (AFAIK). Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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] Questions/comments on documentation formatting
2009/1/20 Benjamin Peterson : > We might be opening a can of worms, though. Do we document everything > that takes a dictionary argument with collections.Mapping or > everything that takes a integer numbers.Rationale? What if multiple > types are possible? No. Only document things as taking an ABC argument if they actually *do* only take that ABC. def f(dct): return dct['a'] does not require a collections.Mapping argument, just something that implements indexing-by-strings. Even with ABCs available, I thought that duck typing was still expected to be the norm. If a function does a type-test for an ABC, it makes sense to document it as requiring that ABC (to flag to users that they may need to register their own types with the ABC), Otherwise, it does not. Paul. ___ 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] Questions/comments on documentation formatting
On Mon, Jan 19, 2009 at 11:56 PM, Brett Cannon wrote: > On Mon, Jan 19, 2009 at 19:19, Benjamin Peterson wrote: >> On Mon, Jan 19, 2009 at 9:11 PM, Brett Cannon wrote: >>> On Mon, Jan 19, 2009 at 19:01, Benjamin Peterson >>> wrote: On Mon, Jan 19, 2009 at 8:24 PM, Brett Cannon wrote: > > 2. Should we start using function annotations? No, I think that information is better stored in the function description. >>> >>> Why? Putting it in the signature makes it very succinct and a simple >>> glance at the doc to see what type/ABC is expected. >> >> Well, I guess it's just not been explored. Feel free to try it out if >> you wish, though. >> > > I just might. We might be opening a can of worms, though. Do we document everything that takes a dictionary argument with collections.Mapping or everything that takes a integer numbers.Rationale? What if multiple types are possible? > 4. The var directive is not working even though the docs list it as a > valid directive; so is it still valid and something is broken, or the > docs need to be updated? The docs should be updated. "data" is the one to use now. >>> >>> So the 'data' directive turns into any variable, not just a module >>> variables? >> >> "data" is for module level objects. If you're documenting properties >> or attributes in classes, use "attribute". > > Then what are we supposed to use for arguments? Just ``literal``? No, use *some_argument*. -- Regards, Benjamin ___ 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 3142: Add a "while" clause to generator expressions
On Mon, Jan 19, 2009 at 10:10:00AM -0500, Gerald Britton wrote: > Please find below PEP 3142: Add a "while" clause to generator > expressions. I'm looking for feedback and discussion. > ... > g = (n for n in range(100) while n*n < 50) May I suggest you this variant? def raiseStopIteration(): raise StopIteration g = (n for n in range(100) if n*n < 50 or raiseStopIteration()) Well, there are more characters... But it is not using any syntax changes and does not require any approval to be functional. Yet it is as fast as the proposed variant, does not require modules and, I hope, will not confuse you or anyone else. -- Alexey G. Shpagin ___ 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 3142: Add a "while" clause to generator expressions
hmmm...doesn't: if n*n < 50 or raise StopIteration() really mean, "Return an integer in the range 0-99 if n-squared is less than fifty or the statement 'raise StopIteration()' returns True" ? I'm not sure that that will work. On Tue, Jan 20, 2009 at 9:18 AM, wrote: > On Mon, Jan 19, 2009 at 10:10:00AM -0500, Gerald Britton wrote: >> Please find below PEP 3142: Add a "while" clause to generator >> expressions. I'm looking for feedback and discussion. >> > ... >> g = (n for n in range(100) while n*n < 50) > > May I suggest you this variant? > >def raiseStopIteration(): >raise StopIteration > >g = (n for n in range(100) if n*n < 50 or raiseStopIteration()) > > Well, there are more characters... > > But it is not using any syntax changes and does not require any approval > to be functional. Yet it is as fast as the proposed variant, does not require > modules and, I hope, will not confuse you or anyone else. > > > -- > Alexey G. Shpagin > ___ 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] one last go at msvcr80 / msvcr90 assemblies - mingw build of python
could someone kindly send me the assembly files that are created by a proprietary win32 build of python2.5, 2.6 and trunk, the ones used to create the dll _and_ the python.exe many thanks. ___ 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] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
On Tue, Jan 20, 2009 at 1:11 PM, Tim Lesher wrote: > On Tue, Jan 20, 2009 at 08:02, Luke Kenneth Casson Leighton > wrote: >> of course - if python for win32 ENTIRELY DROPPED msvc as a development >> platform, and went for an entirely free software development >> toolchain, then this problem goes away. > > That's a non-starter for anyone who incorporates Python in an existing > MSVC-based development environment. surely incorporating libpython2.5.dll.a or libpython2.6.dll.a, along with the .def and the importlib that's generated with dlldump, unless i'm missing something, would be a simple matter, yes? > When in Rome... yeah they said the same thing about "gas ovens", too. not the nazi gas ovens, the phrase my mother used to say "if someone stuck their head in a gas oven, would you do the same?". > There would also be a significant performance cost. > The PGO (Profile Guided Optimisation) compilation of > Visual Studio is impressive. i'd say "great" - but given a choice of "impressive profile guided optimisation plus a proprietary compiler, proprietary operating system _and_ being forced to purchase a system _capable_ of running said proprietary compiler, said proprietary operating system, _and_ giving up free software principles _and_ having to go through patch-pain, install-pain _and_ being forced to use a GUI-based IDE for compilation" or "free software tools and downloads the use of which means i am beholden to NOONE", it's a simple choice for me to make - maybe not for other people. l. ___ 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] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
Luke Kenneth Casson Leighton schrieb: > of course - if python for win32 ENTIRELY DROPPED msvc as a development > platform, and went for an entirely free software development > toolchain, then this problem goes away. > > thoughts, anyone? That's not going to happen anytime soon. As long as Microsoft Visual Studio support is feasible, we will stick to VS. WINE support is not a top priority for us. Christian ___ 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] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
Tim Lesher wrote: On Tue, Jan 20, 2009 at 08:02, Luke Kenneth Casson Leighton wrote: of course - if python for win32 ENTIRELY DROPPED msvc as a development platform, and went for an entirely free software development toolchain, then this problem goes away. That's a non-starter for anyone who incorporates Python in an existing MSVC-based development environment. When in Rome... There would also be a significant performance cost. The PGO (Profile Guided Optimisation) compilation of Visual Studio is impressive. Michael -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
On Tue, Jan 20, 2009 at 08:02, Luke Kenneth Casson Leighton wrote: > of course - if python for win32 ENTIRELY DROPPED msvc as a development > platform, and went for an entirely free software development > toolchain, then this problem goes away. That's a non-starter for anyone who incorporates Python in an existing MSVC-based development environment. When in Rome... -- Tim Lesher ___ 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] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
folks, hi, this is a fairly important issue for python development interoperability - martin mentioned that releases of mingw-compiled python, if done with a non-interoperable version of msvcrt, would cause much mayhem. well, compiling python on mingw with msvcr80 _can_ be done; using it can also be a simple matter of creating a python.exe.manifest file, but i can't actually do any testing because it doesn't work under wine. so, pending any further advice and guidance from anyone which allows me to successfully proceed, i'm not going to continue to compile - or release - python2.5 *or* python2.6 builds (when i get round to that) using msvcr80 or msvcr9X. one issue in favour of this decision is that the DLL that's produced by the autoconf build process is "libpython2.5.dll.a" - not "python2.5.dll". it has a different name. it should be abundantly clear to users and developers that "if name equals libpython2.5.dll.a then duh build equals different". additionally, the setup.py distutils all goes swimmingly well and lovely - using libpython2.5.dll.a. the only issue which _is_ going to throw a spanner in the works is that people who download win32-built precompiled c-based modules are going to find that hey, "it don't work!" and the answer will have to be "go get a version of that module, compiled with mingw, not MSVC". of course - if python for win32 ENTIRELY DROPPED msvc as a development platform, and went for an entirely free software development toolchain, then this problem goes away. thoughts, anyone? l. ___ 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] Copyright notices in modules
On 2009-01-20 11:02, Michael Foord wrote: > M.-A. Lemburg wrote: >> [snip...] >> >>> Does the copyright concept even apply to an >>> abstract base class (I thought APIs were not >>> subject to copyright, just like database layouts >>> and language definitions)? >>> >> >> It applies to the written program text. You are probably >> thinking about other IP rights such as patents or designs. >> >> > > You need to read Van Lindberg's excellent book on intellectual property > rights and open source (which is about American law and European law > will be different). Mere collections of facts are not copyrightable as > they are not creative (the basis of copyright) and this is presumed to > apply to parts of software like header files and interface descriptions > - which could easily apply to ABCs in Python. I doubt that you can make such assumptions in general. It's a case-by-case decision and also one that depends on the copyright law or convention you assume. See e.g. the WIPO copyright treaty: http://www.wipo.int/treaties/en/ip/wct/trtdocs_wo033.html#P56_5626 and the Berne Convention: http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html#P85_10661 and TRIPS: http://www.wto.org/english/docs_e/legal_e/27-trips_04_e.htm#1 That said, for numbers.py there's certainly enough creativity in that file to enjoy copyright protection. > I recommend his book by the way - I'm about half way through so far and > it is highly readable Thanks for the pointer. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 20 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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 3142: Add a "while" clause to generator expressions
Kristján Valur Jónsson wrote: > Are you all certain that this mapping from a generator expression to > a foor loop isn't just a happy coincidence? After all, the generator > statement is just a generalization of the list comprehension and that > doesn't map quite so directly. The mapping of the for and if clauses is identical for both generator expressions and the various flavours of comprehension. It's only the outer wrappings (creating a generator/dict/set/list) and the innermost loop body (yield statement/item assignment/set add/list append) that differ between the constructs. As Terry noted, it's even defined that way in the language reference - the expressions are pure syntactic sugar for the corresponding statements. While this doesn't often matter in practice (since people tend to switch to using the statement based versions rather than writing convoluted multiple clause comprehensions), it's still an important symmetry that matters greatly to Python VM implementers so any proposed changes need to take it into account. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Questions/comments on documentation formatting
Brett Cannon wrote: On Mon, Jan 19, 2009 at 19:02, Scott Dial wrote: Brett Cannon wrote: 3. Are brackets for optional arguments (e.g. ``def fxn(a [, b=None [, c=None]])``) really necessary when default argument values are present? And do we really need to nest the brackets when it is obvious that having on optional argument means the rest are optional as well? I can't think of an example off the top of my head, but I'm certain the point of nesting the brackets is to delimit the optional arguments into groups. Documenting your fxn() examples as "fxn(a [, b=None, c=None])" would imply that if you provide 'b' then you must provide 'c', or if we abandon nested brackets, it's ambiguous as to the requirements. Imagine seeing "foo(a [, b=None, c=None [, d=None]])" and I think the rationale for such notation becomes clear. Well, that is such a rare case that I don't know if it warrants the line noise in the argument declaration. That argument also doesn't make sense in the face of ``fxn(a [, a=None [, b=None]])`` where 'b' almost always has no connection to 'a', but is still supposed to be listed that way because of positional arguments being optional. I understand using them for C functions where there is no such thing as a default argument, but it just doesn't make a ton of sense for Python code. I don't know of anyone who was confused by what help() spit out and not having fancy bracketing. I think the square bracketing is ugly and does nothing for clarity or readability. The sooner it can be phased out the better. Function annotations should probably only be used in API descriptions where those annotations actually exist - otherwise when there are real annotations you have a conflict on how to indicate that in the documentation. Michael -Brett ___ 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Copyright notices in modules
M.-A. Lemburg wrote: [snip...] Does the copyright concept even apply to an abstract base class (I thought APIs were not subject to copyright, just like database layouts and language definitions)? It applies to the written program text. You are probably thinking about other IP rights such as patents or designs. You need to read Van Lindberg's excellent book on intellectual property rights and open source (which is about American law and European law will be different). Mere collections of facts are not copyrightable as they are not creative (the basis of copyright) and this is presumed to apply to parts of software like header files and interface descriptions - which could easily apply to ABCs in Python. I recommend his book by the way - I'm about half way through so far and it is highly readable Michael Foord -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Copyright notices in modules
On 2009-01-20 00:56, Raymond Hettinger wrote: > Why does numbers.py say: > ># Copyright 2007 Google, Inc. All Rights Reserved. ># Licensed to PSF under a Contributor Agreement. Because that's where that file originated, I guess. This is part of what you have to do for things that are licensed to the PSF under a contributor agreement: http://www.python.org/psf/contrib/contrib-form/ """ Contributor shall identify each Contribution by placing the following notice in its source code adjacent to Contributor's valid copyright notice: "Licensed to PSF under a Contributor Agreement." """ > Weren't there multiple contributors including non-google people? The initial contribution was done by Google (Jeffrey Yasskin AFAIK) and that's where the above lines originated from. > Does Google want to be associated with code that > was submitted with no tests? Only Google can comment on this. > Do we want this sort of stuff in the code? Yes, it is required by the contrib forms. > If someone signs a contributor agreement, can we > forgo the external copyright comments? No. See above. Only the copyright owner can remove such notices. > Do we want to make a practice of every contributor > commenting in the name of the company they were > working for at the time (if so, I would have to add > the comment to a lot of modules)? That depends on the contract a contributor has with the company that funded the work. It's quite common for such contracts to include a clause stating that all IP generated during work time is owned by the employer. > Does the copyright concept even apply to an > abstract base class (I thought APIs were not > subject to copyright, just like database layouts > and language definitions)? It applies to the written program text. You are probably thinking about other IP rights such as patents or designs. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 20 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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
