Re: [Python-Dev] Continuing 2.x
On Oct 28, 2010, at 10:51 PM, Brett Cannon wrote: > I think people need to stop viewing the difference between Python 2.7 > and Python 3.2 as this crazy shift and view it from python-dev's > perspective; it should be viewed one follows from the other at this > point. You can view it as Python 3.2 is the next version after Python > 2.7 just like 2.7 followed to 2.6, which makes the policies we follow > for releases make total sense and negates this discussion. It just so > happens people don't plan to switch to the newest release immediately > as the backward-incompatible changes are more involved than what > people are used to from past releases. Brett, with all due respect, this is not a reasonable position. You are making it sound like the popular view of 3.2 is a "crazy shift" is based on a personal dislike of python-dev or something. The fact is that the amount of effort required to port to 3.2 is extreme compared to previous upgrades, and most people still aren't willing to deal with it. It is a crazy shift. Let's take PyPI numbers as a proxy. There are ~8000 packages with a "Programming Language::Python" classifier. There are ~250 with "Programming Langauge::Python::3". Roughly speaking, we can say that is 3% of Python code which has been ported so far. Python 3.0 was released at the end of 2008, so people have had roughly 2 years to port, which comes up with 1.5% per year. Let's say that 20% of the code on PyPI is just junk; it's unfair to expect 100% of all code ever to get ported. But, still: with this back-of-the-envelope estimate of the rate of porting, it will take over 50 years before a decisive majority of Python code is on Python 3. By contrast, there are 536 packages with ::2.6, and 177 with ::2.7. (Trying to compare apples to apples here, since I assume the '2' tag is much more lightly used than '3' to identify supported versions; I figure someone likely to tag one micro-version would also tag the other.) 2.7 was released on July 3rd, so let's be generous and say approximately 6 months. That's 30% of packages, ported in 6 months, or 60% per year. This means that Python 3 is two orders of magnitude crazier of a shift than 2.7. I know that the methods involved at arriving at these numbers are not particularly good. But, I think that if their accuracy differs from that of the download stats, it's better: it takes a much more significant commitment to actually write some code and upload it than to accidentally download 3.x because it's the later version. Right now, Kristján is burning off his (non-fungible) enthusiasm in this discussion rather than addressing more 2.x maintenance issues. If 3.x adoption takes off and makes a nice hockey stick graph, then few people will care about this in retrospect. In the intervening hypothetical half-century while we wait to see how it pans out, isn't it better to just have an official Python branch for the "maybe 2.8" release? Nobody from the current core team needs to work on it, necessarily; either other, new maintainers will show up or they won't. For that matter, Kristján is still talking about porting much of his work to 3.x anyway. In the best case (3.x takes over the world in 6 months) a 2.x branch won't be needed and nobody will show up to do the work of a release; some small amount of this work (the stuff not ported to 3.x) will be lost. In the medium case (3.x adoption is good, but there are still millions of 2.x users in 5 years) it will accumulate some helpers that will make migrating to 3.x even smoother than with 2.7. In the worst case (straw man: 3.x adoption actually declines, and distros start maintaining their own branches of 2.7) I'm sure everyone will be glad that some of this maintenance effort took place and there's some central place to continue it. I'm perfectly willing to admit that I'm still too pessimistic about this and I could be wrong. But given the relatively minimal amount of effort required to let 2.x bugs continue to get fixed under the aegis of Python.org rather than going through the painful negotiation process of figuring out where else to host it (and thereby potentially losing a bunch of maintenance that would not otherwise happen), it seems foolhardy to insist that those of us who think 2.x is going to necessitate another release must necessarily be wrong. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
On Fri, 29 Oct 2010 02:55:55 -0400 Glyph Lefkowitz wrote: > > Let's say that 20% of the code on PyPI is just junk; > it's unfair to expect 100% of all code ever to get ported. But, still: > with this back-of-the-envelope estimate of the rate of porting, it will > take over 50 years before a decisive majority of Python code is on > Python 3. Well, no. A decisive majority would be much smaller than that. There are probably between 2% and 5% of the CheeseShop entries which are widely used dependencies. When these 2 to 5% all get ported, you have a decisive majority. Yes, perhaps more than 50% of 2.x code will never get ported. But, perhaps more than 50% of 1.5.2 code never got upgraded either. That doesn't make it any decisive; just dead (or pining for security fixes in some old rusty "RedHat Enterprise Linux" server, if you prefer). > Right now, Kristján is burning off his (non-fungible) enthusiasm > in this discussion rather than addressing more 2.x maintenance issues. By the same argument, we are also burning off our (non-fungible) enthusiasm trying to answer people like you and Kristján. Perhaps we should stop answering you and instead concentrate on improving 3.x? ;) Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
> Right now, Kristján is burning off his (non-fungible) enthusiasm in this > discussion rather than addressing more 2.x maintenance issues. If 3.x > adoption takes off and makes a nice hockey stick graph, then few people > will care about this in retrospect. In the intervening hypothetical > half-century while we wait to see how it pans out, isn't it better to > just have an official Python branch for the "maybe 2.8" release? Nobody > from the current core team needs to work on it, necessarily; either > other, new maintainers will show up or they won't. For that matter, > Kristján is still talking about porting much of his work to 3.x anyway. That might be - however, I think it is (now) clear that talking about this on python-dev isn't going to make it happen, at least not now. Nobody has really stepped forward to manage a Python 2.8 project; more specifically, Kristjan explicitly said that he will *not* do a Python 2.8 release. As Brett (IMHO correctly) analyzed: Kristjan wants a fork, a place where he can publish his Python changes. Not sure if anybody else has that desire, but if so, these people should get together and set something up. As for the specific implementation of the fork: people proposed that Kristjan should wait for the hg switchover, and can then easily host the fork anywhere (e.g. on bitbucket, or as a private clone on python.org). Assuming there are other contributors (outside of python-committers) to this fork as well, hosting it on bitbucket is probably easier since it will allow to give push permissions to non-core committers. > I'm perfectly willing to admit that I'm still too pessimistic about this > and I could be wrong. But given the relatively minimal amount of effort > required to let 2.x bugs continue to get fixed under the aegis of > Python.org I think here you are strongly mistaken. It is not a relatively minimal effort. Having to support another branch would be very very painful. > it seems foolhardy to insist that those of us who think 2.x is > going to necessitate another release must /necessarily/ be wrong. Predictions are always difficult to make. It may be that 2.x will necessitate another release (by some criteria), but I truly hope that you are wrong in predicting that such a release will actually happen. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
Kristján Valur Jónsson ccpgames.com> writes: > Let’s move the current ‘trunk’ into /branches/afterlife-27. Open it for > submissions from people such as myself that use 2.7 on a regular basis and are > willing to give it some extra love. Just curious - what specific new features or backwards-incompatible fixes do you need to add, i.e. things which cannot be catered for by release27-maint? Or is this just about the *principle* of having a 2.8? Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new buffer in python2.7
> Actually I would like code like
> s = socket()
> ...
> header = struct.unpack("i", s)
>
> In other words, struct should interact with files/streams directly, instead
> of
> requiring me to first read a chunk who's size I manually have to determine
> etc.
That is easy to achieve using the existing API:
def read_and_unpack(stream, format):
data = stream.read(struct.calcsize(format))
return struct.unpack(format, data)
> Otherwise, I'm +1 on your suggestion, avoiding copying is a good thing.
I believe my function also doesn't involve any unnecessary copies.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
> While maintainers' convenience is a valid valid concern and some level > of idiosyncrasy is healthy to allow active maintainers to code in > their preferred style, I think users' convenience should come first > when it conflicts with that of maintainers. Remember, code is written > once and read many. This is particularly true about stdlib. A minor > inconvenience of finding the right place to stick a new function in a > large file does not in my view overweights a major inconvenience of > not having all pieces in one place neatly organized in a linear order. I agree. While investigating an incompatibility in unittest2, I found that the breakage into multiple files makes it much harder to find out how things fit together, and where specifically a certain functionality is implemented. So join those who would have preferred this module to stay as a single 2000-line file. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
Vinay Sajip yahoo.co.uk> writes: > need to add, i.e. things which cannot be catered for by release27-maint? Or is > this just about the *principle* of having a 2.8? Never mind - I've just picked up the extra posts on this thread, which for some reason didn't show up in my reader before. Sorry for the noise. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
Brett Cannon wrote: > 2010/10/28 Kristján Valur Jónsson : >> I'm not sure what I'm actually proposing. But I certainly wasn't thinking >> of a new "fork" of python. And not a new version 2.8 that gets all new 3.x >> features backported. >> I'm more thinking of a place where usability improvements, C API >> improvements, performance improvements, Library improvments, can go. > > It's called a fork. I realize you are trying to avoid that "dirty" > word, Kristján, and I appreciate it, but you are describing a fork. > Python 2.7 is the last sanctioned version of the Python 2.x series, > period. Any non-bugfix changes will not go in there as policy > dictates. And with there being no way Python 2.8 will happen (I know > we as a group have said "slim chance" since Python 3.0 came out, > uptake of Python 3 is such I am willing to personally say "never" for > a python-dev sanctioned Python 2.8), that means it will take a fork, > whether it be internal to CCP or public somewhere, it will still be a > fork. > > And as everyone has said so far (and with which I agree), that's fine. > As long as it is not called Python 2.8 -- EVE-Python 2.8 or some Monty > Python reference -- then that's fine. I don't see why we should not welcome a team of new developers who want to continue working on the 2.x series. It's obvious that a large proportion of the existing python-dev'ers will not participate in such a project, but why should we try to stop someone else to work on it ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 29 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing zipfile.BadZipfile to zipfile.BadZipFile
The tests prove that r85874 does not break the build. On Fri, Oct 29, 2010 at 12:49 AM, Éric Araujo wrote: > Le 28/10/2010 22:52, anatoly techtonik a écrit : > > Can anybody summarize the outcome? > > Is it that renaming BadZipfile to BadZipFile with backward compatible > > alias and deprecation note breaks something? > > See #7351 or r85874. > > Regards > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/bostjan.mejak%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
2010/10/29 M.-A. Lemburg : > Brett Cannon wrote: >> 2010/10/28 Kristján Valur Jónsson : >>> I'm not sure what I'm actually proposing. But I certainly wasn't thinking >>> of a new "fork" of python. And not a new version 2.8 that gets all new 3.x >>> features backported. >>> I'm more thinking of a place where usability improvements, C API >>> improvements, performance improvements, Library improvments, can go. >> >> It's called a fork. I realize you are trying to avoid that "dirty" >> word, Kristján, and I appreciate it, but you are describing a fork. >> Python 2.7 is the last sanctioned version of the Python 2.x series, >> period. Any non-bugfix changes will not go in there as policy >> dictates. And with there being no way Python 2.8 will happen (I know >> we as a group have said "slim chance" since Python 3.0 came out, >> uptake of Python 3 is such I am willing to personally say "never" for >> a python-dev sanctioned Python 2.8), that means it will take a fork, >> whether it be internal to CCP or public somewhere, it will still be a >> fork. >> >> And as everyone has said so far (and with which I agree), that's fine. >> As long as it is not called Python 2.8 -- EVE-Python 2.8 or some Monty >> Python reference -- then that's fine. > > I don't see why we should not welcome a team of new developers who want > to continue working on the 2.x series. He's not saying we shouldn't welcome them; we just don't want to it attached to python-dev. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
> It's obvious that a large proportion of the existing python-dev'ers will > not participate in such a project, but why should we try to stop someone > else to work on it ? I propose to stop this discussion of theoretical projects, and only restart it when someone actually proposes to lead such a project. I might not personally stop anybody from doing such a project, but I surely will not support him. This thread was started by a specific proposal from Kristjan, and Kristjan got a specific suggestion on how to proceed (namely, wait for the Mercurial switchover, then publish his changes in a branch). So despite the more general subject (which I think is still mostly hypothetical), the real issue Kristjan raised has been resolved, AFAICT (although Kristjan has not yet voiced an opinion of whether he finds that resolution acceptable). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
Benjamin Peterson wrote: > 2010/10/29 M.-A. Lemburg : >> Brett Cannon wrote: >>> 2010/10/28 Kristján Valur Jónsson : I'm not sure what I'm actually proposing. But I certainly wasn't thinking of a new "fork" of python. And not a new version 2.8 that gets all new 3.x features backported. I'm more thinking of a place where usability improvements, C API improvements, performance improvements, Library improvments, can go. >>> >>> It's called a fork. I realize you are trying to avoid that "dirty" >>> word, Kristján, and I appreciate it, but you are describing a fork. >>> Python 2.7 is the last sanctioned version of the Python 2.x series, >>> period. Any non-bugfix changes will not go in there as policy >>> dictates. And with there being no way Python 2.8 will happen (I know >>> we as a group have said "slim chance" since Python 3.0 came out, >>> uptake of Python 3 is such I am willing to personally say "never" for >>> a python-dev sanctioned Python 2.8), that means it will take a fork, >>> whether it be internal to CCP or public somewhere, it will still be a >>> fork. >>> >>> And as everyone has said so far (and with which I agree), that's fine. >>> As long as it is not called Python 2.8 -- EVE-Python 2.8 or some Monty >>> Python reference -- then that's fine. >> >> I don't see why we should not welcome a team of new developers who want >> to continue working on the 2.x series. > > He's not saying we shouldn't welcome them; we just don't want to it > attached to python-dev. That new team could be part of python-dev, couldn't it ? Not necessarily the mailing list, but the team of Python developers. Much like the (new) py3k developers joined in when that project was kicked off. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 29 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Misc/python-mode.el (was Re: r85838 - python/branches/py3k/.gitignore)
On Oct 27, 2010, at 09:19 AM, Brett Cannon wrote: >In the name of completeness for people not aware of the issue, >http://bugs.python.org/issue9893 discusses actually removing these >files in preference to files maintained by others. If Misc/Vim were to >be dropped we could place a text file much like Barry is planning to >do for Emacs and point to the files Antoine is recommending. The Emacs changes are committed now in py3k, release31-maint, and release27-maint. Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
"Martin v. Löwis" wrote: >> It's obvious that a large proportion of the existing python-dev'ers will >> not participate in such a project, but why should we try to stop someone >> else to work on it ? > > I propose to stop this discussion of theoretical projects, and only > restart it when someone actually proposes to lead such a project. Fair enough. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 29 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
2010/10/29 M.-A. Lemburg : > Benjamin Peterson wrote: >> He's not saying we shouldn't welcome them; we just don't want to it >> attached to python-dev. > > That new team could be part of python-dev, couldn't it ? Not necessarily > the mailing list, but the team of Python developers. Much like the > (new) py3k developers joined in when that project was kicked off. Perhaps, but it would debatable how much infrastructure (ie buildbots, tracker) would be available to them. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
On Fri, 29 Oct 2010 02:55:55 -0400, Glyph Lefkowitz wrote: > I'm perfectly willing to admit that I'm still too pessimistic about this > and I could be wrong. But given the relatively minimal amount of effort > required to let 2.x bugs continue to get fixed under the aegis of > Python.org rather than going through the painful negotiation process of > figuring out where else to host it (and thereby potentially losing a > bunch of maintenance that would not otherwise happen), it seems > foolhardy to insist that those of us who think 2.x is going to > necessitate another release must necessarily be wrong. Your argument was interesting, but you conclude by talking only about bugs. We are continuing to bugfix 2.x in the form of 2.7 bugfix releases. If at the end of the five years the 2.x user community is large enough that additional *bugfix* releases of 2.7 are worth the effort, we will, I'm sure, continue to produce them. What *new features* are needed in 2.x? I think the effort required to set up and maintain a fork is a good measure of whether or not such features are *valuable enough* to be worth doing. If they are, someone will do it. If notnot. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/
On Oct 27, 2010, at 10:34 AM, R. David Murray wrote: >To put your mind at ease, Barry, I'd not want to do that either :) Phew! But I wasn't worried, 'cause I know you're not insane. (Though the fact that you've effectively inherited the email package does bring that into question. :) >But by (IMO good) design Generator, FeedParser, and Message are all >supposed to be independent (use only each other's public APIs). And >Header can be (and is, I think) used without the other pieces of email, >as is true for other of the helper modules (base64mime, quoprimime, etc). Agreed. >On the other hand, I have no clue why 'iterators.py' exists :) They're there for some corner use cases, but they do tend to be helpful. body_line_iterator() is probably the one I've used the most. The iterators are intended to be used independently. >The one that bugs me most, though, is MIME. Combining all the mime >stuff into one file seems like it would be a big win (not that it's >possible, now). What is the benefit of email.mime.text.MIMEText over >email.mime.MIMEText, when each of the files in the mime package consists >of a single subclass? I think you're right that the extra level of module path is probably unnecessary. I'm not sure that means all the .py files in email/mime should be combined though. OTOH, `wc -l Lib/email/mime/*.py` is only 314 lines so I'm happy to defer to you on that. >So, to clarify, like Raymond I'm not saying that packages are always bad. >I'm just saying that packages are also not always good; and, further, >that the number of lines of code in a file should, IMO, have nothing to >do with the decision as to whether or not to create a package. +1 -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change to logging Formatters: support for alternative format styles
On Oct 25, 2010, at 02:28 PM, Vinay Sajip wrote:
>I've just checked in a change to logging into the py3k branch (r85835),
>including doc changes and tests, for providing slightly more flexibility in
>alternative format styles for logging.
>
>Basically, Formatter.__init__ gets an extra optional keyword arg style='%' (default), '{' or '$'>. This is then used to merge the format string with
>the LogRecord: either fmt % record.__dict__, or fmt.format(**record.dict), or
>string.Template(fmt).substitute(**record.dict). Backward compatibility is
>maintained (unless I've missed something).
This sounds like a reasonable solution that provides the flexibility we want,
while maintaining backward compatibility. Thanks!
I haven't played with it yet, but do you think it makes sense to add a 'style'
keyword argument to basicConfig()? That would make it pretty easy to get the
formatting style you want without having to explicitly instantiate a
Formatter, at least for simple logging clients.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change to logging Formatters: support for alternative format styles
On Tue, Oct 26, 2010 at 6:15 AM, Nick Coghlan wrote: > On Tue, Oct 26, 2010 at 9:08 PM, Nick Coghlan wrote: >> On Tue, Oct 26, 2010 at 12:28 AM, Vinay Sajip >> wrote: >>> Comments welcome. Assuming there are no strong objections asking for >>> reversion >>> of this change, I'll publicise to the wider community in a few days. >> >> It strikes me as a solid, pragmatic solution to a thorny problem. >> >> Looking at your checkin though, I wonder if it might be worth >> implementing some little formatting style classes to get rid of the >> if/elif chains from the Formatter code. Something like: > > Some syntax highlighting may make that wall-o'-code a little easier to > read: http://pastebin.com/SG0Qr3r5 > FWIW +1 -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change to logging Formatters: support for alternative format styles
On Fri, Oct 29, 2010 at 10:07 AM, Barry Warsaw wrote:
> On Oct 25, 2010, at 02:28 PM, Vinay Sajip wrote:
>
>>I've just checked in a change to logging into the py3k branch (r85835),
>>including doc changes and tests, for providing slightly more flexibility in
>>alternative format styles for logging.
>>
>>Basically, Formatter.__init__ gets an extra optional keyword arg style=>'%' (default), '{' or '$'>. This is then used to merge the format string with
>>the LogRecord: either fmt % record.__dict__, or fmt.format(**record.dict), or
>>string.Template(fmt).substitute(**record.dict). Backward compatibility is
>>maintained (unless I've missed something).
>
> This sounds like a reasonable solution that provides the flexibility we want,
> while maintaining backward compatibility. Thanks!
>
> I haven't played with it yet, but do you think it makes sense to add a 'style'
> keyword argument to basicConfig()? That would make it pretty easy to get the
> formatting style you want without having to explicitly instantiate a
> Formatter, at least for simple logging clients.
>
Since this may be considered as a little sophisticated, I'd rather
prefer these new classes to be added to configuration sections using
fileConfig (and default behavior if missing), and still leave
`basicConfig` unchanged (i.e. *basic*) .
PS: Good work !
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2010-10-22 - 2010-10-29)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues stats:
open2496 (+41)
closed 19519 (+56)
total 22015 (+61)
Open issues with patches: 1038
Issues opened (41)
==
#9935: Faster pickling of instances
http://bugs.python.org/issue9935 reopened by pitrou
#10173: Don't pickle TestCase instances in test_multiprocessing
http://bugs.python.org/issue10173 opened by pitrou
#10174: multiprocessing expects sys.stdout to have a fileno/close meth
http://bugs.python.org/issue10174 opened by ikanobori
#10175: vs version for win32 compilation of extension modules is undoc
http://bugs.python.org/issue10175 opened by tfogal
#10177: PyUnicode_AsWideCharString and PyMem_Free
http://bugs.python.org/issue10177 opened by ocean-city
#10179: os.stat fails on mapped network drive
http://bugs.python.org/issue10179 opened by pitrou
#10180: File objects should not pickleable
http://bugs.python.org/issue10180 opened by pitrou
#10181: get_shape0 in memoryobject.c not checked for error return
http://bugs.python.org/issue10181 opened by rupole
#10182: match_start truncates large values
http://bugs.python.org/issue10182 opened by loewis
#10183: test_concurrent_futures failure on Windows
http://bugs.python.org/issue10183 opened by pitrou
#10184: tarfile touches directories twice
http://bugs.python.org/issue10184 opened by loewis
#10188: tempfile.TemporaryDirectory may throw errors at shutdown
http://bugs.python.org/issue10188 opened by ncoghlan
#10189: SyntaxError: no binding for nonlocal doesn't contain a useful
http://bugs.python.org/issue10189 opened by alex
#10190: Can argparse._AttributeHolder._get_kwargs become a public API?
http://bugs.python.org/issue10190 opened by dsuch
#10191: scripts files are not RECORDed.
http://bugs.python.org/issue10191 opened by Atsushi.Odagiri
#10195: Memory allocation fault-injection?
http://bugs.python.org/issue10195 opened by dmalcolm
#10196: distutils.get_python_lib() returns /usr/local/python3/dist-pac
http://bugs.python.org/issue10196 opened by Bruce.Sherwood
#10197: subprocess.getoutput fails on win32
http://bugs.python.org/issue10197 opened by jldm
#10199: Move Demo/turtle under Lib/
http://bugs.python.org/issue10199 opened by belopolsky
#10202: ftplib doesn't check close status after sending file
http://bugs.python.org/issue10202 opened by nagle
#10203: sqlite3.Row doesn't support sequence protocol
http://bugs.python.org/issue10203 opened by pfalcon
#10205: Can't have two tags with the same QName
http://bugs.python.org/issue10205 opened by bersace
#10206: python program starting with unmatched quote spews spaces to s
http://bugs.python.org/issue10206 opened by r.david.murray
#10211: BufferObject doesn't support new buffer interface
http://bugs.python.org/issue10211 opened by krisvale
#10212: struct.unpack and cStringIO.StringIO don't support new buffer
http://bugs.python.org/issue10212 opened by krisvale
#10213: tests shouldn't fail with unset timezone
http://bugs.python.org/issue10213 opened by djc
#10217: python-2.7.amd64.msi install fails
http://bugs.python.org/issue10217 opened by Manfred.Bartz
#10219: BufferedReader.read1 does not check for closed file
http://bugs.python.org/issue10219 opened by amaury.forgeotdarc
#10220: Make generator state easier to introspect
http://bugs.python.org/issue10220 opened by ncoghlan
#10221: {}.pop('a') raises non-standard KeyError exception
http://bugs.python.org/issue10221 opened by djc
#10224: Build 3.x documentation using python3.x
http://bugs.python.org/issue10224 opened by belopolsky
#10225: Fix doctest runable examples in python manual
http://bugs.python.org/issue10225 opened by belopolsky
#10226: urlparse example is wrong
http://bugs.python.org/issue10226 opened by belopolsky
#10227: Improve performance of MemoryView slicing
http://bugs.python.org/issue10227 opened by krisvale
#10228: Refleak run of test_dbm fails when several dbm modules are ava
http://bugs.python.org/issue10228 opened by pitrou
#10229: Refleak run of test_gettext fails
http://bugs.python.org/issue10229 opened by pitrou
#10230: test_tarfile failure (test_extractall) on AMD64 debian paralle
http://bugs.python.org/issue10230 opened by haypo
#10231: SimpleHTTPRequestHandler directory bugs
http://bugs.python.org/issue10231 opened by hfuru
#10232: Tkinter issues with Scrollbar and custom widget list
http://bugs.python.org/issue10232 opened by Robert.Lerche
#10233: fix test_tarfile ResourceWarnings
http://bugs.python.org/issue10233 opened by pitrou
#1610654: cgi.py multipart/form-data
http://bugs.python.org/issue1610654 reopened by r.david.murray
Most recent 15 issues with no replies (15)
==
#10233: fix test_tarfile ResourceWarnings
http://bugs.python.org/issue10233
#10232: Tkinter issues
Re: [Python-Dev] Continuing 2.x
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/29/2010 10:21 AM, Benjamin Peterson wrote: > 2010/10/29 M.-A. Lemburg : >> Benjamin Peterson wrote: >>> He's not saying we shouldn't welcome them; we just don't want to it >>> attached to python-dev. >> >> That new team could be part of python-dev, couldn't it ? Not necessarily >> the mailing list, but the team of Python developers. Much like the >> (new) py3k developers joined in when that project was kicked off. > > Perhaps, but it would debatable how much infrastructure (ie buildbots, > tracker) would be available to them. "Infrastructure" sounds to me like code for "money". How much of the PSF's money, for instance, comes from organizations whose primary interest is still Python2? How many of them are only or principally only interested in Python3? Then again, how much of the PSF's budget goes toward infrastructure? (I honestly don't know the answers to any of these questions). For "donated" infrastructure, surely the individuals providing CPU / bandwidth / diskspace make that call, and not python-dev. If a new retro-fork development community emerges, its members will include folks who have a vested interest in continuing Python 2.x development, and hence can donate (or recruit) such in-kind contributions. Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzK9LEACgkQ+gerLs4ltQ5obQCdEaSgkZ+vG8RlzCHQTzhLEyCb jkYAn00pBS0aPZ0AS05hKqbP3/TpA4pb =AHme -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
On 02:51 am, [email protected] wrote: 2010/10/28 Kristj�n Valur J�nsson : Hi all. This has been a lively discussion. My desire to keep 2.x alive in some sense is my own and I don't know if anyone shares it but as a member of this community I think I'm allowed to voice it. So, just to clarify my particular position, let me explain where all this comes from. [snip] And as everyone has said so far (and with which I agree), that's fine. As long as it is not called Python 2.8 -- EVE-Python 2.8 or some Monty Python reference -- then that's fine. And as pointed out by folks, once Hg kicks in and we have user repos you can even host it on hg.python.org yourself to give it some semblance of authority if you want. In case anyone was discouraged by the idea that a 2.x continuation would not be allowed to bear the name "Python" as Brett suggests here, I want to make a clarification. Brett is speaking for himself here (and he never claimed otherwise!). However, decisions about where to allow the use of the "Python" trademark are made by the Python Software Foundation. The PSF has not decided to reject any request by a 2.x continuation project to use the name "Python". Of course, this does not mean they would necessarily allow such a use. I just wanted to point out that they have not categorically rejected it, as one might be tempted to infer from Brett's message. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
> "Infrastructure" sounds to me like code for "money". No, it's rather "volunteer time". Of course, people keep proposing that this should be replaced by hired time that gets paid from donations, but all such proposals so far got stuck at implementation details (i.e. it's actual work that nobody has done). > How much of the > PSF's money, for instance, comes from organizations whose primary > interest is still Python2? How many of them are only or principally > only interested in Python3? Then again, how much of the PSF's budget > goes toward infrastructure? The first two questions are difficult to answer: the PSF doesn't maintain records of what Python versions are of primary interest to sponsor members. A significant portion of the donations comes from the conference surplus (being saved for the also-likely risk of a massive conference loss); in this case, it's even difficult to identify the donors (as you can't really attribute the surplus to being from, say, attendee fees, as opposed to conference sponsors). As for the budget that goes into infrastructure: you'll find the details in the treasurer reports, but it is comparatively minor and goes primarily into hardware purchases. Connectivity and colocation is donated by companies who may not have an actual interest in Python at all (e.g. XS4ALL, which do this out of a general support for free software and in positive recollection of their former employee Thomas Wouters). > For "donated" infrastructure, surely the individuals providing CPU / > bandwidth / diskspace make that call, and not python-dev. Yes, and I have already stated my opinion. Other pydotorg'ers will surely voice their opinion when they get asked to help. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
On Fri, 29 Oct 2010 16:41:19 - [email protected] wrote: > > Brett is speaking for himself here (and he never claimed otherwise!). > However, decisions about where to allow the use of the "Python" > trademark are made by the Python Software Foundation. The point is not to allow the use of a trademark ("EVE-Python" is already an use of the trademark, as are "IronPython", "Cython", "VPython", etc.), it is to respect the original project and to keep things clear. Even if there were no trademark, I think it would be wrong for a separate project to adopt the same name without agreement from the original group of contributors. I have never seen a fork which didn't change the name of the project. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
On Fri, Oct 29, 2010 at 06:57:54PM +0200, "Martin v. L?wis" wrote: > > "Infrastructure" sounds to me like code for "money". > > No, it's rather "volunteer time". Of course, people keep proposing > that this should be replaced by hired time that gets paid from > donations, but all such proposals so far got stuck at implementation > details (i.e. it's actual work that nobody has done). > > > How much of the > > PSF's money, for instance, comes from organizations whose primary > > interest is still Python2? How many of them are only or principally > > only interested in Python3? Then again, how much of the PSF's budget > > goes toward infrastructure? > > The first two questions are difficult to answer: the PSF doesn't > maintain records of what Python versions are of primary interest > to sponsor members. A significant portion of the donations comes > from the conference surplus (being saved for the also-likely risk > of a massive conference loss); in this case, it's even difficult to > identify the donors (as you can't really attribute the surplus to > being from, say, attendee fees, as opposed to conference sponsors). > > As for the budget that goes into infrastructure: you'll find the details > in the treasurer reports, but it is comparatively minor and goes > primarily into hardware purchases. Connectivity and colocation is > donated by companies who may not have an actual interest in Python > at all (e.g. XS4ALL, which do this out of a general support for > free software and in positive recollection of their former employee > Thomas Wouters). I'd just like to add my 2c that AFAICT the volunteer effort that goes into Python, and in particular into python-dev and the infrastructure foo, absolutely *dwarfs* all other aspects of "official" Python and PSF (including $$ in all forms). So, good job, -dev guys! But they're already pretty overwhelmed. Independent of talk, unless there's a proposal to continue 2.x that actually involves someone *new* stepping up to put in hugely substantial and ridiculously large amounts of seriously expert time, I don't see the point of talking about it. cheers, --titus p.s. I would be happy to enter into discussions on how to clone Martin and others, though. I just need some epithelial cells, I think. And about $20 bn dollars, and relocation to Israel (which I think has the best combination of tech and human use guidelines for cloning). Martin's permission is not *strictly* necessary but should probably be obtained, too. p.p.s. The PSF isn't foolish enough to let me speak for them, in case anyone is wondering. -- C. Titus Brown, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
On Fri, 2010-10-29 at 09:11 +0200, Antoine Pitrou wrote: > On Fri, 29 Oct 2010 02:55:55 -0400 > Glyph Lefkowitz wrote: > > > > Let's say that 20% of the code on PyPI is just junk; > > it's unfair to expect 100% of all code ever to get ported. But, > still: > > with this back-of-the-envelope estimate of the rate of porting, it > will > > take over 50 years before a decisive majority of Python code is on > > Python 3. > > Well, no. A decisive majority would be much smaller than that. There > are probably between 2% and 5% of the CheeseShop entries which are > widely used dependencies. When these 2 to 5% all get ported, you have > a > decisive majority. > > Yes, perhaps more than 50% of 2.x code will never get ported. But, > perhaps more than 50% of 1.5.2 code never got upgraded either. That > doesn't make it any decisive; just dead (or pining for security fixes > in some old rusty "RedHat Enterprise Linux" server, if you prefer). Ouch! Having spent much of the last week doublechecking fixes for CVEs in the builds of python 2.2, 2.3 and 2.4 in the various older RHEL releases, that cuts deep :) Red Hat's security team monitors vulnerabilities in Python, and we do continue to support these releases in the context of our products, even though they're no longer supported by the wider Python development community. As with the the security work done by python-dev on the more up-to-date Python releases, it's tedious and painstaking work (we do have customers paying us to do it, though) If you have concerns about specific security flaws that may affect the older releases of python that are no longer supported by python.org but are within a product supported by Red Hat, please email [email protected] See: https://www.redhat.com/security/team/contact/ for more information. Hope this is helpful Dave ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change to logging Formatters: support for alternative format styles
On 10/26/10 7:08 AM, Nick Coghlan wrote: On Tue, Oct 26, 2010 at 12:28 AM, Vinay Sajip wrote: Comments welcome. Assuming there are no strong objections asking for reversion of this change, I'll publicise to the wider community in a few days. It strikes me as a solid, pragmatic solution to a thorny problem. I keep meaning to review this but haven't had time. One thing I want to look at specifically is the ability to put the time formatting into the str.format version of the format string. Now that the time format specifier can be included in the format string, it's no longer necessary to have the asctime inspection hack that's currently used in order to avoid formatting the time. It would be good if we could remove the formatTime logic for str.format, although I'm not sure how practical it is. I suspect it's too baked-in to the design, but I'm hopeful. I'm +1 on the overall concept of allow the other string formatters. -- Eric. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
On Thu, Oct 28, 2010 at 11:55 PM, Glyph Lefkowitz wrote: > On Oct 28, 2010, at 10:51 PM, Brett Cannon wrote: > > I think people need to stop viewing the difference between Python 2.7 > and Python 3.2 as this crazy shift and view it from python-dev's > perspective; it should be viewed one follows from the other at this > point. You can view it as Python 3.2 is the next version after Python > 2.7 just like 2.7 followed to 2.6, which makes the policies we follow > for releases make total sense and negates this discussion. It just so > happens people don't plan to switch to the newest release immediately > as the backward-incompatible changes are more involved than what > people are used to from past releases. > > Brett, with all due respect, this is not a reasonable position. You are > making it sound like the popular view of 3.2 is a "crazy shift" is based on > a personal dislike of python-dev or something. The fact is that the amount > of effort required to port to 3.2 is extreme compared to previous upgrades, > and most people still aren't willing to deal with it. It is a crazy shift. > Let's take PyPI numbers as a proxy. There are ~8000 packages with a > "Programming Language::Python" classifier. There are ~250 with "Programming > Langauge::Python::3". Roughly speaking, we can say that is 3% of Python > code which has been ported so far. Python 3.0 was released at the end of > 2008, so people have had roughly 2 years to port, which comes up with 1.5% > per year. > Let's say that 20% of the code on PyPI is just junk; it's unfair to expect > 100% of all code ever to get ported. But, still: with this > back-of-the-envelope estimate of the rate of porting, it will take over 50 > years before a decisive majority of Python code is on Python 3. > By contrast, there are 536 packages with ::2.6, and 177 with ::2.7. (Trying > to compare apples to apples here, since I assume the '2' tag is much more > lightly used than '3' to identify supported versions; I figure someone > likely to tag one micro-version would also tag the other.) Just my two cents: First off, unless you have a lot of information I don't, there's no reason at all to believe that Python3's adoption will be linear- if anything it seems very likely to be a power law curve, just like the adoption trends we see for other software projects. Secondly, speaking of power law curves, not all packages on PyPI are equally important as measured by downloads. If even the top 2% of most downloaded projects on PyPI got ported to Python3 it would represent a majority of downloads, and that pattern seems consistent with what you see in other software repositories. The net result of this is that even if you're right and the growth is linear AND the 1.5% statistic is accurate- again, I doubt it- it is conceivable that within two years an overwhelming majority of downloads of Python software could be of projects with full Python3 support. From a user perspective that's fairly close to indistinguishable from a community-wide transition to Python3. Thirdly, only counting PyPI is probably not a very good way to measure popularity in the wider community, as PyPI's overall usage is fairly small. Just to name a few examples, sqlalchemy had been pulled just 2,000 times from PyPI, but 86,000 times from Ubuntu's repo, pyparsing had just 295 downloads on PyPI but 62,000 from Ubuntu, etc. With a few exceptions- especially modules that pride themselves on being pure Python- this is pretty indicative of the general relationship between PyPI and these other repositories. I don't know how the adoption rate figures would look if we took those into account, but if you want to portray the trend accurately that's something you're likely to have to do. So, to cut down a long-winded and overly pedantic response: I'm pretty sure that you're not going to get accurate estimates out of that methodology, assuming that accurate results are what you're after. Geremy Condra ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
On Fri, Oct 29, 2010 at 11:12 AM, geremy condra wrote: > On Thu, Oct 28, 2010 at 11:55 PM, Glyph Lefkowitz > wrote: >> On Oct 28, 2010, at 10:51 PM, Brett Cannon wrote: [snip] > First off, unless you have a lot of information I don't, there's no > reason at all to believe that Python3's adoption will be linear- if > anything it seems very likely to be a power law curve, just like the > adoption trends we see for other software projects. [snip] Just a correction, I'm predicting that Python3's adoption will be exponential and that it's popularity relative to other software projects will move up according to a power law curve, not that it's overall adoption will be power law. Thanks for pointing this out, Titus. Geremy Condra ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r85934 - in python/branches/py3k: Misc/NEWS Modules/socketmodule.c
2010/10/29 martin.v.loewis :
> Author: martin.v.loewis
> Date: Fri Oct 29 20:20:08 2010
> New Revision: 85934
>
> Log:
> Issue #9377: Use Unicode API for gethostname on Windows.
>
> Modified:
> python/branches/py3k/Misc/NEWS
> python/branches/py3k/Modules/socketmodule.c
>
> Modified: python/branches/py3k/Misc/NEWS
> ==
> --- python/branches/py3k/Misc/NEWS (original)
> +++ python/branches/py3k/Misc/NEWS Fri Oct 29 20:20:08 2010
> @@ -160,6 +160,8 @@
> Extensions
> --
>
> +- Issue #9377: Use Unicode API for gethostname on Windows.
> +
> - Issue #10143: Update "os.pathconf" values.
>
> - Issue #6518: Support context manager protcol for ossaudiodev types.
>
> Modified: python/branches/py3k/Modules/socketmodule.c
> ==
> --- python/branches/py3k/Modules/socketmodule.c (original)
> +++ python/branches/py3k/Modules/socketmodule.c Fri Oct 29 20:20:08 2010
> @@ -3093,6 +3093,27 @@
> static PyObject *
> socket_gethostname(PyObject *self, PyObject *unused)
> {
> +#ifdef MS_WINDOWS
> +/* Don't use winsock's gethostname, as this returns the ANSI
> + version of the hostname, whereas we need a Unicode string.
> + Otherwise, gethostname apparently also returns the DNS name. */
> +wchar_t buf[MAX_COMPUTERNAME_LENGTH];
> +DWORD size = sizeof(buf);
> +if (!GetComputerNameExW(ComputerNamePhysicalDnsHostname, buf, &size)) {
> +if (GetLastError() == ERROR_MORE_DATA) {
> +/* MSDN says this may occur "because DNS allows longer names */
> +PyObject *result = PyUnicode_FromUnicode(NULL, size);
> +if (!result)
> +return NULL;
> +if (GetComputerName(ComputerNamePhysicalDnsHostname,
> +PyUnicode_AS_UNICODE(result),
> +size+1))
> +return result;
A reference leak (of result) occurs here if GetComputerName fails again.
--
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
On Fri, Oct 29, 2010 at 11:12:28AM -0700, geremy condra wrote: > On Thu, Oct 28, 2010 at 11:55 PM, Glyph Lefkowitz > > Let's take PyPI numbers as a proxy. There are ~8000 packages with a > > "Programming Language::Python" classifier. There are ~250 with "Programming > > Langauge::Python::3". Roughly speaking, we can say that is 3% of Python > > code which has been ported so far. Python 3.0 was released at the end of > > 2008, so people have had roughly 2 years to port, which comes up with 1.5% > > per year. > Just my two cents: > Just one further informational note about using pypi in this way for statistics... In the porting work we've done within Fedora, I've noticed that a lot of packages are python3 ready or even officially support python3 but the language classifier on pypi does not reflect this. Here's just a few since I looked them up when working on the python porting wiki pages: http://pypi.python.org/pypi/Beaker/ http://pypi.python.org/pypi/pycairo http://pypi.python.org/pypi/docutils -Toshio pgphZAiUVGy6C.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
On Oct 28, 2010, at 10:59 PM, Stephen J. Turnbull wrote: > Mark's position is different. His words suggest that he thinks that > Python.org owes the users something, although if pressed I imagine > he'd present some argument that more users will lead to development of > a better language. I think the developers universally consider that > to be objectively false: Python 3 is a much better language, and is on > track to be a much better environment for development -- of itself and > of applications -- in 2013 than Python 2 could conceivably be. There is tension here. python-dev wants Python to succeed, and now Python == Python 3.x. That means end-of-lifing Python 2.x, for many reasons, not the least of which is that more Python 2.x releases are a disincentive for folks to move their projects to Python 3.x. However there are many many more users of Python 2.x than Python 3.x. Many may never upgrade for the life of these projects, because if it ain't broke, why fix it? It doesn't matter how much better Python 3 is than Python 2. It isn't better enough. I like Python 3, I am using it for my latest projects, but I am also keeping Python 2 compatibility. This incurs some overhead, and basically means I am still really only using Python 2 features. So in some respects, my Python 3.x support is only tacit, it works as well as for Python 2, but it's not taking advantage of Python 3 really. I haven't run into a situation yet where I really want to or have to use Python 3 exclusive features, but then again I'm not really learning to use Python 3 either, short of the new C api. In this regard the existence of Python 3 is a disadvantage, not an advantage for my new code, regardless of how much better a language or dev environment it may be. Of course I made the choice to support both 2 and 3, but it was largely informed by the fact that other dependancies for my projects currently only support Python 2 and I don't have the spare time to port them right now. So at least right now, for me, Python 3 is not helping make new projects easier, it is the contrary unfortunately. Yeah, I am getting older and the years are going by faster, but gosh 2013 still feels like a ways off. -Casey ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
On Oct 29, 2010, at 12:43 PM, Casey Duncan wrote: >I like Python 3, I am using it for my latest projects, but I am also keeping >Python 2 compatibility. This incurs some overhead, and basically means I am >still really only using Python 2 features. So in some respects, my Python 3.x >support is only tacit, it works as well as for Python 2, but it's not taking >advantage of Python 3 really. I haven't run into a situation yet where I >really want to or have to use Python 3 exclusive features, but then again I'm >not really learning to use Python 3 either, short of the new C api. One thing that *might* be interesting to explore for Python 3.3 would be something like `python3 --1` or some such switch that would help Python 2 code run more easily in Python 3. This might be a hook to 2to3 or other internal changes that help some of the trickier bits of writing cross-compatible code. I don't know what those things enabled by --1 would be. Some syntactic things might be fairly easy though largely inconsequential (e.g. print() -> print). It might be that large changes like bytes/string dwarfs syntactic sugar. I had a brief conversation with Michael Foord yesterday and he's writing code that works in 2.4 through 3.2, so for *some* code bases, it's tricky and ugly, but possible. IMHO, those are the kinds of directions we should be thinking about, to help existing code more easily make the jump to Python 3. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
On Fri, Oct 29, 2010 at 12:21 PM, Barry Warsaw wrote: > On Oct 29, 2010, at 12:43 PM, Casey Duncan wrote: > > >I like Python 3, I am using it for my latest projects, but I am also > keeping > >Python 2 compatibility. This incurs some overhead, and basically means I > am > >still really only using Python 2 features. So in some respects, my Python > 3.x > >support is only tacit, it works as well as for Python 2, but it's not > taking > >advantage of Python 3 really. I haven't run into a situation yet where I > >really want to or have to use Python 3 exclusive features, but then again > I'm > >not really learning to use Python 3 either, short of the new C api. > > One thing that *might* be interesting to explore for Python 3.3 would be > something like `python3 --1` or some such switch that would help Python 2 > code > run more easily in Python 3. This might be a hook to 2to3 or other > internal > changes that help some of the trickier bits of writing cross-compatible > code. > More useful IMHO would be things like "from __past__ import print_statement", still requiring some annotation of code to make it run, but less invasive than translating code itself. There's still major things you can't handle like that, but if something is syntactically acceptable in both Python 2 and 3 then it's a lot easier to apply simple conditionals around semantics. This would remove the need, for example, for people to use sys.exc_info() to avoid using "except Exception as e". -- Ian Bicking | http://blog.ianbicking.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
On 10/29/2010 9:42 AM, M.-A. Lemburg wrote: I don't see why we should not welcome a team of new developers who want to continue working on the 2.x series. Given the number of issues on the tracker, I think it would be great if there were some new 2.7-focused developers that would work on fixing 2.7-specific bugs and helping with fixes (including by backporting) to 2.7/3.x bugs. It's obvious that a large proportion of the existing python-dev'ers will not participate in such a project, but why should we try to stop someone else to work on it ? Where is such a team? It is a moot point until they show up. As to a possible successor to 2.7: this seems hardly worth discussing until 1) 2.7 has been out for at year and maybe more; 2) there actually are such new developers working on 2.7 maintenance; and 3) there actually is a proposal to respond to. If new features were limited to backports of features in 3.x, especially in the library, then I *personally* could see something being released as 'python 2.8'. I will be surprised it these preconditions come about. I suspect that most 2.7 users and most *nix distributions would be happy to have a stable increasingly de-bugged 2.7 be Python 2 for several years. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
Another quick thought. What would people think about regular timed releases if python 2.7? This is probably more a question for Benjamin but doing sonmight provide better predictability and "customer service" to our users. I might like to see monthly releases but even quarterly would probably be useful. Doing timed releases might also incentivize folks to fix more outstanding 2.7 bugs. Sent from my digital lollipop. On Oct 29, 2010, at 3:38 PM, Terry Reedy wrote: > On 10/29/2010 9:42 AM, M.-A. Lemburg wrote: > >> I don't see why we should not welcome a team of new developers who want >> to continue working on the 2.x series. > > Given the number of issues on the tracker, I think it would be great if there > were some new 2.7-focused developers that would work on fixing 2.7-specific > bugs and helping with fixes (including by backporting) to 2.7/3.x bugs. > >> It's obvious that a large proportion of the existing python-dev'ers will >> not participate in such a project, but why should we try to stop someone >> else to work on it ? > > Where is such a team? It is a moot point until they show up. > > As to a possible successor to 2.7: this seems hardly worth discussing until > 1) 2.7 has been out for at year and maybe more; 2) there actually are such > new developers working on 2.7 maintenance; and 3) there actually is a > proposal to respond to. If new features were limited to backports of features > in 3.x, especially in the library, then I *personally* could see something > being released as 'python 2.8'. > > I will be surprised it these preconditions come about. I suspect that most > 2.7 users and most *nix distributions would be happy to have a stable > increasingly de-bugged 2.7 be Python 2 for several years. > > -- > Terry Jan Reedy > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/barry%40python.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
On 10/29/2010 2:41 PM, Toshio Kuratomi wrote: On Fri, Oct 29, 2010 at 11:12:28AM -0700, geremy condra wrote: On Thu, Oct 28, 2010 at 11:55 PM, Glyph Lefkowitz Let's take PyPI numbers as a proxy. There are ~8000 packages with a "Programming Language::Python" classifier. There are ~250 with "Programming Langauge::Python::3". Roughly speaking, we can say that is 3% of Python code which has been ported so far. Python 3.0 was released at the end of 2008, so people have had roughly 2 years to port, which comes up with 1.5% per year. Just my two cents: Just one further informational note about using pypi in this way for statistics... In the porting work we've done within Fedora, I've noticed that a lot of packages are python3 ready or even officially support python3 but the language classifier on pypi does not reflect this. Here's just a few since I looked them up when working on the python porting wiki pages: http://pypi.python.org/pypi/Beaker/ http://pypi.python.org/pypi/pycairo http://pypi.python.org/pypi/docutils If you could (successfully) encourage the authors of such packages to update their PyPI classifiers, I and other Python 3 users would greatly appreciate it. That is aside from having better data for this and similar discussions. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
That's a much better idea! Sent from my digital lollipop. On Oct 29, 2010, at 3:31 PM, Ian Bicking wrote: > On Fri, Oct 29, 2010 at 12:21 PM, Barry Warsaw wrote: > On Oct 29, 2010, at 12:43 PM, Casey Duncan wrote: > > >I like Python 3, I am using it for my latest projects, but I am also keeping > >Python 2 compatibility. This incurs some overhead, and basically means I am > >still really only using Python 2 features. So in some respects, my Python 3.x > >support is only tacit, it works as well as for Python 2, but it's not taking > >advantage of Python 3 really. I haven't run into a situation yet where I > >really want to or have to use Python 3 exclusive features, but then again I'm > >not really learning to use Python 3 either, short of the new C api. > > One thing that *might* be interesting to explore for Python 3.3 would be > something like `python3 --1` or some such switch that would help Python 2 code > run more easily in Python 3. This might be a hook to 2to3 or other internal > changes that help some of the trickier bits of writing cross-compatible code. > > More useful IMHO would be things like "from __past__ import print_statement", > still requiring some annotation of code to make it run, but less invasive > than translating code itself. There's still major things you can't handle > like that, but if something is syntactically acceptable in both Python 2 and > 3 then it's a lot easier to apply simple conditionals around semantics. This > would remove the need, for example, for people to use sys.exc_info() to avoid > using "except Exception as e". > > -- > Ian Bicking | http://blog.ianbicking.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
2010/10/29 Barry Warsaw : > I had a brief conversation with Michael Foord yesterday and he's writing code > that works in 2.4 through 3.2, so for *some* code bases, it's tricky and ugly, > but possible. If the application does not involve a lot of I/O, 2.4 -> 3.2 support by using a unique code base is possible and not that ugly. At least, that's what happened with psutil: http://code.google.com/p/psutil/issues/detail?id=75&can=1&q=python%203&colspec=ID%20Summary%20Type%20Opsys%20Status%20Milestone%20Opened%20Owner%20Progress#c9 My personal choice is to encourage the same approach where possible. Regards, --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
On Fri, 29 Oct 2010 15:54:19 -0400 Barry Warsaw wrote: > Another quick thought. What would people think about regular timed releases > if python 2.7? > This is probably more a question for Benjamin but doing sonmight > provide better predictability and "customer service" to our users. I > might like to see monthly releases but even quarterly would probably > be useful. Doing timed releases might also incentivize folks to fix > more outstanding 2.7 bugs. Why would it only apply to 2.7? Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
It certainly doesn't have to. Sent from my digital lollipop. On Oct 29, 2010, at 4:06 PM, Antoine Pitrou wrote: > On Fri, 29 Oct 2010 15:54:19 -0400 > Barry Warsaw wrote: >> Another quick thought. What would people think about regular timed releases >> if python 2.7? >> This is probably more a question for Benjamin but doing sonmight >> provide better predictability and "customer service" to our users. I >> might like to see monthly releases but even quarterly would probably >> be useful. Doing timed releases might also incentivize folks to fix >> more outstanding 2.7 bugs. > > Why would it only apply to 2.7? > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/barry%40python.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
2010/10/29 Barry Warsaw : > Another quick thought. What would people think about regular timed releases > if python 2.7? This is probably more a question for Benjamin but doing > sonmight provide better predictability and "customer service" to our users. I > might like to see monthly releases but even quarterly would probably be > useful. Doing timed releases might also incentivize folks to fix more > outstanding 2.7 bugs. At the moment, I'm planning to do regular maintenance releases for 3.1 and 2.7 roughly every 6 months. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Regular scheduled releases (was: Continuing 2.x)
On Fri, Oct 29, 2010 at 21:54, Barry Warsaw wrote: > Another quick thought. What would people think about regular timed releases > if python 2.7? This is probably more a question for Benjamin but doing > sonmight provide better predictability and "customer service" to our users. I > might like to see monthly releases but even quarterly would probably be > useful. Doing timed releases might also incentivize folks to fix more > outstanding 2.7 bugs. I would really like to see a more regular and frequent release schedule. Most of my experience with this is with Mercurial, where we have a time-based schedule with a feature release every four months and a bugfix release at least every month (usually at the first of each month) and more often if we have bad regressions. It's nice because (a) release are practiced more and therefore become easier to do, (b) regressions can be fixed in a shorter timeframe. A predictable schedule is also just nice for all parties involved. In Gentoo, we actually started taking backports from the maintenance branches to fix issues (regressions) in our packages, but didn't work out so well. Obviously a random snapshot from SVN (even from a stable branch) isn't exercised as well as an actual release, so we ended up having some issues due to that. Also releasing packages with a version number that doesn't fully correspond to the tarball is less than ideal (we mitigated this somewhat by adding a date tag to the packages, but still). Here are the bugfix releases from the 2.6 branch: 2.6.1: 64 days 2.6.2: 131 days 2.6.3: 174 days 2.6.4: 23 days (critical regressions) 2.6.5: 145 days 2.6.6: 158 days That's an average of 4 (if you include .4) or 4.5 months (PEP 6 specifies 6 months, but some of the parts seem outdated). I think releasing each month might be a bit ambitious, but it would be great to drive down the release interval towards 2-3 months instead of 4-5. Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
Barry Warsaw wrote: > On Oct 29, 2010, at 12:43 PM, Casey Duncan wrote: > >> I like Python 3, I am using it for my latest projects, but I am also keeping >> Python 2 compatibility. This incurs some overhead, and basically means I am >> still really only using Python 2 features. So in some respects, my Python 3.x >> support is only tacit, it works as well as for Python 2, but it's not taking >> advantage of Python 3 really. I haven't run into a situation yet where I >> really want to or have to use Python 3 exclusive features, but then again I'm >> not really learning to use Python 3 either, short of the new C api. > > One thing that *might* be interesting to explore for Python 3.3 would be > something like `python3 --1` or some such switch that would help Python 2 code > run more easily in Python 3. This might be a hook to 2to3 or other internal > changes that help some of the trickier bits of writing cross-compatible code. > > I don't know what those things enabled by --1 would be. Some syntactic things > might be fairly easy though largely inconsequential (e.g. print() -> print). > It might be that large changes like bytes/string dwarfs syntactic sugar. I > had a brief conversation with Michael Foord yesterday and he's writing code > that works in 2.4 through 3.2, so for *some* code bases, it's tricky and ugly, > but possible. > > IMHO, those are the kinds of directions we should be thinking about, to help > existing code more easily make the jump to Python 3. +1 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 29 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
Am 29.10.2010 21:54, schrieb Barry Warsaw: > Another quick thought. What would people think about regular timed > releases if python 2.7? This is probably more a question for > Benjamin but doing sonmight provide better predictability and > "customer service" to our users. I might like to see monthly releases > but even quarterly would probably be useful. Doing timed releases > might also incentivize folks to fix more outstanding 2.7 bugs. Ah, timed releases :-) I know this is bike-shedding, but PY_MINOR_VERSION has never used two digits, so far. More seriously - I think that monthly releases would be a *dis-service* to users, and I base that on personal experience with both Bazaar, and TortoiseSVN. For less-than-daily users, the user experience will be that they should upgrade their installation *every* time they want to use it. People providing support will always ask "are you using the latest version", to which the answer will be "of course not, I am using an installation that is five weeks old". Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] closing files and sockets in a timely manner in the stdlib
For those of you who have not noticed, Antoine committed a patch that
raises a ResourceWarning under a pydebug build if a file or socket is
closed through garbage collection instead of being explicitly closed.
I have started to go through the test suite to fix as many of these
cases as possible, but it's time for me to stop. For those of you
interested in helping out, at the end of this email is a list of tests
which have some ResourceWarning raised. Some of them are probably
listed here because of some other module causing the problem.
Everything from test_mailbox and *up* I already tried to silence but
it the solution was non-obvious to me (or was very network-specific
which I don't have much experience with). from test_os *down* I have
not touched (although Antoine has gotten to some).
Just a little tip: if testMethod() comes up as the warning in unittest
it isn't unittest. =) Because the warning gets triggered at odd times
thanks to gc it doesn't always output a helpful line. Best thing is to
search for obvious things like "open(" or "socket(" to find things
that need a context manager if the line where the warning triggered
seems odd (both in the test and in the module being tested).
[ 92/349] test_distutils
[105/349] test_file
[108/349] test_fileio
[116/349] test_ftplib
[143/349] test_httplib
[144/349] test_httpservers
[154/349] test_io
[169/349] test_logging
[173/349] test_mailbox
[197/349] test_os
[214/349] test_pkgimport
[219/349] test_popen
[247/349] test_sax
[255/349] test_shutil
[260/349] test_smtplib
[263/349] test_socket
[267/349] test_ssl
[278/349] test_subprocess
[279/349] test_sunau
[289/349] test_tarfile
[291/349] test_telnetlib
[297/349] test_threading
[303/349] test_tokenize
[314/349] test_unicodedata
[320/349] test_urllib2_localnet
[328/349] test_uu
[343/349] test_xmlrpc
[345/349] test_zipfile
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
Antoine Pitrou wrote: Even if there were no trademark, I think it would be wrong for a separate project to adopt the same name without agreement from the original group of contributors. I have never seen a fork which didn't change the name of the project. +1 -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Cleaning-up the new unittest API
The API for the unittest module has grown fat (the documentation
is approaching 2,000 lines and 10,000 words like a small book).
I think we can improve learnability by focusing on the most
important parts of the API.
I would like to simplify and clean-up the API for the unittest module
by de-documenting assertSetEqual(), assertDictEqual(),
assertListEqual, and assertTupleEqual().
All of those methods are already called automatically by
assertEqual(), so those methods never need to be called directly.
Or, if you need to be more explicit about the type checking for
sequences, the assertSequenceEqual() method will suffice.
Either way, there's no need to expose the four type specific methods.
Besides de-documenting those four redundant methods,
I propose that assertItemsEqual() be deprecated just like
its brother assertSameElements(). I haven't found anyone
who accurately guesses what those methods entail based
on their method names ("items" usually implies key/value
pairs elsewhere in the language; nor is it clear whether order is
important, whether the elements need to be hashable or
orderable or just define equality tests, nor is is clear whether
duplicates cause the test to fail).
Given the purpose of the unittest module, it's important that
the reader have a crystal clear understanding of what a test
is doing. Their attention needs to be focused on the subject
of the test, not on questioning the semantics of the test method.
IMO, users are far better-off sticking with assertEqual() so they
can be specific about the nature of the test:
# hashable elements; ignore dups
assertEqual(set(a), set(b))
# orderable elements; dups matter, order doesn't
assertEqual(sorted(a), sorted(b))
# eq tested elements, dups matter, order matters
assertEqual(list(a), list(b))
# hashable keys, eq tested values
# ignore dups, ignore order
assertEqual(dict(a), dict(b))
These take just a few more characters than assertSameElements()
and assertItemsEqual(), but they are far more clear about their meaning.
You won't have to second guess what semantics are hidden
behind the abstraction.
There are a couple other problems with the new API but it is probably
too late to do anything about it.
* elsewhere in Python we spell comparison names with abbreviations
like eq, ne, lt, le, gt, ge.In unittest, those are spelled in an awkward,
not easily remembered manner: assertLessEqual(a, b), etc.
Fortunately, it's clear what the mean; however, it's not easy to guess
their spelling.
* the names for assertRegexpMatches() and assertNotRegexpMatches
are deeply misleading since they are implemented in terms of
re.search(), not re.match().
Raymond
P.S. I also looked ar assertDictContainsSubset(a,b). It is a bit
over-specialized, but at least it is crystal clear what is does
and it beats the awkward alternative using dict views:
assertLessEqual(a.items(), b.items())
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Regular scheduled releases (was: Continuing 2.x)
On Sat, Oct 30, 2010 at 7:39 AM, Dirkjan Ochtman wrote: > That's an average of 4 (if you include .4) or 4.5 months (PEP 6 > specifies 6 months, but some of the parts seem outdated). I think > releasing each month might be a bit ambitious, but it would be great > to drive down the release interval towards 2-3 months instead of 4-5. Ultimately, the frequency of releases comes down to the burden on the release manager and the folks that build the binary installers. Any given RM is usually only responsible for one or two branches, but the same two people (Martin and Ronald) typically build the Windows and Mac OS X binaries for all of them. So if you add 2.6 and 3.1 together, as well as the releases for 2.7 and 3.2 development, I think you'll find releases happening a lot more often than an average of 1 every 4 months. I suspect the most significant thing that needs to be done in making more regular bug fix releases possible is solid, reliable automated creation of Windows and Mac OS X binaries. We also need to consider the impact on downstream - switching to a new compiler or interpreter version generally has a much higher chance of breaking things than switching to a new version of almost any other software development tool. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cleaning-up the new unittest API
On 29/10/2010 23:14, Raymond Hettinger wrote:
The API for the unittest module has grown fat (the documentation
is approaching 2,000 lines and 10,000 words like a small book).
I think we can improve learnability by focusing on the most
important parts of the API.
I would like to simplify and clean-up the API for the unittest module
by de-documenting assertSetEqual(), assertDictEqual(),
assertListEqual, and assertTupleEqual().
All of those methods are already called automatically by
assertEqual(), so those methods never need to be called directly.
Or, if you need to be more explicit about the type checking for
sequences, the assertSequenceEqual() method will suffice.
Either way, there's no need to expose the four type specific methods.
I'm fine with dedocumenting these. These methods should not need to be
called directly.
Besides de-documenting those four redundant methods,
I propose that assertItemsEqual() be deprecated just like
its brother assertSameElements(). I haven't found anyone
who accurately guesses what those methods entail based
on their method names ("items" usually implies key/value
pairs elsewhere in the language; nor is it clear whether order is
important, whether the elements need to be hashable or
orderable or just define equality tests, nor is is clear whether
duplicates cause the test to fail).
Given the purpose of the unittest module, it's important that
the reader have a crystal clear understanding of what a test
is doing. Their attention needs to be focused on the subject
of the test, not on questioning the semantics of the test method.
assertItemsEqual compares two iterables and tests that they have the
same elements irrespective of order. A relatively straightforward
definition. Hopefully the docstring and documentation make this clear.
If the members are all of the same type then indeed comparing two sorted
lists is only slightly more typing. If the members are of different
types checking that the members are the same is a much harder problem in
Python 3, and this method can be very useful.
-1 for deprecating.
All the best,
Michael Foord
IMO, users are far better-off sticking with assertEqual() so they
can be specific about the nature of the test:
# hashable elements; ignore dups
assertEqual(set(a), set(b))
# orderable elements; dups matter, order doesn't
assertEqual(sorted(a), sorted(b))
# eq tested elements, dups matter, order matters
assertEqual(list(a), list(b))
# hashable keys, eq tested values
# ignore dups, ignore order
assertEqual(dict(a), dict(b))
These take just a few more characters than assertSameElements()
and assertItemsEqual(), but they are far more clear about their meaning.
You won't have to second guess what semantics are hidden
behind the abstraction.
There are a couple other problems with the new API but it is probably
too late to do anything about it.
* elsewhere in Python we spell comparison names with abbreviations
like eq, ne, lt, le, gt, ge.In unittest, those are spelled in
an awkward,
not easily remembered manner: assertLessEqual(a, b), etc.
Fortunately, it's clear what the mean; however, it's not easy to guess
their spelling.
* the names for assertRegexpMatches() and assertNotRegexpMatches
are deeply misleading since they are implemented in terms of
re.search(), not re.match().
Raymond
P.S. I also looked ar assertDictContainsSubset(a,b). It is a bit
over-specialized, but at least it is crystal clear what is does
and it beats the awkward alternative using dict views:
assertLessEqual(a.items(), b.items())
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
--
http://www.voidspace.org.uk/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cleaning-up the new unittest API
On 29/10/2010 23:29, Michael Foord wrote:
[snip...]
Besides de-documenting those four redundant methods,
I propose that assertItemsEqual() be deprecated just like
its brother assertSameElements(). I haven't found anyone
who accurately guesses what those methods entail based
on their method names ("items" usually implies key/value
pairs elsewhere in the language; nor is it clear whether order is
important, whether the elements need to be hashable or
orderable or just define equality tests, nor is is clear whether
duplicates cause the test to fail).
Given the purpose of the unittest module, it's important that
the reader have a crystal clear understanding of what a test
is doing. Their attention needs to be focused on the subject
of the test, not on questioning the semantics of the test method.
assertItemsEqual compares two iterables and tests that they have the
same elements irrespective of order. A relatively straightforward
definition. Hopefully the docstring and documentation make this clear.
If the members are all of the same type then indeed comparing two
sorted lists is only slightly more typing. If the members are of
different types checking that the members are the same is a much
harder problem in Python 3, and this method can be very useful.
Just to clarify. The following fails in Python 3:
sorted([3, 1, 2, None])
If you want to compare that two iterables containing heterogeneous types
have the same members then it is tricky to implement correctly and
assertItemsEqual does it for you.
I agree that the name is not ideal and would be happy to change the name
(deprecating the old name as it was released in 2.7). API churn is as
bad as API bloat, but at least changing the name is something only done
once.
All the best,
Michael
-1 for deprecating.
All the best,
Michael Foord
IMO, users are far better-off sticking with assertEqual() so they
can be specific about the nature of the test:
# hashable elements; ignore dups
assertEqual(set(a), set(b))
# orderable elements; dups matter, order doesn't
assertEqual(sorted(a), sorted(b))
# eq tested elements, dups matter, order matters
assertEqual(list(a), list(b))
# hashable keys, eq tested values
# ignore dups, ignore order
assertEqual(dict(a), dict(b))
These take just a few more characters than assertSameElements()
and assertItemsEqual(), but they are far more clear about their meaning.
You won't have to second guess what semantics are hidden
behind the abstraction.
There are a couple other problems with the new API but it is probably
too late to do anything about it.
* elsewhere in Python we spell comparison names with abbreviations
like eq, ne, lt, le, gt, ge.In unittest, those are spelled in
an awkward,
not easily remembered manner: assertLessEqual(a, b), etc.
Fortunately, it's clear what the mean; however, it's not easy to
guess
their spelling.
* the names for assertRegexpMatches() and assertNotRegexpMatches
are deeply misleading since they are implemented in terms of
re.search(), not re.match().
Raymond
P.S. I also looked ar assertDictContainsSubset(a,b). It is a bit
over-specialized, but at least it is crystal clear what is does
and it beats the awkward alternative using dict views:
assertLessEqual(a.items(), b.items())
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
--
http://www.voidspace.org.uk/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
--
http://www.voidspace.org.uk/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cleaning-up the new unittest API
On 29/10/2010 23:56, Michael Foord wrote:
On 29/10/2010 23:29, Michael Foord wrote:
[snip...]
Besides de-documenting those four redundant methods,
I propose that assertItemsEqual() be deprecated just like
its brother assertSameElements(). I haven't found anyone
who accurately guesses what those methods entail based
on their method names ("items" usually implies key/value
pairs elsewhere in the language; nor is it clear whether order is
important, whether the elements need to be hashable or
orderable or just define equality tests, nor is is clear whether
duplicates cause the test to fail).
Given the purpose of the unittest module, it's important that
the reader have a crystal clear understanding of what a test
is doing. Their attention needs to be focused on the subject
of the test, not on questioning the semantics of the test method.
assertItemsEqual compares two iterables and tests that they have the
same elements irrespective of order. A relatively straightforward
definition. Hopefully the docstring and documentation make this clear.
If the members are all of the same type then indeed comparing two
sorted lists is only slightly more typing. If the members are of
different types checking that the members are the same is a much
harder problem in Python 3, and this method can be very useful.
Just to clarify. The following fails in Python 3:
sorted([3, 1, 2, None])
If you want to compare that two iterables containing heterogeneous
types have the same members then it is tricky to implement correctly
and assertItemsEqual does it for you.
I agree that the name is not ideal and would be happy to change the
name (deprecating the old name as it was released in 2.7). API churn
is as bad as API bloat, but at least changing the name is something
only done once.
Sorry for the noise. Suggested alternative name:
assertElementsEqual
The docs need updating to make it clear that the method isn't just a
synonym for assertEqual(sorted(iter1), sorted(iter2)) and that it works
with unorderable types.
As for "assertLessEqual" and friends, I don't find those names
intuitive. In fact whilst typing this email I initially called the
method "assertLessThan".
For "assertRegexpMatches" I don't find it hard to understand (in natural
English it makes sense even if the standard terminology for regular
expressions is different). I would have preferred "assertRegex" though.
All the best,
Michael
All the best,
Michael
-1 for deprecating.
All the best,
Michael Foord
IMO, users are far better-off sticking with assertEqual() so they
can be specific about the nature of the test:
# hashable elements; ignore dups
assertEqual(set(a), set(b))
# orderable elements; dups matter, order doesn't
assertEqual(sorted(a), sorted(b))
# eq tested elements, dups matter, order matters
assertEqual(list(a), list(b))
# hashable keys, eq tested values
# ignore dups, ignore order
assertEqual(dict(a), dict(b))
These take just a few more characters than assertSameElements()
and assertItemsEqual(), but they are far more clear about their
meaning.
You won't have to second guess what semantics are hidden
behind the abstraction.
There are a couple other problems with the new API but it is probably
too late to do anything about it.
* elsewhere in Python we spell comparison names with abbreviations
like eq, ne, lt, le, gt, ge.In unittest, those are spelled in
an awkward,
not easily remembered manner: assertLessEqual(a, b), etc.
Fortunately, it's clear what the mean; however, it's not easy to
guess
their spelling.
* the names for assertRegexpMatches() and assertNotRegexpMatches
are deeply misleading since they are implemented in terms of
re.search(), not re.match().
Raymond
P.S. I also looked ar assertDictContainsSubset(a,b). It is a bit
over-specialized, but at least it is crystal clear what is does
and it beats the awkward alternative using dict views:
assertLessEqual(a.items(), b.items())
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
--
http://www.voidspace.org.uk/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
--
http://www.voidspace.org.uk/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
--
http://www.voidspace.org.uk/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Un
Re: [Python-Dev] Cleaning-up the new unittest API
On Oct 29, 2010, at 9:11 PM, Michael Foord wrote: >> Just to clarify. The following fails in Python 3: >> >> sorted([3, 1, 2, None]) >> >> If you want to compare that two iterables containing heterogeneous types >> have the same members then it is tricky to implement correctly and >> assertItemsEqual does it for you. >> >> I agree that the name is not ideal and would be happy to change the name >> (deprecating the old name as it was released in 2.7). API churn is as bad as >> API bloat, but at least changing the name is something only done once. > > Sorry for the noise. Suggested alternative name: > > assertElementsEqual > > The docs need updating to make it clear that the method isn't just a synonym > for assertEqual(sorted(iter1), sorted(iter2)) and that it works with > unorderable types. I looked at this again and think we should just remove assertItemsEqual() from Py3.2 and dedocument it in Py2.7. It is listed as being new in 3.2 so nothing is lost. A new name like assertElementsEqual is an improvement because it doesn't suggest something like assertEqual(d.items(), d.items()), but it falls short in describing its key features: * the method doesn't care about order * it does care about duplicates * it don't need hashability * it can handle sequences of non-comparable types Also, I think the O(n**2) behavior is unexpected. There is a O(n log n) fast-path but it has a bug and needs to be removed. See issue 10242. The sole benefit over the more explicit variants like assertEqual(set(a), set(b)) and assertEqual(sorted(a), sorted(b)) is that it handles a somewhat rare corner case where neither of those work (unordered comparison of non-compable types when you do care about duplicates). That particular case doesn't come-up much and isn't suggested by either the current name or its proposed replacement. FWIW, I checked-out some other unittest suites in other languages and did not find an equivalent. That strongly suggests this is YAGNI and it shouldn't be added in Py3.2.There needs to be more evidence of need before putting this in. And if it goes in, it needs a really good name that tells what operations are hidden behind the abstraction. When reading test assertion, it is vital that the reader understand exactly what is being tested. It's an API fail if a reader guesses that assertElementsEqual(a,b) means list(a)==list(b); the test will pass unintentionally. See: http://www.phpunit.de/manual/3.4/en/api.html http://kentbeck.github.com/junit/javadoc/latest/ Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cleaning-up the new unittest API
Raymond Hettinger wrote: The API for the unittest module has grown fat (the documentation is approaching 2,000 lines and 10,000 words like a small book). I think we can improve learnability by focusing on the most important parts of the API. I would like to simplify and clean-up the API for the unittest module by de-documenting assertSetEqual(), assertDictEqual(), assertListEqual, and assertTupleEqual(). While you're at it, what do you think of assertAlmostEqual? Is there a use-case for it as it exists now? As I see it, it suffers from a number of problems: (1) Comparing floats for equality to some number of decimal places is rarely (never?) the right way to do it. Comparison to some number of significant figures would be better. Specifying an absolute or relative error would be better still. (2) This leads people to write the wrong test, because assertAlmostEqual exists and is easy to use, while the right test is tricky and requires better understanding of floating point issues. Example: I recently wrote tests using assertAlmostEqual where I specified places=12, because my code should have been accurate to 12 significant figures. Worked fine for small floating point, but when I started testing values of the order of 1, my tests started failing, because although it was correct to > 12 significant figures, five of those figures were not decimal places. (3) In the rare case that mere rounding is the right way to compare for approximate equality, assertAlmostEqual doesn't save you much: a handful of characters, that's about all. self.assertAlmostEqual(x, y, places=n) vs. self.assertEqual(round(x, n), round(y, n)) (Specifying the number of decimal places is keyword-only in 3.1. To me, that seems to be a gratuitous change from 2.x, where it could be specified as a positional argument.) -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
