SEARCH YOUR SOLUTION HERE  

Reminder: Michigan Python Users Group meeting on Thursday

This is a reminder of the upcoming michipug meeting.

This is the first anniversary meeting of the Michigan Python Users Group!

Thursday, September 7th at 7PM

Our topics for this month include an SQLAlchemy Introduction by Mark
Ramm and Steve Kryskalla talking about two of the new Python 2.5
features.

The meeting will be held at the Arbor Networks office in Ann Arbor.:

Arbor Networks
City Center Building
220 East Huron, 6th Floor
Ann Arbor, MI

Map: http://tinyurl.com/pt957

With the topics we have for this meeting, I would expect about 90
minutes of the main topics. We often have free-flowing discussion
following the main topics, so feel free to come with other topics you
wish to discuss.

See you there!

Kevin

--
Kevin Dangoor
TurboGears / Zesty News

email: kid@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

Posted On: Monday 5th of November 2012 04:08:30 AM Total Views:  270
View Complete with Replies




Related Messages:

APL2007 reminder: early (cheaper) registration ends Thursday 9/13   (78 Views)
On-line registration is through the OOPSLA registrar http://www.regmaster.com/conf/oopsla2007.html APL 2007 home page http://www.sigapl.org/apl2007.html
PyCon reminder: register now!   (72 Views)
Remember, Monday January 15th is the last day for early-bird registration for PyCon 2007 (February 23-25, in Addison Texas). For registration, go to . If you're interested in the tutorials you should register as soon as possible. One tutorial is nearing its maximum size; when that limit is reached, registration for that tutorial will be closed. Hurry!
dear comp.lang.python.announce readers   (101 Views)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It's getting a bit tiresome seeing one misguided American after another with their cutsie little yellow or red-white-blue ribbons on their outsized SUVs. Yeah, I guess it's the thing to do; maybe part of that whole soccer-mom culture. Unfortunately, the only thing they demonstrate is that the person behind the wheel is a clueless, gullible, misguided, nitwit. If foreign invaders landed on our soil, as we have done in Iraq, I would be the first one to take up arms and repel them. (I suppose that would make me an 'insurgent' by OUR logic.) This, and other aggressive governments have always done their utmost to make it APPEAR as if committing yourself to kill in feuds on distant shores that have nothing to do with the welfare of the citizenry is somehow patriotic. It is not. Enlisting in the armed forces, in the absence of a real and impending foreign threat, is no different that hiring yourself as a paid assassin . . the only difference is, you're not getting paid enough. But let's take a realistic look at exactly WHO joins up in an all-volunteer army. The first group are those who join (during peacetime) for the benefits: to get an education, or because it seems a reasonable career path. Consider carefully! Realize that you are gambling with your humanity. Once you sign that form, you sign away your right to say: "No, that is an atrocity." You put your abilities, including the ability to kill, at the disposal of proven liars, psychopaths . . . enemies of humanity. Do you think that every German soldier in World War II who helped load Jews into cattle cars was a cold-blooded killer Most were poor kids, just like you, who got caught up in the patriotic frenzy. Once you're in, you're IN. You lose the ability to stop killing until they tell you so. This not only makes you less than human, it makes you less than an animal, for even the animals retain their freedom of self determination. The second group are the simple minded, who fall for patriotic entreaties about defending democracy, Mom, apple pie; in other words, all the traditional government propaganda. Do you think Soviet lads subjugated their neighbors throughout the world because they thought the Soviet Union was an EVIL empire No, they were fighting for MOM, and whatever passes for apple pie in Russia. Step back and examine the lies your government is handing you, and ask yourself if they have the ring of truth. Do you want to be one of the murderers in uniform who opened up on their fellow citizens at Kent State When you put on that uniform, you give up all autonomy, and become nothing more than a weapon, to be used for whatever evil purposes the scoundrels in government demand (and, if you look carefully, you will discover that the only interests THEY serve are those of the big businesses that own them.) Finally, you have the hard-core psychopaths. These are the people who WANT to kill. Murder, torture, rape; THESE are the American values upon which THIS group is focused. The cause doesn't matter, they're after the thrill that only warfare can provide. Just remember: killing for George W. Bush, or for George H.W. Bush, or for Lyndon B. Johnson, or for Richard M. Nixon is not the same as defending yourself, your family, your or your country. Don't be a dupe. Don't Enlist! Remember -- supporting the troops means supporting Bush aggression, profiteering, and war crimes. Here's an idea: why not take those ribbons, dip them in blood, and mail them to the White House - -- Tom St.Denis 111 Banning Rd Kanata, Ontario K2L 1C3 Canada Home: (613)836-3160 Cell: (613)796-8220 tomstdenis@gmail.com KeyID: 0x40B640D5 Fingerprint: 53F9 307F F83E D52A 9E63 C2A5 B43F D952 40B6 40D5 http://pgp.mit.edu:11371/pks/lookup...rch=0x40B640D5 -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQxLVO7Q/2VJAtkDVEQJnnQCg1mRyNVgZ6Po6Xf7csn62Ph9rkC8AoMxZ Zo8jLvfr6bDGWZb/PhEpz3c8 =2NAY -----END PGP SIGNATURE-----
python-dev Summary for 2005-08-01 through 2005-08-15   (89 Views)
[The HTML version of this Summary is available at http://www.python.org/dev/summary/20...05-08-15.html] ============= Announcements ============= ---------------------------- QOTF: Quote of the Fortnight ---------------------------- Some wise words from Donovan Baarda in the PEP 347 discussions: It is true that some well designed/developed software becomes reliable very quickly. However, it still takes heavy use over time to prove that. Contributing thread: - `PEP: Migrating the Python CVS to Subversion `__ [SJB] ------------ Process PEPs ------------ The PEP editors have introduced a new PEP category: "Process", for PEPs that don't fit into the "Standards Track" and "Informational" categories. More detail can be found in `PEP 1`_, which is itself a Process PEP. ... _PEP 1: http://www.python.org/peps/pep-0001.html Contributing thread: - `new PEP type: Process `__ [TAM] ----------------------------------------------- Tentative Schedule for 2.4.2 and 2.5a1 Releases ----------------------------------------------- Python 2.4.2 is tentatively scheduled for a mid-to-late September release and a first alpha of Python 2.5 for March 2006 (with a final release around May/June). This means that a PEP for the 2.5 release, detailing what will be included, will likely be created soon; at present there are various accepted PEPs that have not yet been implemented. Contributing thread: - `plans for 2.4.2 and 2.5a1 `__ [TAM] ========= Summaries ========= ------------------------------- Moving Python CVS to Subversion ------------------------------- The `PEP 347`_ discussion from last fortnight continued this week, with a revision of the PEP, and a lot more discussion about possible version control software (RCS) for the Python repository, and where the repository should be hosted. Note that this is not a discussion about bug trackers, which will remain with Sourceforge (unless a separate PEP is developed for moving that). Many revision control systems were extensively discussed, including `Subversion`_ (SVN), `Perforce`_, `Mercurial`_, and `Monotone`_. Whichever system is moved to, it should be able to be hosted somewhere (if *.python.org, then it needs to be easily installable), needs to have software available to convert a repository from CVS, and ideally would be open-source; similarity to CVS is also an advantage in that it requires a smaller learning curve for existing developers. While Martin isn't willing to discuss every system there is, he will investigate those that make him curious, and will add other people's submissions to the PEP, where appropriate. The thread included a short discussion about the authentication mechanism that svn.python.org will use; svn+ssh seems to be a clear winner, and a test repository will be setup by Martin next fortnight. The possibility of moving to a distributed revision control system (particularly `Bazaar-NG`_) was also brought up. Many people liked the idea of using a distributed revision control system, but it seems unlikely that Bazaar-NG is mature enough to be used for the main Python repository at the current time (a move to it at a later time is possible, but outside the scope of the PEP). Distributed RCS are meant to reduce the barrier to participation (anyone can create their own branches, for example); Bazaar-NG is also implemented in Python, which is of some benefit. James Y Knight pointed out `svk`_, which lets developers create their own branches within SVN. In general, the python-dev crowd is in favour of moving to SVN. Initial concern about the demands on the volunteer admins should the repository be hosted at svn.python.org were addressed by Barry Warsaw, who believes that the load will be easily managed with the existing volunteers. Various alternative hosts were discussed, and if detailed reports about any of them are created, these can be added to the PEP. While the fate of all PEPS lie with the BDFL (Guido), it is likely that the preferences of those that frequently check in changes, the pydotorg admins, and the release managers (who have all given favourable reports so far), will have a significant effect on the pronouncement of this PEP. ... _PEP 347: http://www.python.org/peps/pep-0347.html ... _svk: http://svk.elixus.org/ ... _Perforce: http://www.perforce.com/ ... _Subversion: http://subversion.tigris.org/ ... _Monotone: http://venge.net/monotone/ ... _Bazaar-NG: http://www.bazaar-ng.org/ ... _Mercurial: http://www.selenic.com/mercurial/ Contributing threads: - `PEP: Migrating the Python CVS to Subversion `__ - `PEP 347: Migration to Subversion `__ - `Hosting svn.python.org `__ - `Fwd: Distributed RCS `__ - `cvs to bzr `__ - `Distributed RCS `__ - `Fwd: PEP: Migrating the Python CVS to Subversion `__ - `On distributed vs centralised SCM for Python `__ [TAM] ------------------------------------------ PEP 348: Exception Hierarchy in Python 3.0 ------------------------------------------ This fortnight mostly concluded the previous discussion about `PEP 348`_, which sets out a roadmap for changes to the exception hierarchy in Python 3.0. The proposal was heavily scaled back to retain most of the current exception hierarchy unchanged. A new exception, BaseException, will be introduced above Exception in the current hierarchy, and KeyboardInterrupt and SystemExit will become siblings of Exception. The goal here is that:: except Exception: will now do the right thing for most cases, that is, it will catch all the exceptions that you can generally recover from. The PEP would also move NotImplementedError out from under RuntimeError, and alter the semantics of the bare except so that:: except: is the equivalent of:: except Exception: Only BaseException will appear in Python 2.5. The remaining modifications will not occur until Python 3.0. ... _PEP 348: http://www.python.org/peps/pep-0348.html Contributing threads: - `Pre-PEP: Exception Reorganization for Python 3.0 `__ - `PEP, take 2: Exception Reorganization for Python 3.0 `__ - `Exception Reorg PEP checked in `__ - `PEP 348: Exception Reorganization for Python 3.0 `__ - `Major revision of PEP 348 committed `__ - `Exception Reorg PEP revised yet again `__ - `PEP 348 and ControlFlow `__ - `PEP 348 (exception reorg) revised again `__ [SJB] ---------------------- Moving towards Unicode ---------------------- Neil Schemenauer presented `PEP 349`_, which tries to ease the transition to Python 3.0, in which there will be a bytes() type for byte data and a str() type for text data. Currently to convert an object to text, you have one of three options: * Call str(). This breaks with a UnicodeEncodeError if the object is of type unicode (or a subtype) or can only represent itself in unicode and therefore returns unicode from __str__. * Call unicode(). This can break external code that is not yet Unicode-safe and that passed a str object to your code but got a unicode object back. * Use the "%s" format specifier. This breaks with a UnicodeEncodeError if the object can only represent itself in unicode and therefore returns unicode from __str__. `PEP 349`_ attempts to address this problem by introducing a text() builtin which returns str or unicode instances unmodified, and returns the result of calling __str__() on the object otherwise. Guido preferred to instead relax the restrictions on str() to allow it to return unicode objects. Neil implemented such a patch, and found that it broke only two test cases. The discussion stopped shortly after Neil's report however, so it was unclear if any permanent changes had been agreed upon. Guido made a few other Python 3.0 suggestions in this thread: * The bytes() type should be mutable with a corresponding frozenbytes() immutable type * Opening a file in binary or text mode would cause it to return bytes() or str() objects, respectively * The file type should grow a getpos()/setpos() pair that are identical to tell()/seek() when a file is open in binary mode, and which work like tell()/seek() but on characters instead of bytes when a file is opened in text mode. However, none of these seemed to be solid commitments. ... _PEP 349: http://www.python.org/peps/pep-0349.html Contributing threads: - `PEP: Generalised String Coercion `__ - `Generalised String Coercion `__ [SJB] ---------------------------- PEP 344 and reference cycles ---------------------------- Armin Rigo brought up an issue with `PEP 344`_ which proposes, among other things, adding a __traceback__ attribute to exceptions to avoid the hassle of extracting it from sys.exc_info(). Armin pointed out that if exceptions grow a __traceback__ attribute, every statement:: except Exception, e: will create a cycle:: e.__traceback__.tb_frame.f_locals['e'] Despite the fact that Python has cyclic garbage collection, there are still some situations where cycles like this can cause problems. Armin showed an example of such a case:: class X: def __del__(self): try: typo except Exception, e: e_type, e_value, e_tb = sys.exc_info() Even in current Python, instances of the X class are uncollectible. When garbage collection runs and tries to collect an X object, it calls the __del__() method. This creates the cycle:: e_tb.tb_frame.f_locals['e_tb'] The X object itself is available through this cycle (in ``f_locals['self']``), so the X object's refcount does not drop to 0 when __del__() returns, so it cannot be collected. The next time garbage collection runs, it finds that the X object has not been collected, calls its __del__() method again and repeats the process. Tim Peters suggested this problem could be solved by declaring that __del__() methods are called exactly once. This allows the above X object to be collected because on the second run of the garbage collection, __del__() is not called again. Thus, the refcount of the X object is not incremented, and so it is collected by garbage collection. However, guaranteeing that __del__() is called only once means keeping track somehow of which objects' __del__() methods were called, which seemed somewhat unattractive. There was also brief talk about removing __del__ in favor of weakrefs, but those waters seemed about as murky as the garbage collection ones. ... _PEP 344: http://www.python.org/peps/pep-0344.html Contributing thread: - `__traceback__ and reference cycles `__ [SJB] ---------------------------- Style for raising exceptions ---------------------------- Guido explained that these days exceptions should always be raised as:: raise SomeException("some argument") instead of:: raise SomeException, "some argument" The second will go away in Python 3.0, and is only present now for backwards compatibility. (It was necessary when strings could be exceptions, in order to pass both the exception "type" and message.) PEPs 8_ and 3000_ were accordingly updated. ... _8: http://www.python.org/peps/pep-0008.html ... _3000: http://www.python.org/peps/pep-3000.html Contributing threads: - `PEP 8: exception style `__ - `FW: PEP 8: exception style `__ [SJB] ----------------------------------- Skipping list comprehensions in pdb ----------------------------------- When using pdb, the only way to skip to the end of a loop is to set a breakpoint on the line after the loop. Ilya Sandler suggested adding an optimal numeric argument to pdb's "next" comment to indicate how many lines of code should be skipped. Martin v. Lwis pointed out that this differs from gdb's "next " command, which does "next" n times. Ilya suggested implementing gdb's "until" command instead, which gained Martin's approval. It was also pointed out that pdb is one of the less Pythonic modules, particularly in terms of the ability to subclass/extend, and would be a good candidate for rewriting, if anyone had the inclination and time. Contributing threads: - `pdb: should next command be extended `__ - `an alternative suggestion, Re: pdb: should next command be extended `__ [TAM] ------------------ Sets in Python 2.5 ------------------ Raymond Hettinger has been checking-in the new implementation for sets in Python 2.5. The implementation is based heavily on dictobject.c, the code for Python dict() objects, and generally deviates only when there is an obvious gain in doing so. Raymond posted a proposed C API sets; no comments were forthcoming and it was implemented for Py2.5 without changes. Contributing threads: - `[Python-checkins] python/dist/src/Objects setobject.c, 1.45, 1.46 `__ - `Discussion draft: Proposed Py2.5 C API for set and frozenset objects `__ [SJB] ================================ Deferred Threads (for next time) ================================ - `SWIG and rlcompleter `__ =============== Skipped Threads =============== - `Extension of struct to handle non byte aligned values `__ - `Syscall Proxying in Python `__ - `__autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code) `__ - `Weekly Python Patch/Bug Summary `__ - `PEP 342 Implementation `__ - `String exceptions in Python source `__ - `[ python-Patches-790710 ] breakpoint command lists in pdb `__ - `[C++-sig] GCC version compatibility `__ - `PyTuple_Pack added references undocumented `__ - `PEP-- Context Managment variant `__ - `Sourceforge CVS down `__ - `PSF grant / contacts `__ - `Python + Ping `__ - `Terminology for PEP 343 `__ - `dev listinfo page (was: Re: Python + Ping) `__ - `set.remove feature/bug `__ - `Extension to dl module to allow passing strings from native function `__ - `build problems on macosx (CVS HEAD) `__ - `request for code review - hashlib - patch #1121611 `__ - `python-dev Summary for 2005-07-16 through 2005-07-31 [draft] `__ - `string_join overrides TypeError exception thrown in generator `__ - `implementation of copy standard lib `__ - `xml.parsers.expat no userdata in callback functions `__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from August 01, 2005 through August 15, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). Tim Lesher has had to bow out from the summaries for now; many thanks to him for the contributions he made over the last few months. This is the 1st summary written by the python-dev summary confederacy of Steve Bethard and Tony Meyer
announcing: "testing-in-python" mailing list   (85 Views)
Folks, catalyzed by the great fun we had at PyCon '07, Grig Gheorghiu and I have created the "testing-in-python" (or "TIP") mailing list. This list will hopefully serve as a forum for discussing Python testing tools, testing approaches useful in Python, Web resources for same, and whatever else people would like to talk about. ("Proposed: The Death Star would not have had a single point of failure had it been written in Python and tested with the Death Star Testing Protocol Tool. Discuss.") Grig has a blog post about the list here: http://agiletesting.blogspot.com/200...ling-list.html You can sign up for the [mailman] list here: http://lists.idyll.org/listinfo/testing-in-python Subscribers can post to the list at 'tip@lists.idyll.org'. List archives are available here: http://lists.idyll.org/pipermail/testing-in-python/ cheers, --titus
python-dev Summary for 2005-06-16 through 2005-06-30   (87 Views)
[The HTML version of this Summary is available at http://www.python.org/dev/summary/20...05-06-30.html] ===================== Summary Announcements ===================== ------------------ OSCON Registration ------------------ Though if you haven't yet registered, you've already missed the early registration period (which ended June 20), you should still consider taking a look at the O'Reilly Open Source Convention (OSCON). Guido assures us that "the Python program is really good!" Contributing Thread: - `Please spread the word about OSCON early reg deadline `__ ========= Summaries ========= ------------ PEP Clean Up ------------ Raymond Hettinger decided to go through the `list of PEPs`_ and do some spring cleaning (late for the Northern Hemisphere, but early down south). * Rejection of `PEP 303`_ ("Extend divmod() for Multiple Divisors") was proposed on the grounds that it has been open for two and half years and hasn't generated discussion or support, is unpersuasive, and unnecessary. No-one spoke up for it (and some against), so it is now rejected. * Rejection of `PEP 254`_ ("Making Classes Look More Like Types") was proposed on the grounds that it is only an empty stub and is unlikely to ever get filled-out. No-one spoke up either way, and it is now rejected. * Rejection of `PEP 265`_ ("Sorting Dictionaries by Value") was proposed on the grounds that as of Python 2.4 its use case is easily solved with a one-line sorted() solution. Several people agreed, and no-one disagreed, so the PEP is now rejcted. * Rejection of `PEP 276`_ ("Simple iterator for ints") was proposed on the grounds that the principal use case was largely met by enumerate() and that the proposed syntax was problematic. Guido agreed, so the PEP was rejected. * Rejection of `PEP 281`_ ("Loop Counter Iteration with range and xrange") was proposed on the grounds that it too was solved by the enumerate() built-in. Guido agreed again, and this PEP too was rejected. * Rejection of `PEP 294`_ ("Type Names in the types Module") was proposed on the grounds that a centralized repository of type names was a mistake and that neither the "types" nor "new" modules should be carried forward to Python 3.0. No-one disagreed, and the PEP was rejected. * Rejection of `PEP 313`_ ("Adding Roman Numeral Literals to Python" - yes, this is a real PEP!) was proposed, and the PEP was rejected. * Rejection of `PEP 336`_ ("Make None Callable") was proposed on the grounds that no support has grown beyond the original poster, and that it fails the tests of obviousness, necessity, clarity, and explicitness. Many people, including Guido, agreed, and the PEP was rejected. * Raymond suggested updating `PEP 284`_ ("Integer for-loops"), but several people spoke up against it, including Guido, so the PEP was rejected. * Raymond asked whether `PEP 330`_ ("Python Bytecode Verification") had any known uses. Guido said that he believes that a verification tool has some value, but if someone wants to add it to Tools/scripts, no PEP is required, so the PEP was rejected. * A.M. Kuchling volunteered to take over `PEP 206`_ ("Python Advanced Library", or the "Batteries Included" PEP) and rewrite it to describe a set of third-party packages to complement the standard library. This was approved, and so he's now the maintainer. * Raymond suggested accepting `PEP 312`_ ("Simple Implicit Lambda"), which resulted in the most discussion of any of the PEP recommendations. However, Guido hates the unary colon syntax, and it was decided that the PEP needs to go back to the drawing board and find a more Pythonic syntax (perhaps an alternative unary operator). The PEP is now deferred. * Raymond asked whether `PEP 237`_ ("Unifying Long Integers and Integers") was now complete and could be marked as final. Guido noted that it was complete for 2.x, but that phase C will be implemented in Python 3.0, as the PEP states. He indicated that he would be fine with marking `PEP 237`_ as final and moving this phase to `PEP 3000`_; at the time of writing, this hadn't been done yet. ... _list of PEPs: http://wwww.python.org/peps ... _PEP 303: http://www.python.org/peps/pep-0303.html ... _PEP 265: http://www.python.org/peps/pep-0265.html ... _PEP 254: http://www.python.org/peps/pep-0254.html ... _PEP 276: http://www.python.org/peps/pep-0276.html ... _PEP 281: http://www.python.org/peps/pep-0281.html ... _PEP 294: http://www.python.org/peps/pep-0294.html ... _PEP 313: http://www.python.org/peps/pep-0313.html ... _PEP 336: http://www.python.org/peps/pep-0336.html ... _PEP 284: http://www.python.org/peps/pep-0284.html ... _PEP 330: http://www.python.org/peps/pep-0330.html ... _PEP 206: http://www.python.org/peps/pep-0206.html ... _PEP 312: http://www.python.org/peps/pep-0312.html ... _PEP 237: http://www.python.org/peps/pep-0237.html ... _PEP 3000: http://www.python.org/peps/pep-3000.html Contributing Threads: - `Propose rejection of PEP 303 -- Extend divmod() for Multiple Divisors `__ - `Propose to close PEP 254 -- Making Classes Look More Like Types `__ - `Propose to reject PEP 265 -- Sorting Dictionaries by Value `__ - `Propose to reject PEP 276 -- Simple iterator for ints `__ - `Propose to reject PEP 281 -- Loop Counter Iteration with range and xrange `__ - `Propose to reject PEP 294 -- Type Names in the types Module `__ - `Propose to reject PEP 313 -- Adding Roman Numeral Literals to Python `__ - `Propose to reject PEP 336 -- Make None Callable `__ - `Propose updating PEP 284 -- Integer for-loops `__ - `Question about PEP 330 -- Python Bytecode Verification `__ - `Request to rewrite PEP 206 `__ - `Recommend accepting PEP 312 -- Simple Implicit Lambda `__ - `Is PEP 237 final -- Unifying Long Integers and Integers `__ [TAM] ------------------------------------------- PEP 342: Coroutines via Enhanced Generators ------------------------------------------- Raymond Hettinger withdrew `PEP 288`_, since the exception-handling part is now covered in `PEP 343`_ and the generator-attributes part was never very popular. Though he seemed to think `PEP 342`_ could replace the generator-attributes part, he was concerned that `PEP 342`_ was proposing too extensive a set of changes, as it modified the basic for-loop and continue statement semantics, and created a split between new- and old-style iterators. As a result of those comments, Phillip J. Eby took over `PEP 342`_, eliminated the continue expression and modification of the for-loop, added some motivating examples, and provided a `prototype patch`_ implementing the proposal. `PEP 342`_ now retains normal Python for-loop and continue statements, and does not introduce a new iterator protocol. Instead, it modifies the generator-iterator type by adding the methods: - send(value) which acts like the previously proposed single-argument form of next(). (Introducing a new method instead of overloading next() minimizes overhead for simple next() calls.) Calling send(value) before the generator has advanced to the first yield-expression raises a TypeError. - throw() which injects exceptions at the point of the generator's last yield-expression. - close() which injects a GeneratorExit exception into the generator to make sure that it terminates. PEP 342 also attempts to ensure that this close() method will be called when a generator-iterator is garbage-collected. Additionally, Phillip's patch addressed some garbage collection issues, having generators set their gi_frame to None when they finish, and modifying gcmodule.c to check for tp_del methods on instance objects (instead of just on heap types) so that the close() methods of generators would be properly invoked. The revised PEP was accepted by Guido at EuroPython. ... _PEP 288: http://www.python.org/peps/pep-0288.html ... _PEP 342: http://www.python.org/peps/pep-0342.html ... _PEP 343: http://www.python.org/peps/pep-0343.html ... _prototype patch: http://python.org/sf/1223381 Contributing Threads: - `Withdrawn PEP 288 and thoughts on PEP 342 `__ - `Implementing PEP 342 (was Re: Withdrawn PEP 288 and thoughts on PEP 342) `__ - `gcmodule issue w/adding __del__ to generator objects `__ - `Generator enhancements patch available `__ [SJB] -------------------------------------------------- Adding Jason Ordenorff's path module to the stdlib -------------------------------------------------- Reinhold Birkenfeld suggested that Jason Ordenorff's `path module`_ should be in the standard library as it has a large user base, frequently c.l.py praises, is a superior interface to OS paths than the existing os.path module, and could more easily be made to properly support unicode paths. Phillip J. Eby reviewed the module and made a list of suggested changes, primarily changing so that there is only one way to do things and clearing up naming confusion between the module and the existing os.path module, but was generally in favour of inclusion. The suggestion was to call the object either "path" or "Path" and put it either in the os module or os.path module, although Guido vetoed os.path.path and Tony Meyer begged for more differentiation between the path class and path module than a single character's case. Early enthusiasm suggested that a PEP wasn't needed to include the module, as there was general agreement about the inclusion and all but minor details. Guido disagreed, however, asking whether there was a need for a completely different mechanism for doing the same things that os.path already does, and inevitable disgreements about details (e.g. time in seconds, or a datetime object) reinforced the need for a PEP. Discussion was still continuing at the end of the summary period; a PEP seems the likely outcome. ... _path module: http://www.jorendorff.com/articles/python/path/ Contributing Thread: - `Adding the 'path' module (was Re: Some RFE for review) `__ [TAM] ------------------------------- PEP 304 searches for a champion ------------------------------- Skip Montanaro wrote `PEP 304`_ ("Controlling Generation of Bytecode Files") a couple of years ago, and has mostly sat idle other than minor updates. Skip has no personal use for the PEP, and can't offer championing for it than continuing to respond to people's inputs. He asked whether anyone would be willing to take up championship of the PEP, or if it could be rejected. There were a couple of people interested in the idea, but no-one has yet volunteered to take the PEP from Skip. ... _PEP 304: http://www.python.org/peps/pep-0304.html Contributing Threads: - `PEP 304 - is anyone really interested `__ - `PEP 304 "Controlling Generation of Bytecode Files" - patch updated `__ [TAM] ------------------------- Merging float and Decimal ------------------------- Fredrik Johansson suggested that Python floats and decimal.Decimal objects should be merged together much in the way that Python ints and longs have been. The idea would be that a binary or decimal represenation could be selected at runtime using a context object like decimal.Context. This would allow code like:: >>> from __future__ import new_float_behaviour >>> 1.1 1.1 >>> import sys >>> sys.float_context.binary = True >>> 1.1 1.1000000000000001 One issue would be the extent to which various context settings could be respected for both binary and decimal floating-point numbers. Since binary floating-point numbers would be represented using C floats, they would not have direct access to the traps and flags that decimal.Decimal floats do because these signals are not available in C. This issue could possibly be addressed by maintaining platform-dependent code for accessing traps and flags. People seemed generally to agree with the proposal, with Raymond Hettinger suggesting a roadmap: first move decimal.Decimal objects to C code, next introduce decimal literals such as 123.45d, and then perhaps use decimal floating-point numbers as the default in Python 3.0. Contributing Thread: - `Decimal floats as default (was: discussion about PEP239 and 240) `__ [SJB] ------------------------------------------------ API differences between builtin set and sets.Set ------------------------------------------------ Barry Warsaw noted that builtin set objects (unlike sets.Set objects) do not have .union_update() methods as aliases for their .update() methods. He also pointed out that the documentation for builtin set objects does not cover the .update() method, and wrongly indicates that the set methods only accept sequences, not iterables. Raymond Hettinger pointed-out that dropping union_update() from the API was an intentional design decision that was be discussed prior to release. At Barry's suggestion, Raymond expanded the docs to include a detailed list of differences between the set builtins and the sets module. The list is thankfully short. Contributing Thread: - `Inconsistent API for sets.Set and build-in set `__ [SJB] ---------------------------------- Using the alternate form of iter() ---------------------------------- In the dowhile threads, Jp Calderone pointed out a useful case for the alternate form of iter() which takes a no-argument function to call repeatedly, and a sentinel value to look for:: for chunk in iter(lambda: f1.read(CHUNK_SIZE), ''): f2.write(chunk) This started a brief discussion on how this very useful idiom could be made easier to read. I suggested that it would be nice if iter() had a signature like unittest.TestCase.assertRaises which accepts ``*args`` and ``**kwargs`` to be passed to the function when it is called. This would have to be a Python 3.0 change because it's backwards incompatible, but would look something like:: for chunk in iter('', f1.read, CHUNK_SIZE): f2.write(chunk) Benji York, Michael Hudson and James Y Knight suggested that functional.partial (which will be available in Python 2.5) is a more general solution because it does not require argument reordering and it can also be used in the occasional cases that require multiple callables:: for chunk in iter(partial(f1.read, CHUNK_SIZE), ''): f2.write(chunk) Raymond Hettinger suggested a Python 3.0 roadmap: the file API should evolve an iterblocks(size) method, and iteration patterns terminating with '' should all be replaced with modern iterators that terminate by raising StopIteration. Contributing Thread: - `iter alternate form and *args and **kwargs `__ [SJB] -------------------------------------- Adding lightweight cooperative threads -------------------------------------- Adam Olsen outlined various problems with the current state of Python threading (they are expensive, unpredictable, uninterupptible, fail silently, and have finely grained atomicity), and proposed adding lightweight cooperative threads to Python (including a new operator for threaded calls, and new statement for creating threads). The proposal received no support, however, with Adam pointed towards `Stackless Python`_ and greenlets from `the Py lib`_ as similar solutions that do not require modification of the language. `PEP 342`_ was also touted as a solution - the PEP includes a short (
ANN: python-ldap-2.0.7   (62 Views)
Find a new release of python-ldap: http://python-ldap.sourceforge.net/ python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema). ---------------------------------------------------------------- Released 2.0.7 2005-04-29 Changes since 2.0.6: * Added preliminary support for sending LDAP controls with a request. Contributors: - Deepak Giridharagopal - Ingo Steuwer (Receiving controls in LDAP results still not supported.) Modules: * LDAPObject.c: removed l_ldap_manage_dsa_it() * LDAPObject.c: Added missing #ifdef around l_ldap_passwd() for compability with older OpenLDAP libs. Lib:/ * New algorithm in ldap.schema.tokenizer.split_tokens() contributed by Wido Depping which is more robust when parsing very broken schema elements (e.g. Oracle's OID). * Fixed argument list (position of timeout) when calling LDAPObject.search_ext_s() from search_st() and search_s(). * LDAPObject.search_ext_s() correctly calls search_ext_s() now. * Re-implemented LDAPObject.manage_dsa_it() without calling _ldap.
ANNOUNCE: gnome-python 2.9.0 (unstable)   (61 Views)
gnome-python 2.9.0 has been just released. This is the first *unstable* release of the series leading up to gnome-python 2.10. This release contains some internal reorganisations in the modules, as previously announced in pygtk list. gnome-python provides python interfacing modules for the most important GNOME Developer Platform libraries. The source tarball can be found here: http://ftp.gnome.org/pub/GNOME/sourc...me-python/2.9/ Overview of Changes from gnome-python 2.6.1 to gnome-python 2.9.0 ================================================================= * Now targetting gnome 2.10 platform (though currently compiles with 2.8) * New module layout: - gnome.applet moved to gnome-python-extras and renamed as gnomeapplet - gnome.vfs was renamed as gnomevfs - gnome.canvas was renamed as gnomecanvas - gnomeprint* moved to gnome-python-extras - gtkhtml2 moved to gnome-python-extras - gnome.nautilus was removed * A bunch of new gconf functions wrapped (Gustavo, Johan) * A bunch of new gnome.ui functions wrapped (Gustavo) * Proper property support in gnome.program_init (Gustavo) * gnomevfs - wrap gnome_vfs_format_file_size_for_display (Benot Dejean) * canvas - implement CanvasItem.grab (Johan) -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic
ANN: python-ldap-2.0.4   (68 Views)
Find a new pre-release of python-ldap: http://python-ldap.sourceforge.net/ python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema). ---------------------------------------------------------------- Released 2.0.4 2004-10-27 Changes since 2.0.3: Modules/: * Applied some fixes for 64-bit platforms to LDAPObject.c * Constants ldap.TLS_AVAIL and ldap.SASL_AVAIL will indicate whether python-ldap was built with support for SSL/TLS and/or SASL setup.py and Modules/: * Applied some fixes for building under Win32
pyvm - a portable python virtual machine   (80 Views)
pyvm 1.4.9 ========== "More batteries to your python" Introduction: pyvm is a relocatable python binary distribution containing several modules. Its main aim is to provide all this without requiring root access. Features: * pyqt (widget set) * pygtk (widget set) * nummarray (array and matematical) * pyqwt (plot widget in qt) * matplotlib (plot function similar tomatlab) * Imaging (a digital imaging library) * elementree (xml library) * and many many more. Download: http://pyvm.sourceforge.net Copyright: MIT for the building script, other licence terms apply to the singular package (see the docs) Author: Antonio Cavallo pyvm@mailsnare.com
ANN: python-ldap-2.2.1   (73 Views)
Find a new release of python-ldap: http://python-ldap.sourceforge.net/ python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema). ---------------------------------------------------------------- Released 2.2.1 2006-11-15 Changes since 2.2.0: Modules/ * Fix for Python 2.5 free(): invalid pointer (see SF#1575329) * passwd() accepts None for arguments user, oldpw, newpw (see SF#1440151) Lib/ * ldif.LDIFWriter.unparse() now accepts instances of derived dict and list classes (see SF#1489898)
python-dev Summary for 2004-07-01 through 2004-07-15   (78 Views)
python-dev Summary for 2004-07-01 through 2004-07-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from July 01, 2004 through July 15, 2004. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the forty-forth summary written by Brett Cannon (wished he could be at OSCON to see Guido throw a pie). To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there. summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; it's simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. ... _PEP Markup: http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation on new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ .. Reported bugs and suggested patches can be found at the SourceForge_ project page. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF_ cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps. ... _python-dev: http://www.python.org/dev/ ... _SourceForge: http://sourceforge.net/tracker/group_id=5470 ... _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev ... _comp.lang.python: http://groups.google.com/groupsq=comp.lang.python ... _Docutils: http://docutils.sf.net/ ... _reST: ... _reStructuredText: http://docutils.sf.net/rst.html ... _PSF: ... _Python Software Foundation: http://python.org/psf/ ... contents:: ... _last summary: http://www.python.org/dev/summary/20...004-07-15.html ... _original text file: http://www.python.org/dev/summary/20..._2004-07-15.ht Summary Announcements ===================== I don't think my informal editors on python-dev often enough for their help. In case you didn't know, I send a rough draft (read: first draft since I **hate** proof-reading) to python-dev before a summary out for general consumption to make sure I didn't totally get something wrong. Luckily I tend not to screw stuff up that badly and it ends up being little grammatical errors here and there. But if it wasn't for them the summaries would not be the level of quality that they are (read: wouldn't seem like they are written by some grad student with impeccable grammar but instead as if they are written by some grad student with decent grammar =). Anyway, I just felt like I should give a public thanks to who has ever sent me a fix. In case you didn't know, Python 2.4a1 was released in early July. If you have not already please `download `__ it and run the `regression test suite `__. And it looks like Unicode will finally work in the Summaries!
www.python.org down   (74 Views)
Yes, we know that www.python.org is down. Please be patient. -- Aahz (aahz@pythoncraft.com) http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR
python-dev Summary for 2005-01-01 through 2005-01-15   (88 Views)
This is a summary of traffic on the `python-dev mailing list`_ from January 01, 2005 through January 15, 2005. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the fifty-sixth summary written by Brett Cannon (I don't want to do my homework). To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there. summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; it's simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. ... _PEP Markup: http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation on new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF_ cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps. ... _python-dev: http://www.python.org/dev/ ... _SourceForge: http://sourceforge.net/tracker/group_id=5470 ... _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev ... _comp.lang.python: http://groups.google.com/groupsq=comp.lang.python ... _Docutils: http://docutils.sf.net/ ... _reST: ... _reStructuredText: http://docutils.sf.net/rst.html ... _PSF: ... _Python Software Foundation: http://python.org/psf/ ... contents:: ... _last summary: http://www.python.org/dev/summary/20...004-12-31.html ... _original text file: http://www.python.org/dev/summary/20..._2005-01-15.ht ===================== Summary Announcements ===================== PyCon_ will be upon us come late March! Still time to plan to go. A warning on the thoroughness off this summary is in order. While trying to delete a single thread of email I managed to accidentally delete my entire python-dev mailbox. I did the best I could to retrieve the emails but it's possible I didn't resuscitate all of my emails, so I may have overlooked something. ... _PyCon: http://www.pycon.org/ ======= Summary ======= ------------- PEP movements ------------- tip:: PEP updates by email are available as a topic from the `Python-checkins`_ mailing list. `PEP 246`_ was a major topic of discussion during the time period covered by this summary. This all stemmed from `Guido's blog`_ entries on optional type checking. This led to a huge discussion on many aspects of protocols, interfaces, and adaptation and the broadening of this author's vocabulary to include "Liskov violation". "Monkey typing" also became a new term to know thanks to Phillip J. Eby's proto-PEP on the topic (found at http://peak.telecommunity.com/DevCenter/MonkeyTyping). Stemming from the phrase "monkey see, monkey do", it's Phillip version of taking PEP 246 logically farther (I think; the whole thing is more than my currently burned-out-on-school brain can handle right now). ... _Python-checkins: http://mail.python.org/mailman/listinfo/python-checkins ... _PEP 246: http://www.python.org/peps/pep-0246.html ... _Guido's blog: http://www.artima.com/weblogs/index.jspblogger=guido Contributing threads: - `getattr and __mro__ `__ - `Son of PEP 246, redux `__ - `PEP 246: lossless and stateless `__ - `PEP 246: LiskovViolation as a name `__ - `"Monkey Typing" pre-PEP, partial draft `__ ------------------------------------------------------------------------------------ Optional type checking: how to inadvertently cause a flame war worse than decorators ------------------------------------------------------------------------------------ `Guido's blog`_ had comments on the idea of adding optional static type checking to Python. While just comments in a blog, it caused a massive response from people, mostly negative from what I gathered. After Guido discussed things some more it culminated in a blog entry found at http://www.artima.com/weblogs/viewpost.jspthread=87182 that lays out what his actual plans are. I highly recommend reading it since it suggests adding optional run-time type checking for function arguments along with some other proposals. of this led to `PEP 246`_ getting updated. For some more details on that see the `PEP movements`_ section of this summary. And if there is a lesson to be learned from all of this, it's that when Alex Martelli and Phillip J. Eby start a technical discussion it's going to be long, in-depth, complex, and lead to my inbox being brimming in python-dev email. ------------------------------ Let's get the AST branch done! ------------------------------ Guido posted an email to the list stating he would like to to make progress towards integrating "things like type inferencing, integrating PyChecker, or optional static type checking" into Python. In order to make that easier he put out a request that people work on the AST branch and finish it. For those that don't know about Python's back-end, the compiler as it stands now takes the parse tree from the parser and emits bytecode directly from that. This is far from optimal since the parse tree is more verbose than needed and it is not the easiest thing to work with. The AST branch attempts to fix this by taking a more traditional approach to compiling. This means the parse tree is used to generate an AST (abstract syntax tree; and even more technically could be considered a control flow graph in view of how it is implemented) which in turn is used to emit bytecode. The AST itself is much easier to work with when compared to the parse tree; better to know you are working with an 'if' guard thanks to it being an 'if' node in the AST than checking if the parse tree statement you are working with starts with 'if' and ends with a ':'. While all of this sounds great, the issue is the AST branch is not finished yet. It is not entirely far off, but new features from 2.4 (decorators and generator expressions) need to be added along with more bug fixing and clean up. This means the AST branch is going to get finished for 2.5 somehow. But help is needed. While the usual suspects who have previously contributed to the branch are hoping to finish it, more help is always appreciated. If you care to get involved, check out the AST branch (tagged as 'ast-branch' in CVS; see the `python-dev FAQ`_ on how to do a tagged branch checkout), read Python/compile.txt and just dive in! There will also be a sprint on the AST branch at PyCon. ... _python-dev FAQ: http://www.python.org/dev/devfaq.html Contributing threads: - `Please help complete the AST branch `__ - `Will ASTbranch compile on windows yet `__ - `ast branch pragmatics `__ - `Re: [Python-checkins] python/dist/src/Python pythonrun.c, 2.161.2.15, 2.161.2.16 `__ -------------------------------- Ditching unbound methods in Py3k -------------------------------- Guido suggested removing unbound methods from Python since their usefulness of checking their first argument and other slight differences from functions just didn't seem worth keeping around and complicating the language. So the idea seems sound. But then people with uses for the extra information kept in unbound methods (im_func and im_self) popped up. To make the long thread short, enough people stepped up mentioning uses they had for the information for Guido to retract the suggestion in the name of backwards compatibility. But unbound methods are now on the list of things to go in Python 3000. Contributing threads: - `Let's get rid of unbound methods `__ - `Getting rid of unbound methods: patch available `__ - `PEP 246 - concrete assistance to developers of new adapter classes `__ ------------------------------------------ Getting exceptions to be new-style classes ------------------------------------------ A patch to allow exceptions to be new-style classes is currently at http://www.python.org/1104669 . The plan is to get that patch in order, apply it, and as long as a ton of code does not break from exceptions moving from classic to new-style classes it will be made permanent in 2.5 . This in no way touches on the major changes as touched upon in a `previous summary `__ which will need a PEP to get the hierarchy cleaned up and discuss any possible changes to bar 'except' statements. Contributing threads: - `Exceptions *must* be old-style classes `__ ----------------------------- Recent IBM patents and Python ----------------------------- note:: contributed by Jim Jewett Current python policy is that all submissions must be unemcumbered by intellectual property claims. See http://www.python.org/psf/psf-contri...agreement.html IBM has recently released several patents for use in Open Source Software, with the restriction that they can revoke the grant if you sue to enforce any Intellectual Property rights against any Open Source project. Is this an acceptable license restriction, or should code covered by these patents be rejected No explicit decision was made. Contributing threads: - `Recent IBM Patent releases `__ =============== Skipped Threads =============== - Mac questions - 2.3.5 schedule, and something I'd like to get in - csv module TODO list - an idea for improving struct.unpack api - Minor change to behaviour of csv module - PATCH/RFC for AF_NETLINK support - logging class submission - frame.f_locals is writable - redux: fractional seconds in strptime - Darwin's realloc(...) implementation never shrinks allocations
python-dev Summary for 2004-12-01 through 2004-12-15   (77 Views)
This is a summary of traffic on the `python-dev mailing list`_ from December 01, 2004 through December 15, 2004. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the fifty-fourth summary written by Brett Cannon (amazed no one has complained about the lateness of these summaries!). To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there. summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; it's simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. ... _PEP Markup: http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation on new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF_ cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps. ... _python-dev: http://www.python.org/dev/ ... _SourceForge: http://sourceforge.net/tracker/group_id=5470 ... _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev ... _comp.lang.python: http://groups.google.com/groupsq=comp.lang.python ... _Docutils: http://docutils.sf.net/ ... _reST: ... _reStructuredText: http://docutils.sf.net/rst.html ... _PSF: ... _Python Software Foundation: http://python.org/psf/ ... contents:: ... _last summary: http://www.python.org/dev/summary/20...004-11-30.html ... _original text file: http://www.python.org/dev/summary/20..._2004-12-15.ht ===================== Summary Announcements ===================== PyCon_ 2005 planning is well underway. The schedule has been posted at http://www.python.org/pycon/2005/schedule.html and looks great with a quite the varied topics. And there is still time for the early-bird registration price of $175 ($125 students) before it expires on January 28th. Some day I will be all caught up with the Summaries... ... _PyCon: http://www.pycon.org ========= Summaries ========= ---------------------------------- PEPS: those existing and gestating ---------------------------------- [for emails on PEP updates, subscribe to python-checkins_ and choose the 'PEP' topic] A proto-PEP covering the __source__ proposal from the `last summary`_ has been posted to python-dev. `PEP 338`_ proposes how to modify the '-m' modifier so as to be able to execute modules contained within packages. ... _python-checkins: http://mail.python.org/mailman/listinfo/python-checkins ... _PEP 338: http://www.python.org/peps/pep-0338.html Contributing threads: - `PEP: __source__ proposal `__ - `PEP 338: Executing modules inside packages with '-m' `__ ------------------- Deprecating modules ------------------- The xmllib module was deprecated but not listed in `PEP 4`_. What does one do Well, this led to a long discussion on how to handle module deprecation. With the 'warning' module now in existence, PEP 4 seemed to be less important. It was generally agreed that listing modules in PEP 4 was no longer needed. It was also agreed that deleting deprecated modules was not needed; it breaks code and disk space is cheap. It seems that no longer listing documentation and adding a deprecation warning is what is needed to properly deprecate a module. By no longer listing documentation new programmers will not use the code since they won't know about it. And adding the warning will let old users know that they should be using something else. ... _PEP 4: http://www.python.org/peps/pep-0004.html Contributing threads: - `Deprecated xmllib module `__ - `Rewriting PEP4 `__ ------------------------------------------ PR to fight the idea that Python is "slow" ------------------------------------------ An article_ in ACM TechNews that covered 2.4 had several mentions that Python was "slow" while justifying the slowness (whether it be flexibility or being fast enough). Guido (rightfully) didn't love all of the "slow" mentions which I am sure we have all heard at some point or another. The suggestions started to pour in on how to combat this. The initial one was to have a native compiler. The thinking was that if we compiled to a native executable that people psychologically would stop the association of Python being interpreted which is supposed to be slow. Some people didn't love this idea since a native compiler is not an easy thing. Others suggested including Pyrex with CPython, but didn't catch on (maintenance issue plus one might say Pyrex is not the most Pythonic solution). This didn't get anywhere in the end beyond the idea of a SIG about the various bundling tools (py2app, py2exe, etc.). The other idea was to just stop worrying about speed and move on stomping out bugs and making Python functionally more useful. With modules in the stdlib being rewritten in C for performance reasons it was suggested we are putting out the perception that performance is important to us. Several other people also suggested that we just not mention speed as a big deal in release notes and such. This also tied into the idea that managers don't worry too much about speed as much as being able to hire a bunch of Python programmers. This led to the suggestion of also emphasizing that Python is very easy to learn and thus is a moot point. There are a good number of Python programmers, though; Stephan Deibel had some rough calculations that put the number at about 750K Python developers worldwide (give or take; rough middle point of two different calculations). ... _article: http://gcn.com/vol1_no1/daily-updates/28026-1.html Contributing threads: - `2.4 news reaches interesting places `__ =============== Skipped Threads =============== - MS VC compiler versions - Any reason why CPPFLAGS not used in compiling Extension modules now compile with directories specified in the LDFLAGS and CPPFLAGS env vars - adding key argument to min and max min and max now have a 'key' argument like list.sort - Unicode in doctests - SRE bug and notifications - PyInt_FromLong returning NULL - PyOS_InputHook enhancement proposal - The other Py2.4 issue - MinGW And The other Py2.4 issue - Supporting Third Party Modules - Python in education
ANN: python-ldap-2.0.0   (61 Views)
Find a new pre-release of python-ldap: http://python-ldap.sourceforge.net/ python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema). ---------------------------------------------------------------- Released 2.0.0 2004-05-18 Changes since 2.0.0pre21: ldif: * Empty records are simply ignored in ldif.LDIFWriter.unparse() Modules/: * New method result2() returns 3-tuple containing the msgid of the outstanding operation. ldap.ldapobject: * New _ldap wrapper method LDAPObject.result2() (see above) which is now used by LDAPObject.result().
Updated Cygwin Package: python-2.3.3-2   (81 Views)
New News: === ==== I have updated the version of Python to 2.3.3-2. The tarballs should be available on a Cygwin mirror near you shortly. The following are the notable changes since the previous release: o all known 64-bit I/O issues are resolved o Berkeley DB module is built against Berkeley DB 4.2 Old News: === ==== Python is an interpreted, interactive, object-oriented programming language. If interested, see the Python web site for more details: http://www.python.org/ Please read the README file: /usr/share/doc/Cygwin/python-2.3.3.README since it covers requirements, installation, known issues, etc. To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. Note that we have recently stopped downloads from sources.redhat.com (aka cygwin.com) due to bandwidth limitations. This means that you will need to find a mirror which has this update. In the US, ftp://mirrors.rcn.net/mirrors/source...at.com/cygwin/ is a reliable high bandwidth connection. In Germany, ftp://ftp.uni-erlangen.de/pub/pc/gnu...irrors/cygnus/ is usually pretty good. In the UK, http://programming.ccp14.ac.uk/ftp-m...in/pub/cygwin/ is usually up-to-date within 48 hours. If one of the above doesn't have the latest version of this package then you can either wait for the site to be updated or find another mirror. The setup.exe program will figure out what needs to be updated on your system and will install newer packages automatically. If you have questions or comments, please send them to the Cygwin mailing list at: cygwin@cygwin.com . I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. If you want to make a point or ask a question, the Cygwin mailing list is the appropriate place. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com@cygwin.com Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
python-dev Summary for 2006-02-01 through 2006-02-15   (104 Views)
python-dev Summary for 2006-02-01 through 2006-02-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ ... contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/20...01_2006-02-15] ============= Announcements ============= ----------------------------- QOTF: Quotes of the Fortnight ----------------------------- We had a plethora (yes, I did just say plethora) of quotable quotes this fortnight. Martin v. Lwis on the `lambda keyword`_: I believe that usage of a keyword with the name of a Greek letter also contributes to people considering something broken. Raymond Hettinger on the `learnability of Python`_: A language suitable for beginners should be easy to learn, but it should not leave them permanently crippled... To misquote Einstein: The language should be as simple as possible, but no simpler. Robert Brewer on `Pythonic syntax`_: Community consensus on syntax is a pipe dream. ... _lambda keyword: http://mail.python.org/pipermail/pyt...ry/060389.html ... _learnability of Python: http://mail.python.org/pipermail/pyt...ry/060420.html ... _Pythonic syntax: http://mail.python.org/pipermail/pyt...ry/060556.html [SJB] -------------------- Release plan for 2.5 -------------------- `PEP 356`_ lists the release plan for Python 2.5. Check it out for the latest feature updates and planned release dates. ... _PEP 356: http://www.python.org/dev/peps/pep-0356/ Contributing threads: - `release plan for 2.5 `__ - `2.5 release schedule `__ - `2.5 PEP `__ [SJB] ---------------------------- lsprof available as cProfile ---------------------------- Armin Rigo finished his integration of the lsprof profiler. It's now available as the cProfile module which exposes the same interface as profile. Contributing thread: - `cProfile module `__ [SJB] --------------------- ssize_t branch merged --------------------- Martin v. Lwis merged in the ssize_t branch (`PEP 353`_). you folks on 64 bit machines should now be able to index sequences using your full address space. Enjoy! ... _PEP 353: http://www.python.org/dev/peps/pep-0353/ Contributing threads: - `ssize_t status (Was: release plan for 2.5 ) `__ - `ssize_t branch (Was: release plan for 2.5 ) `__ - `ssize_t branch merged `__ [SJB] ========= Summaries ========= ------------------------------------------------------ Rumors of lambda's death have been greatly exaggerated ------------------------------------------------------ Guido's finally given in -- the lambda expression will stay in Python 3.0. Of course, this didn't stave off another massively long thread discussing the issue, but Guido finally killed that by providing a pretty exhaustive list of why we should keep lambda as it is: * No purely `syntactic change to lambda`_ is clearly a net gain over the current syntax * It's perfectly fine that Python's lambda is different from Lisp's * Lambda current binding behavior is (correctly) exactly the same as a def statement * owing a block inside a lambda is never going to work because of the need to indent the block ... _syntactic change to lambda: http://wiki.python.org/moin/AlternateLambdaSyntax Contributing threads: - `any support for a methodcaller HOF `__ - `Let's just *keep* lambda `__ - `Let's send lambda to the shearing shed (Re: Let's just *keep* lambda) `__ [SJB] -------------- The bytes type -------------- Guido asked for an update to `PEP 332`_, which proposed a ``bytes`` type. This spawned a massive discussion about what the bytes type should look like and how it should interact with strings, especially in Python 3.0 when all strings would be unicode. Pretty much agreed that bytes objects should be mutable sequences of ints in the range(0, 256). Guido and others were also generally against a b'...' literal for bytes, as that would confusingly suggest that bytes objects were text-like, which they wouldn't be. There was a fair bit of haggling over the signature of the bytes constructor, but it seemed towards the end of the discussion that people were coming to an agreement on ``bytes(initializer [,encoding])``, where ``initializer`` could be a sequence of ints or a str or unicode instance, and where ``encoding`` would be an error for a sequence of ints, ignored for a str instance, and the encoding for a unicode instance. Some people argued that the encoding argument was unnecessary as unicode objects could be encoded using their .encode() method, but Guido was concerned that, at least before Python 3.0 when ..encode() would return bytes objects, the multiple copying (one for the encode, one for the bytes object creation) would require too much overhead. The default encoding for unicode objects was also a contentious point, with people suggesting ASCII, Latin-1, and the system default encoding. Guido argued that since Python strings don't know the encoding that was used to create them, and since a programmer who typed in Latin-1 would expect Latin-1 as the encoding and a programmer who typed in UTF-8 would expect UTF-8 as the encoding, then the only sensible solution was to encode unicode objects using the system default encoding (which is pretty much always ASCII). It seemed like an official PEP for the bytes type would be forthcoming. ... _PEP 332: http://www.python.org/peps/pep-0332.html Contributing threads: - `PEP 332 revival in coordination with pep 349 [ Was:Re: release plan for 2.5 ] `__ - `bytes type discussion `__ - `byte literals unnecessary [Was: PEP 332 revival in coordination with pep 349] `__ - `bytes type needs a new champion `__ [SJB] -------------- Octal literals -------------- Mattheww proposed removing octal literals, making 0640 a SyntaxError, and modifying functions like os.chmod to take string arguments instead, e.g. ``os.chmod(path, "0640")``. This led to a discussion about how necessary octal literals actually are -- the only use case mentioned in the thread was os.chmod() -- and how to improve their syntax. For octal literals people seemed to prefer an ``0o`` or ``0c`` prefix along the lines of the ``0x`` prefix, possibly introducing an ****ogous ``0b`` as binary literal syntax at the same time. People also suggested a number of syntaxes for expressing numeric literals in any base, but these seemed like overkill for the problem at hand. Contributing threads: - `Octal literals `__ - `Octal literals `__ [SJB] --------------------------------------------------- PEP 357: owing Any Object to be Used for Slicing --------------------------------------------------- Travis Oliphant presented `PEP 357`_ to address some issues with the sequence protocol. In Python 2.4 and earlier, if you defined an integer-like type, there was no way of letting Python use instances of your type in sequence indexing. And Python couldn't just call the ``__int__`` slot because then floats could be inappropriately used as indices, e.g. ``range(10)[5.7]`` would be ``5``. To solve this problem, `PEP 357`_ proposed adding an ``__index__`` slot that would be called when a sequence was given a non-integer in a slice. Floats would not define ``__index__`` because they could not be guaranteed to produce an exact integer, but exact integers like those in numpy_ could define this method and then be allowable as sequence indices. ... _PEP 357: http://www.python.org/peps/pep-0357.html ... _numpy: http://www.numpy.org/ Contributing threads: - `PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation `__ - `Please comment on PEP 357 -- adding nb_index slot to PyNumberMethods `__ [SJB] ----------------------------- const declarations in CPython ----------------------------- To avoid some deprecation warnings generated by C++, Jeremy Hylton had added ``const`` to a few CPython APIs that took ``char*`` but were typically called by passing string literals. This generated compiler errors when ``char**`` variables were passed to PyArg_ParseTupleAndKeywords. Initially, people thought this could be solved by changing ``const char **`` declarations to ``const char * const *`` declarations, but while this was fine for C++, it did not solve the problem for C. The end result was to remove the ``const`` declaration from the ``char **`` variables, but not the ``char *`` variables. Contributing thread: - `Baffled by PyArg_ParseTupleAndKeywords modification `__ [SJB] -------------------- asynchat and threads -------------------- Mark Edgington presented a patch adding "thread safety" to asynchat. Most people seemed to think mixing threads and asynchat was a bad idea, and the thread drifted off to talking about exracting a subset of Twisted to add to the stdlib (as a replacement for asynchat and asyncore). People seemed generally in favor of this (if the subset was reasonably small) but no one stepped forward to extract that subset. Contributing thread: - `threadsafe patch for asynchat `__ [SJB] --------------------------------------------------- Approximate equality between floating point numbers --------------------------------------------------- To make floating-point math easier for newbies, Alex Martelli proposed math.areclose() which would take two floating point numbers with optional tolerances and indicate whether or not they were "equal". With a similar motivation, Smith proposed a math.nice() function which would round floating point numbers in the same way that str() does. Raymond Hettinger and others expressed concern over the stated use case and suggested that hiding floating point details would only make learning their intricacies later more difficult. A few people suggested that math.areclose() might also be useful for experienced floating-point users, but it seemed that the proposal probably didn't have enough strength to get into the stdlib. Contributing threads: - `math.areclose ... `__ - `nice() `__ - `[Tutor] nice() `__ [SJB] ----------------------------- Eliminating compiler warnings ----------------------------- Thomas Wouters noticed a few gcc 4.0.x warnings on amd64, and asked if Python developers should strive to remove all warnings even if they're harmless. Tim Peters was definitely in favor of eliminating all warnings whenever possible, and so had Thomas Wouters unnecessarily (for other compilers at least) initialize a variable to silence the warning. Contributing threads: - `Compiler warnings `__ - `Compiler warnings `__ [SJB] --------------------------------- Adding syntactic support for sets --------------------------------- Greg Wilson asked about providing syntactic support for sets literals and set comprehensions, e.g. ``{1, 2, 3, 4, 5}`` and ``{z for z in x if (z % 2)}``. The set comprehension suggestion was pretty quickly shot down as it wasn't deemed to be much of an improvement over a generator expression in the set constructor, e.g. ``set(z for z in x if (z % 2))``. The question of syntactic support for set literals sparked a little more of a discussion. Some people initially suggested that syntactic support for set literals was unnecessary as the set constructor could be expanded, e.g ``set(1, 2, 3, 4, 5)``. However this proposal would not be backwards compatible as it would be unclear whether ``set('title')`` should be a set of one element or five. Others questioned whether the syntactically supported set literal should create a set() or a frozenset(). No one had a good answer for this latter question, and the rest of the thread drifted off into a miscellany of syntax suggestions. Contributing thread: - `syntactic support for sets `__ [SJB] ------------------------------- FD_SETSIZE in Windows and POSIX ------------------------------- Revision 42253 introduced a bug in Windows sockets by assuming that FD_SETSIZE was the maximum number of distinct file descriptors a file descriptor set can hold, and checking for this. FD_SETSIZE is actually the numerical magnitude of a file descriptor (which happens to correspond to the maximum number of distinct file descriptors on POSIX systems where fdsets are just big bit vectors). A #define, Py_DONT_CHECK_FD_SETSIZE, was introduced so that the check could be skipped on windows machines. Contributing thread: - `Pervasive socket failures on Windows `__ [SJB] ----------------------------- Iterators and __length_hint__ ----------------------------- In Python 2.4, a number of iterators had grown __len__ methods to allow for some optimizations (like allocating enough space to create a list out of them). Guido had asked for these methods to be removed and hidden instead as an implementation detail. Originally, Raymond had used the name ``_length_cue``, but he was convinced instead to use the name ``__length_hint__``. Contributing thread: - `_length_cue() `__ [SJB] ----------------------------------------------- Linking with mscvrt instead of the compiler CRT ----------------------------------------------- Martin v. Lwis suggested that on Windows, instead of linking Python with the CRT of the compiler used to compile Python, Python should be linked with mscvrt, the CRT that is part of the operating system. Martin hoped that this would get rid of problems where extension modules had to be compiled with the same compiler as the Python with which they were to run. Unfortunately, after further investigation, Martin had to withdraw the proposal as the platform SDK doesn't provide an import library for msvrt.dll and mscvrt is documented as being intended only for "system components". Contributing thread: - `Linking with mscvrt `__ [SJB] ------------------------------------------- Opening text and binary files in Python 3.0 ------------------------------------------- Guido indicated that in Python 3.0 there should be two open() functions, one for opening text files and one for opening binary files. The .read*() methods of text files would return unicode objects, while the .read*() methods of binary files would return bytes objects. People then suggested a variety of names for these functions including: * opentext() and openbytes() * text.open() and bytes.open() * file.text() and file.bytes() Guido didn't like the tight coupling of data types and IO libraries present in the latter two. He also expressed a preference for using open() instead of opentext(), since it was the more common use case. Of course, modifying open() in this way would be backwards incompatible and would thus have to wait until Python 3.0. Contributing thread: - `str object going in Py3K `__ [SJB] -------------------------------------------- Adding additional bdist_* installation types -------------------------------------------- Phillip Eby suggested adding bdist_deb, bdist_msi, and friends to the standard library in Python 2.5. People seemed generally in favor of this, though there was some discussion as to whether or not bdist_egg should also be included. The thread then trailed off into a discussion of the various installation behaviors on different platforms. Contributing thread: - `bdist_* to stdlib `__ [SJB] ------------------------------------- URL for the development documentation ------------------------------------- Georg Brandl pointed out that while http://docs.python.org/dev/ holds the current development documentation, http://www.python.org/dev/doc/devel was still available. Fred Drake indicated that it was definitely preferable to use the automatically updated docs (http://docs.python.org/dev/) but that having them on docs.python.org seemed wrong -- docs.python.org was established so that queries could be made for the current stable documentation without old docs or development docs showing up. Fred then proposed that the current stable documentation go up at http://www.python.org/doc/current/ and the current development documentation go up at http://www.python.org/dev/doc/. Guido thought that http://docs.python.org/ could possibly disappear in the new `python.org redesign`_. ... _python.org redesign: http://beta.python.org Contributing threads: - `http://www.python.org/dev/doc/devel still available `__ - `moving content around (Re: http://www.python.org/dev/doc/devel still available) `__ [SJB] ------------------------------------------------ PEP 355: Path - Object oriented filesystem paths ------------------------------------------------ BJrn Lindqvist updated `PEP 355`_ which proposes adding the path module to replace some of the functions in os, shutil, etc. At Guido's request, the use of ``/`` and ``//`` operators for path concatenation was removed, and a number of redundancies brought up in the last Path PEP discussion were addressed (though some redundancies, e.g. ``.name`` and ``.basename()`` seem to still be present). ... _PEP 355: http://www.python.org/peps/pep-0355.html Contributing threads: - `The path module PEP `__ - `Path PEP and the division operator `__ - `Path PEP: some comments `__ - `Path PEP -- a couple of typos. `__ [SJB] ----------------------------------------- Rejection of PEP 351: The freeze protocol ----------------------------------------- Raymond Hettinger's strong opposition to `PEP 351`_, the freeze protocol, finally won out, and Guido rejected the PEP. ... _PEP 351: http://www.python.org/peps/pep-0351.html Contributing thread: - `PEP 351 `__ [SJB] -------------------------------------- PEP 338 - Executing Modules as Scripts -------------------------------------- Nick Coghlan updated `PEP 338`_ to comply with the import system of `PEP 302`_. The updated PEP includes a ``run_module()`` function which will execute the supplied module as if it were a script (e.g. with __name__ == "__main__"). Since it supports the `PEP 302`_ import system, it properly handles modules in both packages and zip files. ... _PEP 302: http://www.python.org/peps/pep-0302.html ... _PEP 338: http://www.python.org/peps/pep-0338.html Contributing thread: - `PEP 338 - Executing Modules as Scripts `__ [SJB] ----------------------------------------------- Getting sources for a particular Python release ----------------------------------------------- David Abrahams wanted to get the Python-2.4.2 sources from SVN but couldn't figure out which tag to check out. The right answer for him was http://svn.python.org/projects/python/tags/r242/ and in general it seemed that the r tags corresponded to the .. release. Contributing thread: - `How to get the Python-2.4.2 sources from SVN `__ [SJB] --------------------------------------- PEP for \*args and \*\*kwargs unpacking --------------------------------------- Thomas Wouters asked if people would be interested in a PEP to generalize the use of \*args and \*\*kwargs to unpacking, e.g.: * ``['a', 'b', *iterable, 'c']`` * ``a, b, *rest = range(5)`` * ``{**defaults, **args, 'fixedopt': 1}`` * ``spam(*args, 3, **kwargs, spam='extra', eggs='yes')`` People definitely wanted to see a PEP, as these or similar suggestions have been raised a number of times. The time-table would likely be for Python 2.6 though, so no PEP has yet been made available. Contributing thread: - `Generalizing *args and **kwargs `__ [SJB] ---------------------- Tail call optimization ---------------------- In CPython, a function call requires a new execution frame, which is expensive compared to a loop. Some langauges (notably scheme) automically optimize tail-call recursion, so that in practice, it will be just as fast. This can be done in CPython by using abusing internals. It merged into the decorator module discussion; in the end, Guido did not want it in the standard library, in part because it would change exception tracebacks, and in part because it would likely be very different for other implementations (such as Jython). Contributing thread: - `Any interest in tail call optimization as a decorator `__ [Summary by Jim Jewett] -------------------------------- Things to check before a release -------------------------------- : , we should have changed the copyright dates to include 2006! Yeah, and lets write ourselves a note, so that we remember next year! Uh, where should put that reminder PEP 101 was used, since a new release should be at least one trigger for verifying that things like this happened. And putting it there reminded Georg that PEP 101 needs other updates too. (Example: It still refers to the source code in sourceforge CVS, rather than python.org SVN) Contributing thread: - `Where to put "post-it notes" `__ ================ Deferred Threads ================ - `The decorator(s) module `__ - `C AST to Python discussion `__ - `bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349] `__ - `how bugfixes are handled `__ ================== Previous Summaries ================== - `Extension to ConfigParser `__ - `[PATCH] Fix dictionary subclass semantics whenused as global dictionaries `__ =============== Skipped Threads =============== - `YAML (was Re: Extension to ConfigParser) `__ - `webmaster at python.org failing sender verification. `__ - `ctypes patch (was: (libffi) Re: Copyright issue) `__ - `ctypes patch `__ - `Weekly Python Patch/Bug Summary `__ - `Help with Unicode arrays in NumPy `__ - `small floating point number problem `__ - `Old Style Classes Goiung in Py3K `__ - `Make error on solaris 9 x86 - error: parse error before "upad128_t" `__ - `Python modules should link to libpython `__ - `Help on choosing a PEP to volunteer on it : 308, 328 or 343 `__ - `email 3.1 for Python 2.5 using PEP 8 module names `__ - `[BULK] Python-Dev Digest, Vol 31, Issue 37 `__ - `py3k and not equal; re names `__ - `Post-PyCon PyPy Sprint: February 27th - March 2nd 2006 `__ - `compiler.pyassem `__ - `To know how to set "pythonpath" `__ - `file.next() vs. file.readline() `__ - `Fwd: Ruby/Python Continuations: Turning a block callback into a read()-method `__ - `PEP 343: Context managers a superset of decorators `__ - `Missing PyCon 2006 `__ - `how to upload new MacPython web page `__ - `A codecs nit (was Re: bytes.from_hex()) `__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from February 01, 2006 through February 15, 2006. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This python-dev summary is the 13th written by the swat team of Steve Bethard and Tony Meyer (no, we still can't make a deadline). To contact us, please send email: - Steve Bethard (steven.bethard at gmail.com) - Tony Meyer (tony.meyer at gmail.com) Do *not* post to comp.lang.python if you wish to reach us. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every cent counts so even a small donation with a credit card, check, or by PayPal helps. -------------------- Commenting on Topics -------------------- To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! ------------------------- How to Read the Summaries ------------------------- That this summary is written using reStructuredText_. Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo ; you can safely ignore it. We do suggest learning reST, though; it's simple and is accepted for `PEP markup`_ and can be turned into many different formats like HTML and LaTeX. Unfortunately, even though reST is standardized, the wonders of programs that like to reformat text do not allow us to guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. ... _python-dev: http://www.python.org/dev/ ... _SourceForge: http://sourceforge.net/tracker/group_id=5470 ... _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev ... _c.l.py: ... _comp.lang.python: http://groups.google.com/groupsq=comp.lang.python ... _PEP Markup: http://www.python.org/peps/pep-0012.html ... _Docutils: http://docutils.sf.net/ ... _reST: ... _reStructuredText: http://docutils.sf.net/rst.html ... _PSF: ... _Python Software Foundation: http://python.org/psf/ ... _original text file: http://www.python.org/dev/summary/20...2006-02-15.rst ... _archive: http://www.python.org/dev/summary/ ... _RSS feed: http://www.python.org/dev/summary/channews.rdf
python-dev Summary for 2004-09-16 through 2004-09-30   (88 Views)
python-dev Summary for 2004-09-16 through 2004-09-30 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from September 16, 2004 through September 30, 2004. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the forty-ninth summary written by Brett Cannon (Wow, my thesis gives an entire .5% speed-up on pystone at the moment; ain't that grand...). To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there. summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; it's simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. ... _PEP Markup: http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation on new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF_ cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps. ... _python-dev: http://www.python.org/dev/ ... _SourceForge: http://sourceforge.net/tracker/group_id=5470 ... _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev ... _comp.lang.python: http://groups.google.com/groupsq=comp.lang.python ... _Docutils: http://docutils.sf.net/ ... _reST: ... _reStructuredText: http://docutils.sf.net/rst.html ... _PSF: ... _Python Software Foundation: http://python.org/psf/ ... contents:: ... _last summary: http://www.python.org/dev/summary/20...004-09-15.html ... _original text file: http://www.python.org/dev/summary/20..._2004-09-30.ht ===================== Summary Announcements ===================== Wow. This must have been the easiest summary I have ever done. Why can't they all be like this I didn't even skip that much! This summary also marks the first instance of having a contributing writer (ignoring the time when Raymond Hettinger was guest writer and wrote the whole summary himself). So thanks to Michael Chermside for writing up those summaries. And this is open to anyone, so if you feel that one of the skipped threads is worth summarizing and you catch it on the draft I send out of the Summary please mail them to me and it will probably get included. ========= Summaries ========= ------------------------------------------ Assume nothing when mutability is possible ------------------------------------------ Tim Peters discovered a new way to create an infinite list thanks to generator expressions. But what really came out of this whole discussion came about when someone else came up with an example that exposed a bug in list.extend(). The first thing was that "you can't assume anything about a mutable object after potentially calling back into Python." Basically you can't assume the state of any mutable object was not changed if you execute Python code from C. While it might seem handy to store state while in a loop for instance, you can't count on things not changing by the time you get control back so you just have to do it the hard way and get state all over again. Second was that you need to be careful when dealing with iterators. If you mutate an iterator while iterating you don't have a guarantee it won't explode in your face. Unless you explicitly support it, document it, and take care to protect against it then just don't assume you can mutate an iterator while using it. Contributing threads: - `A cute new way to get an infinite loop `__ - `More data points `__ ----------------------------- The fewer licenses the better ----------------------------- The idea of copying some code from OpenSSH_ for better pty handling was proposed. This was frowned upon since that becomes one more legal issue to keep track of. Minimizing the licenses that Python must keep track of and make sure to comply with, no matter how friendly, is a good thing. ... _OpenSSH: http://www.openssh.org/ Contributing threads: - `using openssh's pty code `__ ----------------------------------------------------------------------- Trying to deal with the exception hierarchy in a backwards-friendly way ----------------------------------------------------------------------- Nick Coghlan came up with the idea of having a tuple that contained all of the exceptions you normally would not want to catch in a blanket 'except' statement; KeyboardInterrupt, MemoryError, SystemExit, etc.). This tuple was proposed to live in sys.special_exceptions with the intended usage of:: try: pass # stuff... except sys.special_exceptions: raise # exceptions that you would not want to catch should keep propogating up the call chain except: pass # if you reach here the exception should not be a *huge* deal Obviously the best solution is to just clean up the exception hierarchy, but that breaks backwards-compatibility. But this idea seemed to lose steam. Contributing threads: - `Proposing a sys.special_exceptions tuple `__ -------------- Built on beer! -------------- by Michael Chermside In this short thread Guido admits that Python *is* really built on beer: "...it's true! During the early days, when hacking on Python, I often lived on stroopwafels and beer." Contributing threads: - `built on beer `__ ----------------------------------- Docs still available in gzip format ----------------------------------- by Michael Chermside Fred Drake suggested that we stop providing the Python documentation in gzip format. We offered the zip and bzip2 formats which have unique advantages (bzip2 compresses better and zip has a directory built in so individual files can be extracted) over gzip and he wanted to reduce the number of different formats offered. However, there was much dissention, so the final decision was to retain the format. Contributing threads: - `Planning to drop gzip compression for future releases. `__ --------------------------------------------------------- Making running stdlib modules as scripts that much easier --------------------------------------------------------- Nick Coghlan contributed a patch for a new command-line option, ``-m``, that will search sys.path for a module of that name and execute it as a ``__main__``. This can be really handy for things such as checking the docstrings of a module (``python -m pydoc heapq``) and such. Currently, though, it only for top-level modules in sys.path and thus ignores packages. If you want that functionality there is a recipe by Nick on the Python Cookbook at http://aspn.activestate.com/ASPN/Coo.../Recipe/307772 . There is also discussions going on python-dev about how to possibly add this in the future. Contributing threads: - `Running a module as a script `__ =============== Skipped Threads =============== - Decimal, copyright and license - Noam's open regex requests - Socket/Asyncore bug needs attention - open('/dev/null').read() -> MemoryError - Finding the module from PyTypeObject - Odd compile errors for bad genexps
python-dev Summary for 2004-09-01 through 2004-09-15   (104 Views)
python-dev Summary for 2004-09-01 through 2004-09-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from September 01, 2004 through September 15, 2004. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the forty-eighth summary written by Brett Cannon (hopefully school won't drown my this quarter). To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there. summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; it's simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. ... _PEP Markup: http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation on new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF_ cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps. ... _python-dev: http://www.python.org/dev/ ... _SourceForge: http://sourceforge.net/tracker/group_id=5470 ... _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev ... _comp.lang.python: http://groups.google.com/groupsq=comp.lang.python ... _Docutils: http://docutils.sf.net/ ... _reST: ... _reStructuredText: http://docutils.sf.net/rst.html ... _PSF: ... _Python Software Foundation: http://python.org/psf/ ... contents:: ... _last summary: http://www.python.org/dev/summary/20...004-08-31.html ... _original text file: http://www.python.org/dev/summary/20..._2004-09-15.ht ===================== Summary Announcements ===================== Python 2.4a3 has been released. Go to http://www.python.org/2.4/ and give it twirl. Sorry for this summary being so short, but school has started back up again so I am in the middle of suddenly having to switch back into homework mode after spending the summer just having a 9:00-17:00 job. And since it is a new school year I am going to abuse this space and say that anyone in San Luis Obispo, including students, should join the `SLO Meetup`_ coming up on October 14. ... _SLO Meetup: http://python.meetup.com/95/ ========= Summaries ========= -------------------- Movement in PEP Land -------------------- `PEP 334`_ (Simple Coroutines via SuspendIteration) came into existence. `PEP 328`_ (Relative Imports) got some discussion on postponing making imports absolute instead of the relative/absolute semantics they have now. As it stands it looks like the changeover might get pushed off. `PEP 292`_ (Simpler String Substitutions) seems to finally be done and locked down. `PEP 335`_ (Overloadable Boolean Operators) came into existence. ... _PEP 334: http://www.python.org/peps/pep-0334.html ... _PEP 328: http://www.python.org/peps/pep-0328.html ... _PEP 292: http://www.python.org/peps/pep-0292.html ... _PEP 335: http://www.python.org/peps/pep-0335.html Contributing threads: - `PEP 334 - Simple Coroutines via SuspendIteration `__ - `PEP 328 - Relative Imports `__ - `Re: Alternative Implementation for PEP 292:Simple String Substitutions `__ - `ANN: PEP 335: Overloadable Boolean Operators `__ ------------------------------------------------------ __str__, __unicode__, and how to have them play nicely ------------------------------------------------------ Did you know that __str__ methods are allowed to return Unicode objects Well, it turns out they can, but that str() (which calls PyObject_Str()) automatically tries to convert the value returned by __str__ into ASCII. Basically __str__ shouldn't return Unicode if you can help it and you should use __unicode__ instead and reserve __str__ to return str objects only. Contributing threads: - unicode and __str__ (couldn't find in archives) ---------------------- Backporting C APIs bad ---------------------- Somebody (*cough* Guido *cough*) asked if the datetime C API could be backported to 2.3 . The argument was that the only person who would probably use it is the person who asked for it, the author of cx_Oracle. Well, pretty much spoke up against this. The argument went that adding an API would just be bad since there would suddenly be a point in the 2.3 releases where backwards compatibility was broken. People brought up the point of 2.2 where in 2.2.1 booleans were added and how that has caused compatibility headaches for some people. In the end the API was not backported. Contributing threads: - `Re: [Python-checkins] python/dist/src/Modules threadmodule.c, 2.56, 2.56.8.1 `__ ---------------------------------------------------------------------- Got to love race conditions thanks to the filesystem and external apps ---------------------------------------------------------------------- Tim Peters found a race condition one can have on Windows if you have an app that uses the low-level hooks into the filesystem. If you create a file, delete it, and then try to delete the directory the directory deletion will fail since the file is not deleted yet. What can happen is an indexing program can still be indexing the file before the filesystem is allowed to delete it and thus the directory is not truly empty when the directory deletion is executed. Fun stuff. Contributing threads: - `Coernic Desktop Search versus shutil.rmtree `__ ------------------------------- Python 2.4a3 is out the door!!! ------------------------------- Go to http://www.python.org/2.4/ , download it (using the bz2 version if possible so as to save on bandwidth), and run it against your code, run the test suite, put it on your head and sell yourself to an art gallery, etc. Contributing threads: - `RELEASED Python 2.4, alpha 3 `__ ---------------------------- Cleaning the Exception House ---------------------------- The idea of reorganizing the exceptions hierarchy came up again (see http://www.python.org/dev/summary/20...from-exception for a previous discussion on this). This time, the idea of separating the hierarchy into exceptions one would like to catch with a bare 'except' and those that you wouldn't was brought up. The idea is that some exceptions, such as MemoryError, one does not want to catch in a blanket statement usually. Chances of recovering from that kind of exception is low and should only be caught if you know what you are doing. So tweaking the exception hierarchy so that exceptions that were not near-catastrophic could inherit from an exception class that people could catch so as to allow the proper exceptions to propagate to the top-level without issue. Tim Peters even went as far as to suggest deprecating bare 'except' statements. This would force people to be explicit about what they want to catch, whether it be all "safe" exceptions or *all* exceptions. As it stands now no officially decision has been made for Python 3000 since that is about the only place this could happen. Contributing threads: - `Dangerous exceptions `__ --------------------------------------------------------------- Making decorators not look like decorators to the outside world --------------------------------------------------------------- Raymond Hettinger pointed out that a decorator does not, by default, look like the function that it is fiddling with (if that is the intent). Since most decorators will most likely be a wrapper function some things need to be set in the wrapper in order not to mask things in the wrapped function (doc string, argument parameters, etc.). So Raymond pointed out some things one can do. This also led to the suggestion of having a common name used to store a reference back to the wrapped function. There was also the mention that a decorator-oriented module in the stdlib will probably materialize in Python 2.5 . For now, though, stick recipes either in the Python Cookbook or in the Python wiki at http://www.python.org/cgi-bin/moinmo...coratorLibrary . Contributing threads: - `decorator support `__ =============== Skipped Threads =============== - random.py still broken wrt. urandom - random.py fixage - Re: [Python-checkins] python/dist/src/Lib/test test_compiler.py, 1.5, 1.6 test_decimal.py, 1.13, 1.14 - assert failure on obmalloc - Re: [Python-checkins] python/dist/src/Modules socketmodule.c, 1.304, 1.305 - Install-on-first-use vs. optional extensions - Console vs. GUI applications - Adding status code constants to httplib - PEP 292: method names - PEP 265 - Sorting dicts by value - httplib is not v6 compatible, is this going to be fixed - OT: Unicode history - --with-tsc compile fails - tempfile.TemporaryFile on Windows NT - PyExc_UnicodeDecodeError - urllib.urlopen() vs IDNs, percent-encoded hosts, ':' - tabs in httplib.py and test_httplib.py There is now a vimrc file in the Misc directory that sets things up to follow PEPs 7 & 8 - strawman decision: @decorator won't change - unicode inconsistency