Re: [Python-Dev] Encouraging developers
On Tuesday 06 March 2007 5:42 am, Martin v. Löwis wrote: > Phil Thompson schrieb: > > 1. Don't suggest to people that, in order to get their patch reviewed, > > they should review other patches. The level of knowledge required to put > > together a patch is much less than that required to know if a patch is > > the right one. > > People don't *have* to review patches. They just can do that if they > want expedite review of their code. > > > 2. Publically identify the core developers and their areas of expertise > > and responsibility (ie. which parts of the source tree they "own"). > > I doubt this will help. Much of the code isn't owned by anybody > specifically. Those parts that are owned typically find their patches > reviewed and committed quickly (e.g. the tar file module, maintained by > Lars Gustäbel). Doesn't your last sentence completely contradict your first sentence? > > 4. Acceptance by core developers that only half the "job" is developing > > the core - the other half is mentoring potential future core developers. > > So what do you do with core developers that don't do their job? Fire them? Of course not, but this is a cultural issue not a technical one. The first step in changing a culture is to change the expectations. Phil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On Tuesday 06 March 2007 5:49 am, Martin v. Löwis wrote: > Phil Thompson schrieb: > > I'm not sure what your point is. My point is that, if you want to > > encourage people to become core developers, they have to have a method of > > graduating through the ranks - learning (and being taught) as they go. To > > place a very high obstacle in their way right at the start is completely > > counter-productive. > > And please be assured that no such obstacle is in the submitters way. > Most patches are accepted without the submitter actually reviewing any > other patches. I'm glad to hear it - but I'm talking about the perception, not the fact. When occasionally submitters ask if their patch is going to be included, they will usually get a response suggesting they review other patches. That will only strengthen the perception. This discussion started because the feeling was expressed that it was difficult to get patches accepted and that new core developers were not being found. I would love to contribute more to the development of Python - I owe it a lot - but from where I stand (which is most definitely not where you stand) I can't see how to do that in a productive and rewarding way. Phil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] locals(), closures, and IronPython...
On 3/5/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I don't know too many good use cases for
> locals() apart from "learning about the implementation" I think this
> might be okay.
Since I'm watching this list for any discussion on the traceback
threads, I figured I would point out the most common use I know
for locals() is in string interpolation when there are many local
variables, eg:
a = "spam"
b = "egg"
...
y = "foo"
z = "bar"
print fmtstr % locals()
The next most is to deal with a large number of input parameters, as
this from decimal.py:
def __init__(self, prec=None, rounding=None,
traps=None, flags=None,
_rounding_decision=None,
Emin=None, Emax=None,
capitals=None, _clamp=0,
_ignored_flags=None):
...
for name, val in locals().items():
if val is None:
setattr(self, name, _copy.copy(getattr(DefaultContext, name)))
else:
setattr(self, name, val)
and this example based on a post of Alex Martelli's:
def __init__(self, fee, fie, foo, fum):
self.__dict__.update(locals())
del self.self
In both cases they are shortcuts to "reduce boilerplate".
I've more often used the first form in my code. If an
inner local returned a superset of the items it returns now,
I would not be concerned.
I've rarely used the 2nd form in my code. The only way
I can see there being a problem is if a function defines
a class, which then uses the locals() trick, because
>>> def blah():
...a = 6; b = 7
...class XYZ(object):
... def __init__(self):
...c = a
...print "in the class", locals()
...print "in the function", locals()
...XYZ()
...
>>> blah()
in the function {'a': 6, 'XYZ': , 'b': 7}
in the class {'a': 6, 'c': 6, 'self': <__main__.XYZ object at 0x72ad0>}
the code in the class's initializer will have more locals. I've
never seen code like this (class defined in a function, with __init__
using locals()) and it's not something someone would write
thinking it was a standard way of doing things.
In both cases I'm not that bothered if it's implementation specific.
Using locals has the feel of being too much like a trick to get
around having to type so much. That's what editor macros are for :)
Andrew
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On Tuesday 06 March 2007 6:00 am, Martin v. Löwis wrote: > Phil Thompson schrieb: > >>> Any ideas for fixing this problem? > >> > >> A better patch-tracker, better procedures for reviewing patches > >> surounding this new tracker, one or more proper dvcs's for people to > >> work off of. I'm not sure about 'identifying core developers' as we're > >> all volunteers, with dayjobs for the most part, and only a few people > >> seem to care enough about python as a whole. > > > > I don't think that that is true. I think a lot of people care, but many > > can't do anything about because the barrier to entry is too great. > > He was talking about the committers specifically who don't care about > Python as-a-whole, and I think this is true. But I also believe that > many contributors don't "care" about Python as-a-whole, in the sense > that they are uninterested in learning about implementation details of > libraries they will never use. What they do care about is the problems > they have, and they do contribute patches for them. > > >> While submitting patches is good, there's a lot more to it than just > >> submitting the 5-line code change to submit a bug/feature, and reviewing > >> takes a lot of time and effort. > > > > So there is something wrong there as well. > > > >> I don't think it's unreasonable to ask for > >> help from the submitters like we do, or ask them to write tests and docs > >> and such. > > > > Of course it's not unreasonable. I would expect to be told that a patch > > must have tests and docs before it will be finally accepted. However, > > before I add those things to the patch I would like some timely feedback > > from those with more experience that my patch is going in the right > > direction. > > This cannot work. It is very difficult to review a patch to fix a > presumed bug if there is no test case. You might not be able to > reproduce the patch without a test case at all - how could you then > know whether the patch actually fixes the bug? Please read what I said again. Yes, a patch must be reviewed before submission. Yes, a patch when submitted must include docs and test cases. I'm talking about the less formal process leading up to that point. The less formal process has a much lower barrier to entry, requires much less effort by the "reviewer", is the period during which the majority of the teaching happens, and will result in a better quality final patch that will require less effort to be put in to the final, formal review. > So I really think patches should be formally complete before being > submitted. This is an area were anybody can review: you don't need > to be an expert to see that no test cases are contributed to a > certain patch. > > If you really want to learn and help, review a few patches, to see > what kinds of problems you detect, and then post your findings to > python-dev. People then will comment on whether they agree with your > review, and what additional changes they like to see. Do you think this actually happens in practice? There is no point sticking to a process, however sensible, if it doesn't get used. Phil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On 3/6/07, Phil Thompson <[EMAIL PROTECTED]> wrote: > On Tuesday 06 March 2007 5:49 am, Martin v. Löwis wrote: > > Phil Thompson schrieb: > > > I'm not sure what your point is. My point is that, if you want to > > > encourage people to become core developers, they have to have a method of > > > graduating through the ranks - learning (and being taught) as they go. To > > > place a very high obstacle in their way right at the start is completely > > > counter-productive. > > > > And please be assured that no such obstacle is in the submitters way. > > Most patches are accepted without the submitter actually reviewing any > > other patches. > > I'm glad to hear it - but I'm talking about the perception, not the fact. When > occasionally submitters ask if their patch is going to be included, they will > usually get a response suggesting they review other patches. That will only > strengthen the perception. > > This discussion started because the feeling was expressed that it was > difficult to get patches accepted and that new core developers were not being > found. I would love to contribute more to the development of Python - I owe > it a lot - but from where I stand (which is most definitely not where you > stand) I can't see how to do that in a productive and rewarding way. I recognize there is a big problem here. Each of us as individuals don't scale. So in order to get stuff done we need to be more distributed. This means distributing the workload (partially so we don't burn out). In order to do that we need to distribute the knowledge. That probably involves some changes. I understand it's really hard to get involved. It can be frustrating at times. But I think the best way is to find a mentor. Find an existing core developer that you relate to and/or have similar interests with. I've been trying to do this more. So here's my offer. Anyone who is serious about becoming a Python core developer, but doesn't know how to get involved can mail me. Privately, publicly, it doesn't matter to me. I will try to mentor you. Be prepared! I will demand submissions are high quality which at a minimum means: - it adds a new test, enhances an existing test or fixes a broken test - it has *all* the required documentation, including versionadded/versionchanged - most people think the feature is desirable - the code is maintainable and formatted according to the prevailing style - we follow the process (which can include improving the process if others agree) ie, there's no free lunch, unless you work at Google of course :-) It also means you are willing to hold other people up to equally high standards. Your contributions don't have to be code though. They can be doc, they can be PEPs, they can be the python.org website. It could even be helping out with Google's Summer of Code. The choice is yours. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On Tuesday 06 March 2007 6:15 am, Raymond Hettinger wrote: > [Phil Thompson] > > > I think a lot of people care, but many can't > > do anything about because the barrier to entry is too great. > > Do you mean commit priviledges? ISTM, those tend to be > handed out readily to people who assert that they have good use for them. > Ask the Georg-bot how readily he was accepted and coached. IMO, > his acceptance was a model that all open source projects should aspire to. > > If you meant something else like knowing how to make a meaningful patch, > then you've got a point. It takes a while to learn your way around the > source tree and to learn the inter-relationships between the moving parts. > That is just the nature of the beast. I meant the second. While it may be the nature that doesn't mean that the situation can't be improved. > [MvL] > > >> While submitting patches is good, there's a lot more to it than just > >> submitting the 5-line code change to submit a bug/feature, and reviewing > >> takes a lot of time and effort. > > [Phil] > > > So there is something wrong there as well. > > I have not idea what you're getting at.Martin's comment seems > accurate to me. Unless it is a simple typo/doc fix, it takes > some time to assess whether the bug is real (some things are bugs > only in the eye of the submitter) and whether the given fix is the > right thing to do. > > Of course, automatic acceptance of patches would be a crummy idea. > There have been no shortage of patches complete with docs and tests > that were simply not the right thing to do. My point is simply that the effort required to review patches seems to be a problem. Perhaps the reasons for that need to be looked at and the process changed so that it is more effective. At the moment people just seem be saying "that's the way it is because that's the way it's got to be". > [Phil] > > > The process needs > > to keep people involved in it - at the moment submitting a patch is > > fire-and-forget. > > Such is the nature of a system of volunteers. If we had full-time people, > it could be a different story. IMO, given an 18 month release cycle, > it is perfectly acceptable for a patch to sit for a while until someone > with the relavant expertise can address it. Even with a tests and docs, > patch acceptance is far from automatic. That being said, I think history > has shown that important bugs get addressed and put into bug fix releases > without much loss of time. When Py2.5.1 goes out, I expect that all known, > important bugs will have been addressed and that's not bad. Then perhaps getting a full-time person should be taken seriously. Phil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
Stephen J. Turnbull schrieb: > An informal version of this process is how XEmacs identifies its > Reviewers (the title we give to those privileged to authorize commits > to all parts of XEmacs). People who care enough to make technical > comments on *others'* patches are rare, and we grab the competent ones > pretty quickly. My experience exactly. Besides Georg Brandl, I think this was also how Raymond Hettinger started his regular contributions to Python. > The mess is not "total", as Josiah Carlson points out. To the extent > that it is a mess, it is the consequence of a process similar to the > one you propose to institutionalize. It wasn't clear to me that this is the case, but I think you are exactly right. Those libraries that are now considered a mess had been ad-hoc contributions in many cases, with a single use case (namely the one of the original contributor). The contributor is not to blame, of course: he could only contribute what he has experience with. I wouldn't blame the committers who accepted the libraries, either - much of Python's value is in "libraries included". So to fix "the total mess", one has to replace the libraries with better ones, were available, learning from past experience to not accept libraries that had not been widely tested "in the field". > Second, where the stdlib module is closely bound to the core, the > maintainer ends up being the group of core developers. It can't be > any other way, it seems to me. It might be that individuals get designated maintainers: Guido maintains list and tuple, Tim maintaines dict, Raymond maintains set, I maintain configure.in. However, I doubt that would work in practice. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On 3/6/07, Neil Schemenauer <[EMAIL PROTECTED]> wrote: Using git-svn to track a SVN repository seems to work well. I'm not interested in setting up GIT myself, mostly because it doesn't solve any issues that other dvcs' don't solve, the on-disk repository is mighty big and it doesn't work very well on non-Linux systems (at least, not last I looked.) If you want to set it up and maintain it, though, that's fine by me. I would like to point out that while it takes only a few minutes to setup a new repository and start the conversion for any of the SCM's (not just distributed ones), that doesn't mean it's a no-brainer to set them up 'officially', and maintain them :) There's a lot more work in there, so be prepared to spend some time to get it to work right and reliable for everyone. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On 3/6/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: [MvL] >> While submitting patches is good, there's a lot more to it than just >> submitting the 5-line code change to submit a bug/feature, and reviewing >> takes a lot of time and effort. That was incorrectly attributed; it was me, not Martin. (But thanks for agreeing :) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
Phil Thompson schrieb: >>> 2. Publically identify the core developers and their areas of expertise >>> and responsibility (ie. which parts of the source tree they "own"). >> I doubt this will help. Much of the code isn't owned by anybody >> specifically. Those parts that are owned typically find their patches >> reviewed and committed quickly (e.g. the tar file module, maintained by >> Lars Gustäbel). > > Doesn't your last sentence completely contradict your first sentence? No (not sure how you are counting: there are three sentences): 1. Public identification will not help, because: 2. most code isn't in the responsibility of anybody (so publically identifying responsibilities would leave most code unassigned), and 3. for the code that has some responsible member, things are already fine (so public identification won't improve here) Maybe you meant to suggest "assign responsibilities to core developers, then identify them publically"; this is different from merely publically announcing already-assigned specific responsibilities. The latter won't work for the reasons discussed; the former won't work because these are volunteers, you can't assign anything to them. >>> 4. Acceptance by core developers that only half the "job" is developing >>> the core - the other half is mentoring potential future core developers. >> So what do you do with core developers that don't do their job? Fire them? > > Of course not, but this is a cultural issue not a technical one. The first > step in changing a culture is to change the expectations. I think the expectations of the users of Python have to adjust, then. This is free software, it has its own working principles that people need to get used to. In essence: if you want change, you need to execute it your own. Nobody will do it for you. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
Phil Thompson schrieb: >> And please be assured that no such obstacle is in the submitters way. >> Most patches are accepted without the submitter actually reviewing any >> other patches. > > I'm glad to hear it - but I'm talking about the perception, not the fact. > When > occasionally submitters ask if their patch is going to be included, they will > usually get a response suggesting they review other patches. That will only > strengthen the perception. That's because those who get their patches accepted quickly never complain. They are still the majority, though. In case of Titus Brown (who complained in his blog), I found that all of his 5 patches got integrated into Python, me committing four of them, and Georg committing one. Response time was between 3 days and 16 months. > This discussion started because the feeling was expressed that it was > difficult to get patches accepted and that new core developers were not being > found. I would love to contribute more to the development of Python - I owe > it a lot - but from where I stand (which is most definitely not where you > stand) I can't see how to do that in a productive and rewarding way. Not sure how long you have been contributing to free software: you will find, over time, that it is rewarding to get changes accepted even if the process takes several months. Patience is an important quality here. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
Phil Thompson schrieb:
>>> Of course it's not unreasonable. I would expect to be told that a patch
>>> must have tests and docs before it will be finally accepted. However,
>>> before I add those things to the patch I would like some timely feedback
>>> from those with more experience that my patch is going in the right
>>> direction.
>> This cannot work. It is very difficult to review a patch to fix a
>> presumed bug if there is no test case. You might not be able to
>> reproduce the patch without a test case at all - how could you then
>> know whether the patch actually fixes the bug?
>
> Please read what I said again.
I did - I can't see where I misunderstood. You said you want feedback on
the patch even if it doesn't have test and doc changes ("before I add
those things"), and I said the only feedback you'll likely get is
"add test cases and doc changes".
> Yes, a patch must be reviewed before
> submission. Yes, a patch when submitted must include docs and test cases. I'm
> talking about the less formal process leading up to that point. The less
> formal process has a much lower barrier to entry, requires much less effort
> by the "reviewer", is the period during which the majority of the teaching
> happens, and will result in a better quality final patch that will require
> less effort to be put in to the final, formal review.
Here I'm not sure what you are talking about. How would that process be
executed? On python-dev? On the patches tracker?
It often happens that people write a bug report, and I respond
"yes, this is a bug, would you like to work on a patch?" They then
either ask "should I do it this or that way?", and then I give my
opinion. So this already happens - again, it's just that the people
don't talk much about it.
I can't see that the barrier at contributing is high. The number
of patch submissions and bug reports proves the contrary. Literally
hundreds of people contribute.
>> If you really want to learn and help, review a few patches, to see
>> what kinds of problems you detect, and then post your findings to
>> python-dev. People then will comment on whether they agree with your
>> review, and what additional changes they like to see.
>
> Do you think this actually happens in practice?
I wasn't talking in general, I was talking specifically about you
(Phil Thompson) here. If you really want to contribute in
*maintaining* Python, you are more than welcome. Several current
committers found their way into python-dev in the way you described,
and nearly nobody was ever turned away.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
Phil Thompson schrieb: > My point is simply that the effort required to review patches seems to be a > problem. Perhaps the reasons for that need to be looked at and the process > changed so that it is more effective. At the moment people just seem be > saying "that's the way it is because that's the way it's got to be". We have already changed the process a lot. These days patches are regularly turned away for not having tests and doc changes in them. Yet, there are no reviewers willing to contribute even this very straight-forward, easy-to-execute check. If the patch meets the formal criteria, the hard part (on the reviewers side) starts: they must understand the code being patched, the nature of the problem, and the patch itself. I don't see how this could be simplified, without neglecting quality. > Then perhaps getting a full-time person should be taken seriously. That's quite expensive, plus somebody would need to supervise that person. A part-time person would be less expensive, but still needs supervision. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
Phil Thompson writes: > MvL wrote: > > I doubt this will help. Much of the code isn't owned by anybody > > specifically. Those parts that are owned typically find their patches > > reviewed and committed quickly (e.g. the tar file module, maintained by > > Lars Gustäbel). > Doesn't your last sentence completely contradict your first sentence? Not in view of the second one. Martin is saying that where the existing process looks like your suggestion, it already works great. It's not that this isn't well-known to the core developers! The problem is a lack of reviewers/module "owners". The existing review-for-review *offer* (not requirement!) proposes to increase the supply of reviewers by offering them "good and valuable consideration" (ie, a fast track for their own patches) in return. You may not wish to take advantage of that offer, but it addresses the underlying problem. The other proposals on the table amount to (a) the existing reviewers should work harder and (b) if patches aren't reviewed, then they should be presumed good enough to apply. I think it should be obvious how far they will get when restated in those practical terms. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Access to bits for a PyLongObject
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <[EMAIL PROTECTED]> wrote: > Eric V. Smith schrieb: > > I'm working on PEP 3101, Advanced String Formatting. About the only > > built-in numeric formatting I have left to do is for converting a > > PyLongOjbect to binary. > > > > I need to know how to access the bits in a PyLong. > > I think it would be a major flaw in PEP 3101 if you really needed it. > The long int representation should be absolutely opaque - even the > fact that it is a sign+magnitude representation should be hidden. Well, it depends on the level for which PEP 3101 is intended. I had the same problem, and was pointed at _PyLong_AsByteArray, which was all I needed. In my case, going though a semi-generic formatter would not have been an acceptable interface (performance). However, if PEP 3101 is intended to be a higher level of formatting, then I agree with you. So I have nailed my colours firmly to the fence :-) Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
"Martin v. Löwis" writes: > Stephen J. Turnbull schrieb: > > Second, where the stdlib module is closely bound to the core, the > > maintainer ends up being the group of core developers. It can't be > > any other way, it seems to me. > > It might be that individuals get designated maintainers: Guido maintains > list and tuple, Tim maintaines dict, Raymond maintains set, I maintain > configure.in. However, I doubt that would work in practice. I was referring more to modules like "os" than to language features. My experience with XEmacs is that 3rd parties are generally surprised at how wide the range of packages that are considered to require the blessing of a core developer before messing with them. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On 06/03/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Scott Dial schrieb: > > While I understand that this tit-for-tat mechanism is meant to ensure > > participation, I believe in reality it doesn't, as the 400-some > > outstanding patches you referenced elswhere indicate. I can personally > > attest to having a patch that is over a year old with no "core > > developer" having any interest at all with the subject matter. And to be > > frank, nor did I really, but I saw a problem and was capable of solving > > it. My lack of caring about the patch means I am not going to beat > > people over the head to pay attention. This system is broken for someone > > like me (coder) that just wants to help out (non-coders). > > If you don't care that much about the patch, it's not broken. As I said > before, the number of unreviewed patches has been roughly stable for > some time now. If the patch is not really important, it may take two > years now to get it in, but eventually, it will (if you then still are > interested to work on it to complete it). Here's a random offer - let me know the patch number for your patch, and I'll review it. Note that I do *not* consider myself a core developer, I don't even have the tools these days to build Python easily - I certainly haven't done so for a while. The likelihood is that I don't know much about the subject area of your patch, either. As a final disclaimer, note that I have no commit privilege, so my review won't result in your patch actually being applied :-) I'll post the results of my review here, as an example of what a reviewer needs to look at. If someone wants to distil that into a set of "how to review a patch" guidelines, then that's great. More reviewers would be a huge benefit. I agree that "contributing" feels hard, and often the hard bit is gaining the attention of the committers. The 5-for-1 offers help this, and shouldn't be dismissed - it's just that the *other* ways involve people skills (and so are far harder!!!) Maybe we should emphasize (again) that reviewing patches is also contributing, and would be greatly appreciated. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
Paul Moore schrieb: >> Scott Dial schrieb: >>> While I understand that this tit-for-tat mechanism is meant to ensure >>> participation, I believe in reality it doesn't, as the 400-some >>> outstanding patches you referenced elswhere indicate. I can personally >>> attest to having a patch that is over a year old with no "core >>> developer" having any interest at all with the subject matter. > > Here's a random offer - let me know the patch number for your patch, > and I'll review it. Surprisingly (and I hope Scott can clarify that), I can't find anything. Assuming Scott's SF account is "geekmug", I don't see any open patches (1574068 was closed within 20 days by amk, last October). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] splitext('.cshrc')
#1115886 complains that in the file name '.cshrc', the entire file name is treated as an extension, with no root. #1462106 contains a patch for that, changing the behavior so that there will always be a root file name (and no extension if the file is just a dotfile). Should this be changed? Opinions? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
On 3/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > #1115886 complains that in the file name '.cshrc', the > entire file name is treated as an extension, with no > root. > > #1462106 contains a patch for that, changing the behavior > so that there will always be a root file name (and no > extension if the file is just a dotfile). > > Should this be changed? Opinions? +1 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
On Tue, Mar 06, 2007 at 01:36:03PM +0100, "Martin v. L?wis" wrote: > #1115886 complains that in the file name '.cshrc', the > entire file name is treated as an extension, with no > root. > > #1462106 contains a patch for that, changing the behavior > so that there will always be a root file name (and no > extension if the file is just a dotfile). > > Should this be changed? Opinions? Yes. In .pythonrc.py .pythonrc is the root, and .py is the extension. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] locals(), closures, and IronPython...
On 3/5/07, Dino Viehland <[EMAIL PROTECTED]> wrote:
> Thanks Guido. It might take some time (and someone may very well beat me to
> it if they care a lot) but I'll see if we can get the PEP started.
Dino,
One of the questions I was puzzling over was what locals() should
return in a class scope. It's confusing in CPython, because the same
dictionary is used to stored names that are destined to become class
attributes and names that are used to created closures for methods
with free variables. The implementation was causing the latter names
to show up as class attributes when you called locals().
Terry is right that lifetime of variables is a key issue. It would
probably be bad if all the local variables of a function were kept
alive because a nested function used locals().
One idea was discussed at PyCon was having a different representation
for an environment so that it would be easier to introspect on it but
still possible to pass the environment to exec. One possibility is
just a third dictionary--globals, locals, nonlocals. Another
possibility is an object where you can ask about the scope of each
variable but also extract a dictionary to pass to locals.
Jeremy
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guido van
> Rossum
> Sent: Monday, March 05, 2007 2:14 PM
> To: Dino Viehland
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] locals(), closures, and IronPython...
>
> Jeremy Hylton has been asking questions about this too at the sprint
> after PyCon. I'm tempted to accept that the exact behavior of locals()
> is implementation-defined (IOW undefined :-) as long as it includes
> the locals defined in the current scope; whether it also includes free
> variables could be debatable. I don't know too many good use cases for
> locals() apart from "learning about the implementation" I think this
> might be okay. Though a PEP might be in order to get agreement between
> users, developers and other implementation efforts (e.g. PyPy,
> Jython).
>
> On 3/5/07, Dino Viehland <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> > def a():
> >
> > x = 4
> >
> > y = 2
> >
> > def b():
> >
> > print y, locals()
> >
> > print locals()
> >
> > b()
> >
> >
> >
> > a()
> >
> >
> >
> > in CPython prints:
> >
> >
> >
> > {'y': 2, 'x': 4, 'b': }
> >
> > 2 {'y': 2}
> >
> >
> >
> > I'm wondering if it's intentional that these don't print dictionaries w/ the
> > same contents or if it's more an accident of the implementation. In other
> > words would it be reasonable for IronPython to promote all of the locals of
> > a into b's dictionary when both a and b call locals?
> >
> >
> >
> > We currently match CPython's behavior here - at least in what we display
> > although possibly not in the lifetimes of objects. We're considering an
> > internal change which might alter the behavior here though and end up
> > displaying all the members.
> >
> >
> >
> >
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > http://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> > http://mail.python.org/mailman/options/python-dev/guido%40python.org
> >
> >
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
Martin v. Löwis schrieb: > #1115886 complains that in the file name '.cshrc', the > entire file name is treated as an extension, with no > root. > > #1462106 contains a patch for that, changing the behavior > so that there will always be a root file name (and no > extension if the file is just a dotfile). > > Should this be changed? Opinions? Since dotfiles can have extensions as well (e.g. ~/.fonts.conf), I'd say that the current behavior is wrong. Question is, is it worth possibly breaking compatibility... Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
Raymond Hettinger schrieb: > [Phil Thompson] >> I think a lot of people care, but many can't >> do anything about because the barrier to entry is too great. > > Do you mean commit priviledges? ISTM, those tend to be > handed out readily to people who assert that they have good use for them. > Ask the Georg-bot how readily he was accepted and coached. IMO, > his acceptance was a model that all open source projects should aspire to. Indeed. For me, it wasn't "hard" to get tracker rights. I reviewed some patches, commented on bugs, posted suggestions to python-dev etc. When I asked about tracker rights on python-dev, they were given to me. Then, it wasn't "hard" to get commit rights. I contributed some stuff, and after a while I asked about commit rights on python-dev, and they were given to me on condition that I still let a core dev review inteded changes. As far as I recall, there has been nearly no one who asked for commit rights recently, so why complain that the entry barrier is too great? Surely you cannot expect python-dev to got out and say "would you like to have commit privileges?"... Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On 3/6/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > Raymond Hettinger schrieb: > > [Phil Thompson] > >> I think a lot of people care, but many can't > >> do anything about because the barrier to entry is too great. > > > > Do you mean commit priviledges? ISTM, those tend to be > > handed out readily to people who assert that they have good use for them. > > Ask the Georg-bot how readily he was accepted and coached. IMO, > > his acceptance was a model that all open source projects should aspire to. > > Indeed. For me, it wasn't "hard" to get tracker rights. I reviewed some > patches, > commented on bugs, posted suggestions to python-dev etc. When I asked about > tracker rights on python-dev, they were given to me. > Then, it wasn't "hard" to get commit rights. I contributed some stuff, and > after a while I asked about commit rights on python-dev, and they were given > to me on condition that I still let a core dev review inteded changes. > > As far as I recall, there has been nearly no one who asked for commit rights > recently, so why complain that the entry barrier is too great? Surely you > cannot expect python-dev to got out and say "would you like to have commit > privileges?"... You can ask whether we should have a plan for increasing the number of developers, actively seeking out new developers, and mentoring people who express interest. Would the code be better if we had more good developers working on it? Would we get more bugs fixed and patches closed? If so, it wouldn't hurt to have some deliberate strategy for bringing new developers in. I can easily imagine someone spending a lot of time mentoring and a little time coding, but having a bigger impact that someone who only wrote code. Jeremy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
Am Dienstag, 06. März 2007 13:36 schrieb Martin v. Löwis: > #1115886 complains that in the file name '.cshrc', the > entire file name is treated as an extension, with no > root. > > #1462106 contains a patch for that, changing the behavior > so that there will always be a root file name (and no > extension if the file is just a dotfile). > > Should this be changed? Opinions? +1 The current behavior is clearly a bug, since a leading dot does not start an extension, but marks a file as "hidden". The latter is on UNIX, and while this is different on Windows, I cannot imagine that anyone would a) have dotfiles under that OS, or even then b) rely on the current behavior that their full filename counts as "extension". Greetings, Hans ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Access to bits for a PyLongObject
Martin v. Löwis wrote: > Eric V. Smith schrieb: >> I'm working on PEP 3101, Advanced String Formatting. About the only >> built-in numeric formatting I have left to do is for converting a >> PyLongOjbect to binary. >> >> I need to know how to access the bits in a PyLong. > > I think it would be a major flaw in PEP 3101 if you really needed it. > The long int representation should be absolutely opaque - even the > fact that it is a sign+magnitude representation should be hidden. > > Looking at the PEP, I see that a class can implement __format__. > Wouldn't it be appropriate if the long type implemented that? > Implementation-wise, I would expect that long_format already does the > bulk of what you need to do. Yes, I think that would be appropriate. However, it conflicts with the current implementation strategy, which is to make a stand-alone module until we can flush out all of the issues. Not that our current implementation should drive the correct decision, of course. Also, it would either mean duplicating lots of code from the int formatter, or having a formatter library that both can call. This is because __format__ must implement all formats, including padding, parenthesis for negatives, etc., not just the "missing" binary format. Not that that's necessarily bad, either. But see the next point. > OTOH, also look at _PyString_FormatLong. I think a solution would be to add 'b' to _PyString_FormatLong, which I'm already calling for hex, octal, and decimal formatting. Does that sound reasonable? It seems to me that if binary is useful enough for PEP 3101, it should generally be available in _PyString_FormatLong. The obvious implementation of this would require adding a nb_binary to PyNumberMethods. I'm not sure what the impact of that change would be, but it sounds really big and probably a show-stopper. Maybe a direct call to a binary formatter would be better. OTOH, this approach isn't as efficient as I'd like (for all formatting outputs, not just binary), because it has to build a string object and then copy data out of it. Having written all of this, I'm now thinking that Nick's suggestion of _PyLong_AsByteArray might be the way to go. I would use that for all of my formatting for longs. I think I can use my output buffer as the buffer for _PyLong_AsByteArray, since all formats (binary, decimal, octal, hex) are less "bit dense" than the byte array. As long as I read, format, and write the data in the correct order, I'd be okay. So even though I'd copy the data into my buffer, at least I wouldn't be allocating more memory or another object just to extract data from the long. Maybe I'm over-emphasizing performance, given the early status of the implementation. But I'd like PEP 3101 to be as efficient as possible, because once it's available I'll replace all of the '%' string formatting in my code with it. I think others will consider that as well. Thank you for your insights. I apologize for the length of this message, but as I believe Pascal said, I did not have time to make it shorter. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On Tuesday 06 March 2007 1:42 pm, Jeremy Hylton wrote: > On 3/6/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > > Raymond Hettinger schrieb: > > > [Phil Thompson] > > > > > >> I think a lot of people care, but many can't > > >> do anything about because the barrier to entry is too great. > > > > > > Do you mean commit priviledges? ISTM, those tend to be > > > handed out readily to people who assert that they have good use for > > > them. Ask the Georg-bot how readily he was accepted and coached. IMO, > > > his acceptance was a model that all open source projects should aspire > > > to. > > > > Indeed. For me, it wasn't "hard" to get tracker rights. I reviewed some > > patches, commented on bugs, posted suggestions to python-dev etc. When I > > asked about tracker rights on python-dev, they were given to me. > > Then, it wasn't "hard" to get commit rights. I contributed some stuff, > > and after a while I asked about commit rights on python-dev, and they > > were given to me on condition that I still let a core dev review inteded > > changes. > > > > As far as I recall, there has been nearly no one who asked for commit > > rights recently, so why complain that the entry barrier is too great? > > Surely you cannot expect python-dev to got out and say "would you like to > > have commit privileges?"... > > You can ask whether we should have a plan for increasing the number of > developers, actively seeking out new developers, and mentoring people > who express interest. Would the code be better if we had more good > developers working on it? Would we get more bugs fixed and patches > closed? If so, it wouldn't hurt to have some deliberate strategy for > bringing new developers in. I can easily imagine someone spending a > lot of time mentoring and a little time coding, but having a bigger > impact that someone who only wrote code. Thank you - that's exactly what I'm trying to say. Phil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
On Tue, Mar 06, 2007 at 02:44:52PM +0100, Hans Meine wrote: > a leading dot does not start an > extension, but marks a file as "hidden". The latter is on UNIX, and while On Unix - I mean in the OS itself - there are no such things as "roots", "extensions" and "hidden files". All these are only conventions in the user programs. The current behaviour is not a bug in a strict sense, but it is inconvenient and hence should be changed. > this is different on Windows, I cannot imagine that anyone would > a) have dotfiles under that OS I have. (-: I often copy files from an ext3 partition to a FAT partition on my dual-booting desktop. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
Oleg Broytmann wrote: >[snip..] > >>this is different on Windows, I cannot imagine that anyone would >>a) have dotfiles under that OS >> >> > > > It is very common for cross platform programs to create configuration files which are dotfiles, whichever OS they are running on. Michael Foord ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On Tue, Mar 06, 2007 at 10:26:50AM +0100, Thomas Wouters wrote: > I'm not interested in setting up GIT myself, mostly because it > doesn't solve any issues that other dvcs' don't solve dvcs wars are the new editor wars. :-) > the on-disk repository is mighty big and it doesn't work very well > on non-Linux systems (at least, not last I looked.) Not true. The on-disk repository is now one of the more efficient ones. There is also now a MinGW port (i.e. native Windows). Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Patch 1644818: Allow importing built-in submodules
Hi list, A month and a half ago, I submitted patch 1644818 to the CPython Patch Tracker: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1644818&group_id=5470 On several occassions I have been advised to mention the patch in this list, so here it is: The problem: Importing built-in submodule extensions (e.g. PyQt4.QtCore and PyQt4.QtGui in my case) does not work. By built-in I mean statically linked against the Python executable. The cause: find_module in import.c only checks the module name (e.g. QtCore) against the built-in list, which should contain the full name (e.g. PyQt4.QtCore) instead. Also, the above check is performed after the code to check if the parent module is frozen, which would have already exited in that case. Solution: By moving the "is_builtin()" check to earlier in find_module and using the "fullname" variable instead of "name", I can build PyQt4.QtCoreand PyQt4.QtGui into the interpreter and import and use them with no problem whatsoever, even if their parent module (PyQt4) is frozen. When I submitted the patch, I ran the regression tests and everything seemed Ok. Also, the patch is for Python-2.5, but it a month and a half ago it was applicable to the svn trunk with only a one-line offset. As I am completely new to CPython development, perhaps this problem has already been discussed and/or fixed I may have done something incorrectly. Please let me know if that is the case. Regards, Miguel Lobo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
Georg Brandl wrote: > As far as I recall, there has been nearly no one who asked for commit rights > recently, so why complain that the entry barrier is too great? Surely you > cannot expect python-dev to got out and say "would you like to have commit > privileges?"... I think the number one suggestion I can make to anyone who is genuinely interested in contributing to the Python core is to lurk on python-dev for a while. It *does* require a reasonable time commitment (much more than the time required to fire a one-off patch at the SF tracker), but I've certainly found it to be a valuable learning experience (both in general and in relation to Python core development): - getting an idea of who's who (and what's what) in the Python world - getting an idea of what needs to be done in CPython development - seeing bugs and patches discussed (yes, it happens!) - learning various non-Python specific things ranging from good API design and doing object-oriented programming in C to the intricacies of binary floating point, Unicode and POSIX signal handling (etc, etc, ...) I believe my personal involvement in core development followed a similar trajectory to Georg's - lurked on python-dev for a while, began participating in discussions before too long (I'm not very good at lurking ;), helped out with the initial addition of the decimal module, got tracker privileges to help out with various bugs and patches, then eventually got commit privileges in order to update PEP 343. And I think this approach still works - it's just that it is mainly useful to people that are interested in Python core development in general, rather than those that are looking to get a specific bug fixed or patch accepted (although the latter can happen too - Lars was given commit privileges when it became clear that he was both willing and able to be the maintainer of the tarfile module). One thing that did happen though (which the messages from Jeremy & Phil reminded me of) is that I got a lot of direction, advice and assistance from Raymond when I was doing that initial work on improving the speed of the decimal module - I had the time available to run the relevant benchmarks repeatedly and try different things out, while Raymond had the experience needed to suggest possible avenues for optimisation (and when to abandon an approach as making the code too complicated to be effectively maintained). I don't know whether or not there is anything specific we can do to encourage that kind of coaching/mentoring activity, but I know it was a significant factor in my become more comfortable with making contributions. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On Tue, Mar 06, 2007 at 09:06:22AM +, Phil Thompson wrote: > My point is simply that the effort required to review patches seems to be a > problem. Perhaps the reasons for that need to be looked at and the process > changed so that it is more effective. At the moment people just seem be > saying "that's the way it is because that's the way it's got to be". Unfortunately I think the effort required is intrinsic to reviewing patches. Trivial or obviously correct patches get applied quickly, so the remaining bugs and patches are the ones that are hard to fix. For example, our oldest bug is http://www.python.org/sf/214033, opened 2000-09-11, and is that (x?)? is reported as an error by the SRE regex parser; the PCRE engine and Perl both accept it. Fixing it requires changing sre_parse, figuring out what to do (should it be equivalent to '(x?)' or to '(x)?', and then being very sure that no other patterns are broken by the change. I suspect that fixing this bug properly by researching the right answer, implementing it, and adding tests would take me a half-day's worth of work. If modifying sre_parse is very difficult, it could take longer. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SVK (was: Encouraging developers)
On Tue, Mar 06, 2007 at 07:59:53AM +0100, Ronald Oussoren wrote: > development easier for them. They can already do this using SVK, > which is a distributed version control system as well but uses SVN > repositories to store its data. I'm happy to write up a wiki page describing how to use SVK to set up your own mirror of the Python SVN. However, trying it now, the initial setup seems very slow: SVK is retrieving each of 54165 revisions and it'll probably take over an hour to complete. I'm retrying it now by mirroring only the trunk to see if that's any faster, but this seems like an impediment -- if you want to develop a bugfix of sufficient complexity to need a DVCS, and the first step required takes over an hour, that may dissipate your forward motion. (Of course, I don't know how long a checkout of a hypothetical Bazaar repository would take; maybe it's not any faster.) --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
Oleg Broytmann schrieb: >> Should this be changed? Opinions? > >Yes. In .pythonrc.py .pythonrc is the root, and .py is the extension. Ah, it would do that already: with multiple dots, the last one always provides the extension. However, for .pythonrc, it would conclude that .pythonrc is the extension. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
On Tue, Mar 06, 2007 at 04:00:01PM +0100, "Martin v. L?wis" wrote: > >Yes. In .pythonrc.py .pythonrc is the root, and .py is the extension. > > Ah, it would do that already: with multiple dots, the last one always > provides the extension. Ah, sorry. I messed it with .split(). Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
Jeremy Hylton schrieb: > You can ask whether we should have a plan for increasing the number of > developers, actively seeking out new developers, and mentoring people > who express interest. Would the code be better if we had more good > developers working on it? Would we get more bugs fixed and patches > closed? Certainly, yes. > If so, it wouldn't hurt to have some deliberate strategy for > bringing new developers in. Well, it might hurt. I do have a strategy: I force people eager to get their patches included into reviewing, with the 5:1 deal. I do consider it a useful strategy, and feel sorry that nobody else was willing to adopt it. However, it seems that this also has hurt, because now some people believe this is the only way to get patches reviewed (but perhaps that's not too bad, because before they believed there is no way at all to get patches reviewed...). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
Oleg Broytmann schrieb:
> On Tue, Mar 06, 2007 at 04:00:01PM +0100, "Martin v. L?wis" wrote:
>>>Yes. In .pythonrc.py .pythonrc is the root, and .py is the extension.
>> Ah, it would do that already: with multiple dots, the last one always
>> provides the extension.
>
>Ah, sorry. I messed it with .split().
Ok - now I'm confused: do you consider this behavior
(splitext('.pythonrc') == ('', '.pythonrc')) correct
or not?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] git (Was: Encouraging developers)
Neil Schemenauer schrieb: >> the on-disk repository is mighty big and it doesn't work very well >> on non-Linux systems (at least, not last I looked.) > > Not true. The on-disk repository is now one of the more efficient > ones. Which is a relative quality :-) Every time I update the Linux kernel sandbox I have, it takes many many minutes to run, and often aborts with a timeout. If this still makes git one of the more efficient dvcs systems, I don't want to see the other ones :-( Thinking of git always makes me not complain about the time subversion needs to produce a certain log message... Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
Nick Coghlan schrieb: > One thing that did happen though (which the messages from Jeremy & Phil > reminded me of) is that I got a lot of direction, advice and assistance > from Raymond when I was doing that initial work on improving the speed > of the decimal module - I had the time available to run the relevant > benchmarks repeatedly and try different things out, while Raymond had > the experience needed to suggest possible avenues for optimisation (and > when to abandon an approach as making the code too complicated to be > effectively maintained). > > I don't know whether or not there is anything specific we can do to > encourage that kind of coaching/mentoring activity, but I know it was a > significant factor in my become more comfortable with making contributions. While there was no explicit management of a mentoring process, I think it so happened that committers always found a mentor. It so happened that some developer activated privileges for them (either himself, or requesting that this be done), and then certainly feels responsible for his 'student'. This automatically establishes a mentoring relationship. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
On Tue, Mar 06, 2007 at 04:07:16PM +0100, "Martin v. L?wis" wrote:
> Oleg Broytmann schrieb:
> > On Tue, Mar 06, 2007 at 04:00:01PM +0100, "Martin v. L?wis" wrote:
> >>>Yes. In .pythonrc.py .pythonrc is the root, and .py is the extension.
> >> Ah, it would do that already: with multiple dots, the last one always
> >> provides the extension.
> >
> >Ah, sorry. I messed it with .split().
>
> Ok - now I'm confused: do you consider this behavior
> (splitext('.pythonrc') == ('', '.pythonrc')) correct
> or not?
I messed this in the sense that I have ran .split('.pythonrc.py'), got
('', '.pythonrc.py') and thought there is a problem. .split() works fine.
Even .splitext() works fine with multiple dots:
>>> os.path.splitext("/bin/.pythonrc.py")
('/bin/.pythonrc', '.py')
but
>>> os.path.splitext(".pythonrc")
('', '.pythonrc')
and I think it should be
('.pythonrc', '')
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
A.M. Kuchling schrieb: > For example, our oldest bug is http://www.python.org/sf/214033, opened > 2000-09-11, and is that (x?)? is reported as an error by the SRE regex > parser; the PCRE engine and Perl both accept it. Fixing it requires > changing sre_parse, figuring out what to do (should it be equivalent > to '(x?)' or to '(x)?', and then being very sure that no other > patterns are broken by the change. I suspect that fixing this bug > properly by researching the right answer, implementing it, and adding > tests would take me a half-day's worth of work. If modifying > sre_parse is very difficult, it could take longer. I just applied a patch by Aaron Watters for HTMLParser, which was three years old. The patch wasn't contributed in unified diff, it hadn't test cases and documentation changes, and it changed the way HTMLParser does unescaping of references in HTML attributes. It was a fairly small change, yet it contained a bug, and a likely-to-occur boundary behavior (entity references for undefined entities). In testing, I found that HTMLParser (incorrectly) supports ' and decided to continue to support it for compatibility. All in all, it took me about one hour to review and apply this patch (again, even though it changed only 20 lines or so). I felt it wouldn't have been fair to Aaron to go back and ask for unified diffs etc now that the patch had been sitting there for several years. Yet, in all these years, nobody else commented that the patch was incomplete, let alone commenting on whether the feature was desirable. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SVK
On Tue, Mar 06, 2007 at 09:53:35AM -0500, A.M. Kuchling wrote: > initial setup seems very slow: SVK is retrieving each of 54165 > revisions and it'll probably take over an hour to complete. It's even worse than that. Retrying with the trunk, SVK synced 500 revisions in about 10 minutes. We have 54165 revisions (not all trunk ones). That means it will take about 54165/500 * 10 minutes = 1080 minutes = 18 hours. Yikes! SVK has an option to skip revisions, the -s argument to sync, but it doesn't seem to work: [EMAIL PROTECTED]:~/tmp$ svk mirror http://svn.python.org/projects/python/ //mirror/python Committed revision 1977. [EMAIL PROTECTED]:~/tmp$ svk sync -s 54100 //mirror/python HTTP Path Not Found: REPORT request failed on '/projects/!svn/bc/1/python': '/projects/!svn/bc/1/python' path not found [EMAIL PROTECTED]:~/tmp$ --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Access to bits for a PyLongObject
Eric V. Smith schrieb: > Also, it would either mean duplicating lots of code from the int > formatter, or having a formatter library that both can call. This is > because __format__ must implement all formats, including padding, > parenthesis for negatives, etc., not just the "missing" binary format. > Not that that's necessarily bad, either. But see the next point. Ah, I had missed the point that it's just binary formatting that you are concerned with (and then I missed that binary is "base 2", rather than "sequence of bits") >> OTOH, also look at _PyString_FormatLong. > > I think a solution would be to add 'b' to _PyString_FormatLong, which > I'm already calling for hex, octal, and decimal formatting. Does that > sound reasonable? It seems to me that if binary is useful enough for > PEP 3101, it should generally be available in _PyString_FormatLong. That sounds fine. > The obvious implementation of this would require adding a nb_binary to > PyNumberMethods. I'm not sure what the impact of that change would be, > but it sounds really big and probably a show-stopper. Maybe a direct > call to a binary formatter would be better. Sure, introducing _PyLong_Dual (or _PyLong_AsDualString) would be appropriate, that can then forward to long_format. > OTOH, this approach isn't as efficient as I'd like (for all formatting > outputs, not just binary), because it has to build a string object and > then copy data out of it. Ah, but that's a proof-of-concept implementation only, right? A "true" implementation should use __format__ (or whatever it's called). If *that* then isn't efficient, you should be worried (and consider introduction of a slot in the type object). > Having written all of this, I'm now thinking that Nick's suggestion of > _PyLong_AsByteArray might be the way to go. I would use that for all of > my formatting for longs. How would you do negative numbers, then? AsByteArray gives you two's complement. > Maybe I'm over-emphasizing performance, given the early status of the > implementation. Most definitely. > But I'd like PEP 3101 to be as efficient as possible, > because once it's available I'll replace all of the '%' string > formatting in my code with it. That is fine. However, don't trade efficiency for maintainability. Keep encapsulation of types, this is what OO is for. Modularize along with type boundaries. If that loses efficiency, come up with interfaces that still modularize in that way but are efficient. Don't "hack" to achieve performance. (Any other way I can formulate the same objective :-?) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
Oleg Broytmann schrieb:
os.path.splitext(".pythonrc")
> ('', '.pythonrc')
>
>and I think it should be
>
> ('.pythonrc', '')
Thanks, so it sounds like the patch should be accepted.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
Miguel Lobo schrieb: > As I am completely new to CPython development, perhaps this problem has > already been discussed and/or fixed I may have done something > incorrectly. Please let me know if that is the case. I looked at it briefly. If I understand correctly, the proposed feature is fine, but lacks a test case. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SVK
A.M. Kuchling schrieb: > I'm happy to write up a wiki page describing how to use SVK to set up > your own mirror of the Python SVN. However, trying it now, the > initial setup seems very slow: SVK is retrieving each of 54165 > revisions and it'll probably take over an hour to complete. If it helps, you can download a snapshot of the entire repository from http://svn.python.org/snapshots/projects-svn-tarball.tar.bz2 This is more than Python, so it depending on your link, it may or may not pay off. You can also try to run the svk conversion on dinsdale, if that helps, so we can provide daily initial svn repositories (if there is such a thing) for download. > (Of course, I don't know how long a checkout of a hypothetical Bazaar > repository would take; maybe it's not any faster.) From my experience with git and the Linux repository, an hour is "about right". People familiar with these tools probably learn to do initial checkouts over night. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
Martin v. Löwis schrieb: > Nick Coghlan schrieb: >> One thing that did happen though (which the messages from Jeremy & Phil >> reminded me of) is that I got a lot of direction, advice and assistance >> from Raymond when I was doing that initial work on improving the speed >> of the decimal module - I had the time available to run the relevant >> benchmarks repeatedly and try different things out, while Raymond had >> the experience needed to suggest possible avenues for optimisation (and >> when to abandon an approach as making the code too complicated to be >> effectively maintained). >> >> I don't know whether or not there is anything specific we can do to >> encourage that kind of coaching/mentoring activity, but I know it was a >> significant factor in my become more comfortable with making contributions. > > While there was no explicit management of a mentoring process, I think > it so happened that committers always found a mentor. It so happened > that some developer activated privileges for them (either himself, or > requesting that this be done), and then certainly feels responsible > for his 'student'. This automatically establishes a mentoring > relationship. Perhaps we should really try to make *that* notion widely known out there, opposed to others like the alleged 5:1 requirement or that it is hard to get patches into the Python core :) A sort of announcement and some text on the website would surely help... Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
At 04:07 PM 3/6/2007 +0100, Martin v. Löwis wrote:
>Oleg Broytmann schrieb:
> > On Tue, Mar 06, 2007 at 04:00:01PM +0100, "Martin v. L?wis" wrote:
> >>>Yes. In .pythonrc.py .pythonrc is the root, and .py is the extension.
> >> Ah, it would do that already: with multiple dots, the last one always
> >> provides the extension.
> >
> >Ah, sorry. I messed it with .split().
>
>Ok - now I'm confused: do you consider this behavior
>(splitext('.pythonrc') == ('', '.pythonrc')) correct
>or not?
I consider it correct, or at the least, don't think it should be changed,
as it would make the behavior more difficult to reason about and introduce
yet another thing to worry about when writing cross-version code.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] locals(), closures, and IronPython...
On Tue, Mar 06, 2007, Andrew Dalke wrote: > On 3/5/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> >> I don't know too many good use cases for >> locals() apart from "learning about the implementation" I think this >> might be okay. > > Since I'm watching this list for any discussion on the traceback > threads, I figured I would point out the most common use I know > for locals() is in string interpolation when there are many local > variables, eg: > >a = "spam" >b = "egg" > ... >y = "foo" >z = "bar" > > print fmtstr % locals() I'll second this one. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "I disrespectfully agree." --SJM ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
On Tue, Mar 06, 2007, Phillip J. Eby wrote:
> At 04:07 PM 3/6/2007 +0100, Martin v. L?wis wrote:
>>
>>Ok - now I'm confused: do you consider this behavior
>>(splitext('.pythonrc') == ('', '.pythonrc')) correct
>>or not?
>
> I consider it correct, or at the least, don't think it should be changed,
> as it would make the behavior more difficult to reason about and introduce
> yet another thing to worry about when writing cross-version code.
That's my primary concern, as well. I'm -0 WRT 2.x; +1 WRT 3.x.
--
Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/
"I disrespectfully agree." --SJM
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
A.M. Kuchling schrieb: > On Tue, Mar 06, 2007 at 09:06:22AM +, Phil Thompson wrote: >> My point is simply that the effort required to review patches seems to be a >> problem. Perhaps the reasons for that need to be looked at and the process >> changed so that it is more effective. At the moment people just seem be >> saying "that's the way it is because that's the way it's got to be". > > Unfortunately I think the effort required is intrinsic to reviewing > patches. Trivial or obviously correct patches get applied quickly, so > the remaining bugs and patches are the ones that are hard to fix. Exactly. I often find myself looking at a patch or bug and turn away thinking "I would need hours to review and check that in, while the developer who originally wrote the code might perhaps do it in much less time". It's not easy to apply patches to code that was written by others and that should stay as compatible as possible for all cases not covered by the patch. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SVK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 6, 2007, at 10:48 AM, Martin v. Löwis wrote: >> (Of course, I don't know how long a checkout of a hypothetical Bazaar >> repository would take; maybe it's not any faster.) > > From my experience with git and the Linux repository, an hour is > "about right". People familiar with these tools probably learn > to do initial checkouts over night. I can't speak to a python-on-bzr, but for another project, doing the initial branch of a huge and deep history took maybe an hour, hour- and-a-half over the network. I know that bzr is trying to improve this. However, by checking out into a repository, once all that history was on my local machine, branching was trivially fast. And if your pushing changes into a remote repository that's up-to-date, that will be very fast too. So yes, there's some initial overhead but with bzr done right, for most subsequent work, there's no perceptible lag due to the scm. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRe2QM3EjvBPtnXfVAQIaSAP/SAoPvqTQZgfG8EDZB6J2hgggAUgWlYun xCtYYtqgnFq0afBOHP1/K1OuD5SFsHghjrLykJjia6TNRC2MpRblk/44Xc5syXCJ aCCJ7t1CLZWMjLjyEpPIcpwBNC6DNfOQYZc28b5BabeIHsF3FqsZb4sIKsSU+dK2 gigs3rjbHRE= =z/vM -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Subversion checkout hanging?
I've had to blast my windows machine, as one is apparently required to do on occasion, and I'm trying to set up subversion again. I saved my private key file, and I can use plink -T to connect and I get: ( success ( 1 2 ( ANONYMOUS EXTERNAL ) ( edit-pipeline ) ) ) and that seems correct, and jives with the FAQ at least. I've also edited my %APPDATA%/Subversion/config file, and I know it was the right one, because I screwed it up at first and it didn't work at all.. :-) However, now I'm just getting a hang when I execute: svn checkout svn+ssh://[EMAIL PROTECTED]/python/trunk I've only let it go for about 5 minutes so far, so maybe it's thinking about something, but I suspect it isn't... Anyone have any idea what I've done wrong? -- Nick ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
George Brandl writes: >> As far as I recall, there has been nearly no one who asked for >> commit rights recently, so why complain that the entry barrier is >> too great? Surely you cannot expect python-dev to got out and say >> "would you like to have commit privileges?"... Why not? It depends on how far out "out" is, but I was surprised how much effect we (at XEmacs) got by simply asking people who contributed a couple of patches if they would like to take on tracking + patch flow management for their own patches in return for direct access to the repository. Giving out authority to approve commits is another matter, but as long as the new people are willing to participate in the mechanics it's generally a management win to have more committers. The answer is more often than not "no, but *thanks for asking*." Merely asking creates an atmosphere of openness and trust. That's a lot, when simply asking that developers of patches consider third parties' use cases is attacked as a "high barrier" to participation. And of course it's the most common path to greater authority. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
On Tue, 6 Mar 2007, Hans Meine wrote: > Am Dienstag, 06. M?rz 2007 13:36 schrieb Martin v. L?wis: > > #1115886 complains that in the file name '.cshrc', the > > entire file name is treated as an extension, with no > > root. > > The current behavior is clearly a bug, since a leading dot does not start an > extension, but marks a file as "hidden". It's not at all clear that current behaviour should be considered a bug . e.g, I think it's reasonable to expect that splitext( a+"." + b) == (a, .b ) for any a,b which have no dots in them... The patch will break this assumption for empty a So, I'd classify dot files as a border case (either behaviour could be viewed as wrong/correct).. In which case backward compatibility should be the primary consideration IMHO Ilya > Greetings, > Hans > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ilya%40bluefir.net > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] locals(), closures, and IronPython...
The lifetime issue is bad - unfortunately we have the same issue in v1.x we
just don't show you the names/values. That alone should (and hopefully will)
drive us to clean this up but right now we'll only be worse in that we are
explicit about keeping the dictionaries alive.
Classes are interesting for us as well... Our model is that we chain all of our
dictionaries together including the classes in FunctionEnvironment's (just an
optimized dictionary, usually only containing the variables used in the
closure) and ultimately that chains out to the globals dictionary. The change
that exposes all of the locals is to drop the explicit list of keys in the
outer scopes. The classes dictionaries get mixed in here as well and so now
when doing a fully dynamic name-lookup we need to know to skip the classes
which is strange.
How would "nonlocals" be used in the method? Wouldn't you need a new opcode
which would resolve to a non-local variable or add it explicitly into the LEGB
search?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Hylton
Sent: Tuesday, March 06, 2007 4:54 AM
To: Dino Viehland
Cc: Guido van Rossum; python-dev@python.org
Subject: Re: [Python-Dev] locals(), closures, and IronPython...
On 3/5/07, Dino Viehland <[EMAIL PROTECTED]> wrote:
> Thanks Guido. It might take some time (and someone may very well beat me to
> it if they care a lot) but I'll see if we can get the PEP started.
Dino,
One of the questions I was puzzling over was what locals() should
return in a class scope. It's confusing in CPython, because the same
dictionary is used to stored names that are destined to become class
attributes and names that are used to created closures for methods
with free variables. The implementation was causing the latter names
to show up as class attributes when you called locals().
Terry is right that lifetime of variables is a key issue. It would
probably be bad if all the local variables of a function were kept
alive because a nested function used locals().
One idea was discussed at PyCon was having a different representation
for an environment so that it would be easier to introspect on it but
still possible to pass the environment to exec. One possibility is
just a third dictionary--globals, locals, nonlocals. Another
possibility is an object where you can ask about the scope of each
variable but also extract a dictionary to pass to locals.
Jeremy
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guido van
> Rossum
> Sent: Monday, March 05, 2007 2:14 PM
> To: Dino Viehland
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] locals(), closures, and IronPython...
>
> Jeremy Hylton has been asking questions about this too at the sprint
> after PyCon. I'm tempted to accept that the exact behavior of locals()
> is implementation-defined (IOW undefined :-) as long as it includes
> the locals defined in the current scope; whether it also includes free
> variables could be debatable. I don't know too many good use cases for
> locals() apart from "learning about the implementation" I think this
> might be okay. Though a PEP might be in order to get agreement between
> users, developers and other implementation efforts (e.g. PyPy,
> Jython).
>
> On 3/5/07, Dino Viehland <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> > def a():
> >
> > x = 4
> >
> > y = 2
> >
> > def b():
> >
> > print y, locals()
> >
> > print locals()
> >
> > b()
> >
> >
> >
> > a()
> >
> >
> >
> > in CPython prints:
> >
> >
> >
> > {'y': 2, 'x': 4, 'b': }
> >
> > 2 {'y': 2}
> >
> >
> >
> > I'm wondering if it's intentional that these don't print dictionaries w/ the
> > same contents or if it's more an accident of the implementation. In other
> > words would it be reasonable for IronPython to promote all of the locals of
> > a into b's dictionary when both a and b call locals?
> >
> >
> >
> > We currently match CPython's behavior here - at least in what we display
> > although possibly not in the lifetimes of objects. We're considering an
> > internal change which might alter the behavior here though and end up
> > displaying all the members.
> >
> >
> >
> >
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > http://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> > http://mail.python.org/mailman/options/python-dev/guido%40python.org
> >
> >
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu
>
___
Python-Dev mailing list
Python-De
Re: [Python-Dev] splitext('.cshrc')
On Tue, Mar 06, 2007 at 08:49:00AM -0800, Ilya Sandler wrote: > I think it's reasonable to expect that > > splitext( a+"." + b) == (a, .b ) > > for any a,b which have no dots in them... Except for an empty 'a', in what case 'b' is the name, not the extension. Well, 'a' cannot be empty because it's the name, but 'b' can be empty. For ".pythonrc.py" ".pythonrc" is the name and ".py" is the extension. For ".pythonrc" ".pythonrc" is the name and there is no extension. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On Wed, Mar 07, 2007 at 01:50:25AM +0900, Stephen J. Turnbull wrote: > Why not? It depends on how far out "out" is, but I was surprised how > much effect we (at XEmacs) got by simply asking people who contributed > a couple of patches if they would like to take on tracking + patch > flow management for their own patches in return for direct access to > the repository. I've been thinking about how other projects handle this. One method is to appoint "maintainers" of specific pieces of functionality. The term "maintainers" was used earlier, but referring only to core developers (those with commit access). I have a somewhat different proposal: In summary, create a layer of volunteer, non-committing maintainers for specific modules who agree to do in-depth analysis of patches for their areas of expertise, and pass well-formed, reviewed patches along to committers. Every part of Python gets a maintainer, annotated in the comments atop the file. A basic process is established for promotion/demotion of maintainers. New patches for a module get sent to that module's maintainer, who checks for well-formedness, functionality, and appropriateness to the module. The *maintainer* can then refer successful patches to the core developers, who can just skim the patch and check that the unit test pass. The core of the interpreter would be implicitly maintained by the core developers, while each module or package of the stdlib is assigned to a specific maintainer (or several, if more are willing). New modules are initially assigned to their author, while existing modules with no apparent maintainer are assigned to a "maintainer-needed" pseudo-maintainer. Patches to maintainer-less modules would languish, unless the submitter stepped up as maintainer, or yelled loudly enough that the core devs processed the pach. I think this would have several advantages: - maintainers can do the basic screening that takes so long and is no fun for core developers - being a maintainer can be a stepping-stone to becoming a full developer, for those who wish to join - patch authors have an advocate "inside the system" Speaking personally, I don't want to be a core developer, but I would be happy to maintain a half-dozen stdlib modules. This is loosely based on the Gentoo project's idea of maintainers (although in Gentoo maintainers must be full developers). Dustin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PCBuild8
I ran into the same problem and I'm pretty sure this cleared it up: http://mail.python.org/pipermail/python-dev/2006-August/068369.html Good luck, Gustavo On 3/5/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Andrew MacKeith schrieb: > Is there a scheduled date for the release of Python-2.5.1 ? There was a scheduled date, but it then interfered with the schedule of the people executing it, so there is none at the moment. I think we will release 2.5.1 in April. > I presume that the PCBuild8 directory should be used when building in 64 > bit on Win64. No. The official binaries both for Itanium and AMD64 (which are both "in 64 bit on Win64") are created with the PCbuild directory. See PCbuild/readme.txt. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/gustavotabares%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
On 3/6/07, Hans Meine <[EMAIL PROTECTED]> wrote: > The current behavior is clearly a bug, since a leading dot does not start an > extension, but marks a file as "hidden". The latter is on UNIX, and while > this is different on Windows, I cannot imagine that anyone would > a) have dotfiles under that OS, or even then > b) rely on the current behavior that their full filename counts as > "extension". FWIW, all of the "standard" Windows functions from the Microsoft CRT (_splitpath) to the Shell API (PathRemoveExtension) to the CLR (System.IO.Path.*) believe that ".cshrc" is the extension of the filename ".cshrc". I'm not sure if that's an argument for or against the patch, though. -- Tim Lesher <[EMAIL PROTECTED]> ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On Tue, 6 Mar 2007, [ISO-8859-1] "Martin v. L?wis" wrote: > Yet, in all these years, nobody else commented that the patch was incomplete, > let alone commenting on whether the feature was desirable. Which actually brings up another point: in many cases even a simple comment by a core developer: "yes this feature is desirable" might be of considerable value as it's likely to increase chances that some other developer will decide to spend time on the patch Similarly, some bug reports are for border cases. A confirmation by a core developer: "yes, that needs fixing" might encourage someone else to submit a patch... I'd also suggest that request for test cases/docs comes after (or together with) suggestion that a feature is desirable in the first place. Ilya > Regards, > Martin > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ilya%40bluefir.net > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Subversion checkout hanging?
Nicholas Bastin schrieb: > I've had to blast my windows machine, as one is apparently required to > do on occasion, and I'm trying to set up subversion again. I saved my > private key file, and I can use plink -T to connect and I get: > > ( success ( 1 2 ( ANONYMOUS EXTERNAL ) ( edit-pipeline ) ) ) > > and that seems correct, and jives with the FAQ at least. I've also > edited my %APPDATA%/Subversion/config file, and I know it was the > right one, because I screwed it up at first and it didn't work at > all.. :-) > > However, now I'm just getting a hang when I execute: > > svn checkout svn+ssh://[EMAIL PROTECTED]/python/trunk > > I've only let it go for about 5 minutes so far, so maybe it's thinking > about something, but I suspect it isn't... > > Anyone have any idea what I've done wrong? You could try to do ssh -vv [EMAIL PROTECTED] and see if the debug messages mean anything to you. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
Phillip J. Eby schrieb: > I consider it correct, or at the least, don't think it should be > changed, as it would make the behavior more difficult to reason about > and introduce yet another thing to worry about when writing > cross-version code. Now it's becoming difficult: several people in favor, some opposed... I'll wait a bit longer, but will still likely commit it, unless opposition gets stronger: If the current behavior is incorrect (in the sense that it contradicts wide-spread intuition), then an application worrying about this detail should surely make the 2.6 behavior also appear in 2.5 and earlier. I'm not sure what people actually use splitext for: I guess there are two applications: a) given a list of file names, give me all those belonging to a hard-coded list of extensions (e.g. .py, .pyc, .c, .h). These won't break, since they likely won't search for "all files ending in .bash_profile" - there is only one per directory, and if the want it, they use the entire filename. b) given a list of file names, classify them for display (the way the Windows explorer works, and similar file managers). They use MIME databases and the like, and if they are unix-ish, they probably reject the current splitext implementation already as incorrect, and have work-arounds. As these files now show up with "no extension", I rather expect that the work-around won't trigger, and the default behavior will be the correct one. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
Ilya Sandler schrieb: > I'd also suggest that request for test cases/docs comes after > (or together with) suggestion that a feature is desirable in the first > place. It depends. I was going through some old patches today, and came across one that added a class to heapq. I couldn't tell (even after reading the code) what precisely all implications are, so I was unable to proceed review beyond "please provide documentation saying what this is for". I would then be able to tell: a) whether it really does what it promises to do, and b) whether this is desirable to have I remember many occasions where a patch was rejected and never reconsidered (even after discussion on python-dev) because the submitter failed to clearly specify what the intention of the change was, as it turned out that the code didn't implement the intention, and people reviewing rejected it because they thought it was meant to do something else (namely, to do what it actually did). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Subversion checkout hanging?
On 3/6/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > You could try to do > > ssh -vv [EMAIL PROTECTED] > > and see if the debug messages mean anything to you. My problem is that SSH works fine if you just try to do that (well, with plink). It's subversion that doesn't seem to be working. -- Nick ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Subversion checkout hanging?
I've fixed it. It appears that there was something wrong with Pageant, and removing my key and readding it solved the problem. The lack of any debugging info from subversion was very helpful in solving this problem.. :-) Thanks for the help from those who responded. -- Nick ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
At 07:24 PM 3/6/2007 +0100, Martin v. Löwis wrote: >given a list of file names, classify them for display (the > way the Windows explorer works, and similar file managers). > They use MIME databases and the like, and if they are unix-ish, > they probably reject the current splitext implementation already > as incorrect, and have work-arounds. I know I've written code like this that *depends* on the current behavior. It's *useful* to classify e.g. .svn directories or .*rc files by their "extension", so I'm honestly baffled by the idea of wanting to treat such files as *not* having an extension (as opposed to a possibly-unrecognized one). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On 3/5/07, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > Any ideas for fixing this problem? The current developer FAQ says: 2.4 How can I become a developer? There's only one way to become a developer, and that's through the School of Hard Knocks. http://mail.python.org/pipermail/python-dev/2002-September/028725.html That's a little glib. And maybe inaccurate. That message (by Raymond Hettinger and probably not originally intended to be the first thing developers-aspirant see) seems at odds with Martin's characterization, in this thread, of Raymond's own experience. I would submit a doc patch, but what's the use. ;) I should be explicit-- I greatly admire the python-dev community and its processes. I don't get the feeling much happens in private e-mail. Quite the opposite: it feels like important decisions are regularly made on python-dev. I don't think it's hard to contribute. I don't think the stdlib is a huge mess of brokenness. And I don't think the community is either. -j ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
Nick> I don't know whether or not there is anything specific we can do Nick> to encourage that kind of coaching/mentoring activity, but I know Nick> it was a significant factor in my become more comfortable with Nick> making contributions. Martin> While there was no explicit management of a mentoring process, I Martin> think it so happened that committers always found a mentor. Could the Summer of Code be used as a vehicle to match up current developers with potentially new ones? The svn sandbox (or a branch) could serve as a place for developers to get their feet wet. Perhaps Raymond can comment on whether he thinks that makes sense based upon his experience mentoring the Decimal-in-C module. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
On 3/6/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 07:24 PM 3/6/2007 +0100, Martin v. Löwis wrote: > >given a list of file names, classify them for display (the > > way the Windows explorer works, and similar file managers). > > They use MIME databases and the like, and if they are unix-ish, > > they probably reject the current splitext implementation already > > as incorrect, and have work-arounds. > > I know I've written code like this that *depends* on the current > behavior. It's *useful* to classify e.g. .svn directories or .*rc files by > their "extension", so I'm honestly baffled by the idea of wanting to treat > such files as *not* having an extension (as opposed to a > possibly-unrecognized one). My argument would be that the file is not 'unnamed', with an extension of 'cshrc'. The file is actually called 'cshrc', and the '.' is metadata that is attached to tell the shell to hide the file. Assuming that we want ot be ignorant of shell semantics (and I think we do), then the file is called '.cshrc', and it has no extension. The notion of an unnamed file with an extension I think would be very odd to most people. +1 to changing the behaviour to return .cshrc as the filename, with no extension. -- Nick ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >1. Public identification will not help, because: >2. most code isn't in the responsibility of anybody (so publically >identifying responsibilities would leave most code unassigned), and >3. for the code that has some responsible member, things are already >fine (so public identification won't improve here) If I were looking for an 'ophan' (python-coded) module to adopt, then such a list would help me choose. It would also be helpful if the new tracker system could produce a list of module-specific open items sorted by module, since that would indicate modules needing attention, and I could look for a batch that were unassigned. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Finding the python library binaries (and docs)
I'm trying to find the Python library binaries associated with a given python executable. If I look at the help for sys.prefix and sys.exec_prefix import sys; help(sys) I see: prefix -- prefix used to find the Python library exec_prefix -- prefix used to find the machine-specific Python library This text is somewhat ambiguous, but from the fact that exec_prefix refers to the "machine-specific" Python library I'm led to guess that prefix's "the Python library" refers to the *.py* files that form most of the Python standard library, and "the machine-specific Python library" perhaps refers to the library binaries such as libpython25.a. However, neither of those interpretations seems to correspond to reality. My guess is that these constants correspond to the --prefix and --exec_prefix options to the configure script invocation that was used to build Python. What I'm really looking for, I think, is the directory corresponding to the --libdir option to configure, but I don't see that in sys. If I look at "configure --help," it claims the default libdir is EPREFIX/lib, so I suppose I could look in sys.exec_prefix+'/lib', but when I look at real installations I find only the shared libraries in that location. For the static libraries, I have to look in EPREFIX/lib/python$(version)/config/, and in fact there is a symlink there to the shared libs. So: 1. I think the documentation for sys and configure both need some updating 2. I'd like to know if there's an officially correct procedure for finding the library binaries associated with a Python executable. Thanks in advance, -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
At 02:08 PM 3/6/2007 -0500, Nicholas Bastin wrote: >The notion of an unnamed file with an extension I think would be very >odd to most people. Clearly, we all think that "most" people are like ourselves. :) I think that for someone with a Windows/DOS background, that's *exactly* what .cshrc looks like! (IIRC in DOS, *every* file has an extension, such that 'foo' and 'foo.' refer to the same file.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
On 3/6/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> It's *useful* to classify e.g. .svn directories or .*rc files by their
> "extension"
I respectfully disagree. When trying to find directories named .svn or
files named .bashrc, I do
>>> filename in ('.svn', '.bashrc')
because I don't expect filenames like foo.svn or bar.bashrc -- have
you ever seen one? These are not "extensions" for me.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
dustin> In summary, create a layer of volunteer, non-committing dustin> maintainers for specific modules who agree to do in-depth dustin> analysis of patches for their areas of expertise, and pass dustin> well-formed, reviewed patches along to committers. One problem with this sort of system is that it's difficult for many people to commit the personal resources necessary over a long period of time. Life often gets in the way. Consider the rather simple task of fielding submissions to the Python job board. I think three or four different people who have taken care of that task over the last two or three years. In each case the transition to a new person was a bit bumpy because life sort of jumped up an bit the current maintainer in the butt, leaving a scramble to find a new person to take over that role. Now consider how simple that is compared with, say, being the Python XML guru. Let's say Fred Drake takes on that role. (I'm not picking on Fred. My brain just associates him with XML-in-Python, rightly or wrongly.) Things go swimmingly for awhile, then he gets a huge load dumped on him at work, his wife has a baby and the family moves to Austin, TX to be close to his aging parents. After moving to Austin it takes a month to get a properly functioning Internet connection because the phone company is so lame. I think it's understandable that his level of committment to XML-in-Python might be reduced. Other events in his life might take over to such an extent that he forgets to (or can't easily) let anyone know. It's not until someone happens to notice (maybe Fred, maybe Martin, maybe nobody for quite awhile) that there are a bunch of XML-related bug reports and patches piling up that the team starts looking for someone new to assume that role. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On Tue, Mar 06, 2007 at 01:03:39PM -0600, [EMAIL PROTECTED] wrote: > Could the Summer of Code be used as a vehicle to match up current developers > with potentially new ones? The svn sandbox (or a branch) could serve as a > place for developers to get their feet wet. Perhaps Raymond can comment on > whether he thinks that makes sense based upon his experience mentoring the > Decimal-in-C module. Gregory Johnson, who did the rewrite of mailbox.py in the 2005 SoC, did a very good job; the module went into 2.5 and, judging by the few bug reports that have come in, gained some users pretty quickly. He also vanished after SoC was over, which is unfortunate, but not due to anything in my mentoring (I hope!). --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Subversion checkout hanging?
Nicholas Bastin schrieb: > I've had to blast my windows machine, as one is apparently required to > do on occasion, and I'm trying to set up subversion again. I saved my > private key file, and I can use plink -T to connect and I get: > > ( success ( 1 2 ( ANONYMOUS EXTERNAL ) ( edit-pipeline ) ) ) > > and that seems correct, and jives with the FAQ at least. I've also > edited my %APPDATA%/Subversion/config file, and I know it was the > right one, because I screwed it up at first and it didn't work at > all.. :-) > > However, now I'm just getting a hang when I execute: > > svn checkout svn+ssh://[EMAIL PROTECTED]/python/trunk > > I've only let it go for about 5 minutes so far, so maybe it's thinking > about something, but I suspect it isn't... > > Anyone have any idea what I've done wrong? I would verify that you were indeed passing [EMAIL PROTECTED] to plink. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >I consider it correct, or at the least, don't think it should be changed, >as it would make the behavior more difficult to reason about and introduce >yet another thing to worry about when writing cross-version code. Windows did not allow .xxx as a filename in my attempts, so this case seems irrelevant there. tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On Tue, Mar 06, 2007 at 01:51:41PM -0600, [EMAIL PROTECTED] wrote: > > dustin> In summary, create a layer of volunteer, non-committing > dustin> maintainers for specific modules who agree to do in-depth > dustin> analysis of patches for their areas of expertise, and pass > dustin> well-formed, reviewed patches along to committers. > > One problem with this sort of system is that it's difficult for many people > to commit the personal resources necessary over a long period of time. Life > often gets in the way. This is *definitely* the core problem with this system, and has plagued every project to use a variant of it (including many small projects with only one developer who takes months to respond to email). I think one *advantage* of this system would be that, with patch submitters having a specific person to whom their patches should be addressed, non-responsiveness on that person's part would be detected and brought to the community's attention more quickly. It would help a great deal to have a very formalized system in place for promoting/demoting maintainers -- email templates with filterable subject lines and specific addresses to send them to, specific expected response times, etc. As someone else said in another thread, we all think that everyone thinks like us (I think that's tautological?). My thinking is that a lot of people like me would love to have a small "corner of Python" for which they are responsible. Dustin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
Neal Norwitz wrote: > I recognize there is a big problem here. Each of us as individuals > don't scale. So in order to get stuff done we need to be more > distributed. This means distributing the workload (partially so we > don't burn out). In order to do that we need to distribute the > knowledge. That probably involves some changes. Neil with deep insight states... """In order to do that we need to distribute the knowledge.""" + 1000 I'm looking forward to a new tracker and hope it manages single projects... (patches and bugs) better. It would be great if we could search for items based on possibly the following conditions. patch_complete patch_reviewed patch_approved test_complete test_reviewed test_approved doc_complete doc_reviewed doc_approved For new features: pep_completed pep_reviewed pep_approved Finally: (after all the above applicable conditions are true) accept_reject (python-dev (or BDFL) approval) [*] *Note: Rejections could be done sooner if it obviously a bad idea. In the case of bugs, the tests would probably come first in order to verify and reproduce the specific bug. What something like this would do is effectively distribute knowledge as you suggest. For example someone good at writing docs could do a search for all patches that do not have doc's or need docs reviewed and contribute in that way. The same for someone interested in writing and reviewing tests. It would also be easy for python core developers to get a list of items that are completed *and* are reviewed and then go through those items that are up for final approval on py-dev on a regular schedule. If it's determined there still needs to be work on any one item, they can clear the specific flags, (needs better tests, clear all test flags, with a suggestion of action), Then when it is fixed and re-reviewed it will come up for final approval again when the next final patch review period comes around. (or sooner if a core developer wants to push it though.) > I understand it's really hard to get involved. It can be frustrating > at times. But I think the best way is to find a mentor. Find an > existing core developer that you relate to and/or have similar > interests with. I've been trying to do this more. > > So here's my offer. Anyone who is serious about becoming a Python > core developer, but doesn't know how to get involved can mail me. > Privately, publicly, it doesn't matter to me. I will try to mentor > you. Cool! Thanks. > Be prepared! I will demand submissions are high quality which at a > minimum means: > > - it adds a new test, enhances an existing test or fixes a broken test > - it has *all* the required documentation, including > versionadded/versionchanged > - most people think the feature is desirable > - the code is maintainable and formatted according to the prevailing style > - we follow the process (which can include improving the process if > others agree) > ie, there's no free lunch, unless you work at Google of course :-) > > It also means you are willing to hold other people up to equally high > standards. I wouldn't expect less. > Your contributions don't have to be code though. They can be doc, > they can be PEPs, they can be the python.org website. It could even > be helping out with Google's Summer of Code. The choice is yours. I wonder if a tracker could also have patch requests. Similar to bugs, except it's more of a todo list. Oh, never mind there is a feature request group already. Could that possibly be extended to other areas? _Ron ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
> As I am completely new to CPython development, perhaps this problem has > already been discussed and/or fixed I may have done something > incorrectly. Please let me know if that is the case. I looked at it briefly. If I understand correctly, the proposed feature is fine, but lacks a test case. I have now added a test case. Please let me know if anything else is needed. Thanks, Miguel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
Terry Reedy wrote:
> "Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> I consider it correct, or at the least, don't think it should be changed,
>> as it would make the behavior more difficult to reason about and introduce
>> yet another thing to worry about when writing cross-version code.
>
> Windows did not allow .xxx as a filename in my attempts, so this case seems
> irrelevant there.
Windows is a bit funny there. You can't create a ".xxx" filename
in Explorer, but you can from Console/the API:
import os
f = open (".xxx", "w")
f.close ()
os.path.isfile (".xxx")
# True
Not that this helps anything, really, but just
to make the point :)
TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] how can I review? [was: Encouraging developers]
The 5:1 patch review is a good idea -- but what is the procedure for reviewing a patch? I often comment on patches. Does this count as a review? Would anyone know if it did? If I were going through five at the same time, and I had a sixth to push, I could post here. Normally, I just make a comment on the SF tracker. As far as I know, that makes zero difference to any committer (at least) until they have already decided to look at the issue themselves. At best, I am shaving off a round of back-and-forth, if there would have been one. Sometimes all I say is "What about case X"? The patch isn't ready to be committed yet. It might be that comments are enough, but it isn't ready. I wouldn't want the fact fact that I commented to grab a committer's attention. Sometimes the patch is good, or they deal with all issues.[1] At that point, I ... stop commenting. I don't know of any way (except personal email) to indicate that it was reviewed, let alone approved. [1] Well, all that I noticed at the time -- I don't have a checklist, and there isn't a standard review form. One option would be a designated wiki page listing who reviewed patches when and whether they are ready -- but it seems sort of heavyweight, like it ought to be part of the tracker. I do like Dustin's suggestion (http://mail.python.org/pipermail/python-dev/2007-March/071598.html) If some committers are interested (and tell me how they want the review notification), I would be happy to pre-filter some stdlib patches. If there are several volunteers wanting to split the work, I would be willing to organize the split however the others prefer. -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding socket timeout to urllib2
Guido van Rossum wrote:
>> - I'll modify urlopen for it to accept a socket_timeout parameter,
>> default to None
>
> I'd call it timeout. There can't really be much ambiguity can there?
Yes and no. For example, if I do a
``urllib2.urlopen("ftp://ftp.myhome.com.ar/blah.txt";, timeout=10)``, the
timeout is about the socket or about the file transfer?
> I say your next step should be to submit a patch, perhaps
> incorporating the work that Skip has already done.
Ok.
> You could also reduce the amount of work to be done initially by only
> handling http. At this point I expect that'll cover 99% of all uses.
Me too, I suggested ftplib for being cleaner...
Thanks.
--
. Facundo
.
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
Phillip J. Eby schrieb: > I know I've written code like this that *depends* on the current > behavior. It's *useful* to classify e.g. .svn directories or .*rc files > by their "extension", so I'm honestly baffled by the idea of wanting to > treat such files as *not* having an extension (as opposed to a > possibly-unrecognized one). I never considered it an extension. Ask 10 people around you to see what a leading dot on Unix in a file name means, and I would be suprised if more than one answered "it separates the file name from the extension". Most of them likely include "hidden file" in their answer, and the rest (of those who know anything about it) will say "dotfiles, not displayed by ls, and not included in globbing". It really is a *different* dot from the one that separates the file name from its extension. I also fail to see why it is useful to invoke splitext on a file name to find out whether it is .svn - I would rather check the file name itself. It's unfortunate, of course, that people apparently relied on this behavior (is the code you are referring to publicly available? If so, where?) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
At 02:55 PM 3/6/2007 -0500, Terry Reedy wrote: >"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] > >I consider it correct, or at the least, don't think it should be changed, > >as it would make the behavior more difficult to reason about and introduce > >yet another thing to worry about when writing cross-version code. > >Windows did not allow .xxx as a filename in my attempts, so this case seems >irrelevant there. Huh? .xyz files work fine on Windows. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finding the python library binaries (and docs)
David Abrahams schrieb: > I'm trying to find the Python library binaries associated with a given > python executable. This really isn't a python-dev question; please use python-list (news:comp.lang.python) instead. Please take a look at sys.path. > 1. I think the documentation for sys and configure both need some > updating Would you like to work on a patch? This information can be readily obtained from the Python source code. > 2. I'd like to know if there's an officially correct procedure for > finding the library binaries associated with a Python executable. Yes (although I'm not sure what a "library binary" is). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] how can I review? [was: Encouraging developers]
Jim> The 5:1 patch review is a good idea -- but what is the procedure Jim> for reviewing a patch? Jim> I often comment on patches. Does this count as a review? Would Jim> anyone know if it did? I believe "review" can mean a few things: * Comments. Reviewing the code does it look reasonable to you given your experience in the space the patch is playing in? Is it missing anything (test cases, documentation, platform dependencies)? * Apply it in your sandbox and try it out. Does the Python test suite pass? Does it work with your applications? * Extend it. If it's missing platform dependencies, test cases or documentation and you can supply (any of) them, feel free to do so. Open a new patch and add a comment to the current tracker item containing a reference to it. (In SourceForge at least you won't be able to attach a file to a tracker item you didn't create or don't own. YMMV once the Rapture occurs and we get to RoundUp nirvana.) Generally, once you've reviewed the five, post a note here referencing them and also referring to the item you would like reviewed. (Personally, if you take a tracker item from "clearly can't be committed as is" to "this is good to go" I think the five review bar should be lowered.) Jim> Sometimes the patch is good, or they deal with all issues.[1] At Jim> that point, I ... stop commenting. "Works for me" and "looks good to me" are also valid comments. ;-) Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
Martin v. Löwis wrote:
Ok - now I'm confused: do you consider this behavior
(splitext('.pythonrc') == ('', '.pythonrc')) correct
or not?
+1 on the behavior. However, the patch is special-casing a leading dot;
it would still fail on splitext(".."). If we're gonna fix the bug, I'd
rather we fixed it dead.
What follows is a cross-platform splitext(). It passes all the tests I
threw at it, also attached. If there is interest, I would be happy to
submit it as an alternate patch. If runtime speed is paramount, I could
lose the portability, and instead port my patch into all three *path.py
files natively (dropping os.sep and os.altsep).
Hope this helps,
/larry/
--
import os
def splitext(f):
sepIndex = f.rfind(os.sep)
if os.altsep:
altsepIndex = f.rfind(os.altsep)
sepIndex = max(sepIndex, altsepIndex)
dotIndex = f.rfind(".")
if dotIndex > sepIndex:
# skip all leading dots
filenameIndex = sepIndex + 1
while filenameIndex < dotIndex:
if f[filenameIndex] != '.':
return f[:dotIndex], f[dotIndex:]
filenameIndex += 1
return f, ''
def splitextTest(path, filename, ext):
assert splitext(path) == (filename, ext)
assert splitext(os.sep + path) == (os.sep + filename, ext)
assert splitext("abc" + os.sep + path) == ("abc" + os.sep + filename, ext)
assert splitext("abc.def" + os.sep + path) == ("abc.def" + os.sep +
filename, ext)
if os.altsep:
assert splitext(os.altsep + path) == (os.altsep + filename, ext)
assert splitext("abc" + os.altsep + path) == ("abc" + os.altsep +
filename, ext)
assert splitext("abc.def" + os.altsep + path) == ("abc.def" +
os.altsep + filename, ext)
splitextTest("foo.bar", "foo", ".bar")
splitextTest("foo.boo.bar", "foo.boo", ".bar")
splitextTest("foo.boo.biff.bar", "foo.boo.biff", ".bar")
splitextTest(".csh.rc", ".csh", ".rc")
splitextTest("nodots", "nodots", "")
splitextTest(".cshrc", ".cshrc", "")
splitextTest("...manydots", "...manydots", "")
splitextTest("...manydots.ext", "...manydots", ".ext")
splitextTest(".", ".", "")
splitextTest("..", "..", "")
splitextTest("", "", "")
//
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding socket timeout to urllib2
On 3/6/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> >> - I'll modify urlopen for it to accept a socket_timeout parameter,
> >> default to None
> >
> > I'd call it timeout. There can't really be much ambiguity can there?
>
> Yes and no. For example, if I do a
> ``urllib2.urlopen("ftp://ftp.myhome.com.ar/blah.txt";, timeout=10)``, the
> timeout is about the socket or about the file transfer?
Think of it this way. "Timeout" doesn't mean the whole thing needs to
be completed in 10 secs. It means that over 10 secs of no activity
causes it to be aborted.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] how can I review? [was: Encouraging developers]
Jim Jewett schrieb: > The 5:1 patch review is a good idea -- but what is the procedure for > reviewing a patch? > > I often comment on patches. Does this count as a review? Sure. Ideally, a review should bring the patch to an "accept-or-reject" state, i.e. it should lead to a recommendation to the committer. An explanation should include the reasoning done (eg. for accept: useful feature, complete implementation, for reject: patch is incomplete, has undesirable side effects). However, in that 5:1 deal, any kind of review was good in the past, even though it doesn't lead to a decision. > Would anyone know if it did? I often see your reviews (thanks!), but I don't keep track. > If I were going through five at the same time, and I had a sixth to > push, I could post here. Normally, I just make a comment on the SF > tracker. As far as I know, that makes zero difference to any > committer (at least) until they have already decided to look at the > issue themselves. At best, I am shaving off a round of > back-and-forth, if there would have been one. Indeed. That is already useful, although it might help more if you stated a recommendation (I know you do in many cases). If you have a list of patches that you think are ready for decision, please post the list here, listing clear accepts and clear rejects. For uncertain cases, you can try to start a discussion; make your lay out pros and cons and explain what side you are leaning to. > Sometimes all I say is "What about case X"? The patch isn't ready to > be committed yet. It might be that comments are enough, but it isn't > ready. I wouldn't want the fact fact that I commented to grab a > committer's attention. If you think the patch is not complete, state so: "It is not complete because it doesn't support case X". If the submitter doesn't respond, you can consider revising it yourself, if you think the patch is important, or recommend rejection (if you think it isn't that relevant). > Sometimes the patch is good, or they deal with all issues.[1] At that > point, I ... stop commenting. I don't know of any way (except > personal email) to indicate that it was reviewed, let alone approved. For the record, state your position in a comment. It is important to record what position people have on patches they reviewed. If they merely review, and then don't communicate their findings, it is wasted time. > One option would be a designated wiki page listing who reviewed > patches when and whether they are ready -- but it seems sort of > heavyweight, like it ought to be part of the tracker. I agree. Maybe we should add some "reviewed by" field to the roundup tracker where reviewers can record that they brought the patch to a state ready for committing/final rejection (I think a second check is still needed, as the case of splitext shows: you were in favor of rejecting it because of the incompatibility, but it looks like the majority of users is in favor of accepting because they consider the current behavior buggy). > If some committers are interested (and tell me how they want the > review notification), I would be happy to pre-filter some stdlib > patches. If there are several volunteers wanting to split the work, I > would be willing to organize the split however the others prefer. Not sure how you are organizing this work: If you have completed a review (i.e. so that just some technical action would need to be taken), feel free to post to python-dev (ideally with a python.org/sf/number link so people can easily follow your analysis), with a subject like "recommend for rejection/acceptance". The tricky ones are really the incomplete ones: if neither the submitter nor you yourself feel like completing the patch, posting to comp.lang.python might also reveal some contributors. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
Larry Hastings schrieb: > Hope this helps, Indeed it does! After all this discussion, a documentation clarification is certainly in order, but I can work that out myself. Thanks, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finding the python library binaries (and docs)
on Tue Mar 06 2007, "Martin v. Löwis" wrote: > David Abrahams schrieb: >> I'm trying to find the Python library binaries associated with a given >> python executable. > > This really isn't a python-dev question; please use python-list > (news:comp.lang.python) instead. I wrestled with the right list for this one and determined that only the python devs would know the answers. Also I intended to propose that the information I'm looking for be added to sys as a standard attribute. > Please take a look at sys.path. No help at all; that is the module search path (i.e. for .py files), not for the Python library binaries. >> 1. I think the documentation for sys and configure both need some >> updating > > Would you like to work on a patch? This information can be readily > obtained from the Python source code. I'll consider it, once we get the original intention cleared up. There are lots of ways to interpret what the code actually does, and documentation that merely transcribes the code's logic will not be very useful. >> 2. I'd like to know if there's an officially correct procedure for >> finding the library binaries associated with a Python executable. > > Yes (although I'm not sure what a "library binary" is). I gave one example in my post: libpython25.a -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
Terry Reedy schrieb: > It would also be helpful if the new tracker system could produce a list of > module-specific open items sorted by module, since that would indicate > modules needing attention, and I could look for a batch that were > unassigned. The new tracker will initially have the same "category" as the current one, but it will have the ability to group by them (and perhaps even count them). Of course, many bugs don't have a category set, so some volunteer would first need to go through all open bugs and categorize them. If, for "Modules", you want a more fine-grained classification, it would be possible to add new categories, or add another field "affected modules" (multi-list, I assume). If there is a volunteer that would like to go through all bug reports and classify them according this finer category, I can work with the roundup maintainers to add that (although it will likely only happen after the switch to roundup - it is easy to extend the schema with additional fields if it is known exactly what they are). There is also a generic "keywords" field in the roundup tracker - perhaps the "affected modules" could become keywords. HTH, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
At 10:01 PM 3/6/2007 +0100, Martin v. Löwis wrote: >It's unfortunate, of course, that people apparently relied on >this behavior I was going to say it's the *documented* behavior, but I see that the documentation is actually such that it could be interpreted either way. However, since it's not documented more specifically, it seems perfectly reasonable to rely on the implementation's behavior to resolve the ambiguity. >(is the code you are referring to publicly available? No, and I don't know if it's still being used, although it probably is. But it might also still be running on Python 2.2, and I'm not sure if any of its actual uses are actually affected by such dotted files, or whether the code will ever be upgraded to more recent Python versions. I haven't worked at the company in question for a few years now. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finding the python library binaries (and docs)
David Abrahams schrieb: > on Tue Mar 06 2007, "Martin v. Löwis" wrote: >> David Abrahams schrieb: >>> I'm trying to find the Python library binaries associated with a given >>> python executable. >> This really isn't a python-dev question; please use python-list >> (news:comp.lang.python) instead. > > I wrestled with the right list for this one and determined that only > the python devs would know the answers. That absolutely cannot be the case. Python is open source, you have *everything* you need to answer this question. >>> 2. I'd like to know if there's an officially correct procedure for >>> finding the library binaries associated with a Python executable. >> Yes (although I'm not sure what a "library binary" is). > > I gave one example in my post: libpython25.a Ah, ok. If you want to know where that is installed (officially), check out what "make install" does. Also, ask yourself whether you know a Python module that should know how to find it. distutils and freeze come to mind. HTH, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3000 upgrade path
On 3/5/07, Facundo Batista <[EMAIL PROTECTED]> wrote: > Thomas Wouters wrote: > > > developers and people who develop their own software. I would like to hear > > from people who have concrete doubts about this upgrade path. I don't mean > > Disclaimer: I'm not involved in Py3k, and not even tried it once. And > don't know the details of the tool to "transform" Py2 to Py3. > > Having said that, the *only* fear I have, is how safe it will be. And > here comes the explanation. > > I'm now in an enviroment where we rely on Python, and I advocates on it > everyday. We use 2.3, and 2.4, some servers we're about to deploy have > 2.5, and we'll use the lastest Py2.x everytime we deploy a new machine. > > But, as we have always running behind our ToDo, we don't have time to > say "Ok, this server runs 2.3, how can I start using 2.5?". Too many > servers, too many applications, too many > undocumented-and-nobody-knows-about-it applications. And they all are > applications running 7x24. I know the feeling. Google still uses Python 2.2 for most apps. We're supporting 2.4 as well, and hope to have the last apps migrated to 2.4 in a year or so. *Then* we'll start supporting a higher version -- probably 2.6 by then. > And Py3k is around the corner, and I even heard some guys saying "If I'd > spent time taking care that this app runs ok after changing a bit of > it, I'll wait to Python 3000". In your kind of env it's clearly too early to think about 3.0. You shouldn't expect to be switching until a year after 3.0 is released, probably. > So, the enviroment is explained, now I go with "how safe it will be". > I'd love to know that there'll be a tool that tells me, after running it > over my application, Your app is "ready for migration"'. I do *not* care > if it takes a lot of work to make the proper changes, but I need to feel > confident that after running the last changed version during a week in, > say, Py2.7, and no warnings appear, and the "verification tool" say > green light, I can start running it in Py3k. And look at it a week more. > And say "life is great", :) You need comperhensive unit tests too. Then: *If* you get the green light from 2.6's py3k warning mode, *and* the conversion tool produces syntactically correct code without issuing warnings, *and* your unit tests all pass, *then* I expect you'll be in about the same situation as for any version upgrade in such an environment (e.g. 2.4 -> 2.5). I.e. you need to do a big integration test and once that passes you should be set for a stress-free transition. I think that's the best we can hope for. I plan to do it this way at Google too. > Anyway, I know how hard is it, and I regret not having the time I'd love > to have to help you. All I can do is thank you. > > Thank you very much! You're welcome! > > One thing in particular I wonder about is the warning about mixing tabs and > > spaces. Should it be in category 2) (on by default) or 3) (still off by > > default, but part of -Wpy3k)? > > For me, I'd love to 2.6 start warning "you're mixing tab and spaces, > shame yourself!". (The English say "shame on you" :-) While I'd like to do this too I don't know how many folks there are out there who have no way to suppress the warning (because they're end users of a script someone else wrote for them). I think it may be more of a development warning, so I think category is appropriate. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
Phillip J. Eby schrieb: > At 10:01 PM 3/6/2007 +0100, Martin v. Löwis wrote: >> It's unfortunate, of course, that people apparently relied on >> this behavior > > I was going to say it's the *documented* behavior, but I see that the > documentation is actually such that it could be interpreted either way. > > However, since it's not documented more specifically, it seems perfectly > reasonable to rely on the implementation's behavior to resolve the ambiguity. Sure, it is an incompatible change, no doubt. However, incompatible changes are "ok" for feature releases (not so fo bugfix releases). So this being an incompatible change alone is not a reason to reject the patch. Significant breakage in many applications might be, but I don't expect that for this change (which is really tiny). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
