Re: [Python-Dev] A wart which should have been repaired in 3.0?
2008/12/31 Phillip J. Eby : > Change that to [os.path.normpath(p)+'/' for p in paths] and you've got > yourself a winner. s#'/'#os.sep# to make it work on Windows as well :-) Have we established yet that this is hard enough to get right to warrant a stdlib implementation? Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A wart which should have been repaired in 3.0?
pobox.com> writes: > > which leads me to believe that other people using the current function in > the real world would be confused by your interpretation. ... and are vulnerable to security hazards. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A wart which should have been repaired in 3.0?
Phillip J. Eby wrote: > At 09:30 PM 12/30/2008 -0500, [email protected] wrote: >> On Tue, 30 Dec 2008 at 17:51, Phillip J. Eby wrote: >>> At 02:32 PM 12/30/2008 -0800, Scott David Daniels wrote: More trouble with the "just take the dirname": paths = ['/a/b/c', '/a/b/d', '/a/b'] os.path.dirname(os.path.commonprefix([ os.path.normpath(p) for p in paths])) give '/a', not '/a/b'. >>> >>> ...because that's the correct answer. >> >> But not the answer that is wanted. >> >> So the challenge now is to write a single expression that will yield >> '/a/b' when passed the above paths list, and also produce '/a/b' when >> passed the following paths list: >> >> paths = ['/a/b/c', '/a/b/cd'] > > Change that to [os.path.normpath(p)+'/' for p in paths] and you've got > yourself a winner. > Or possibly [os.path.normpath(p)+os.path.sep for p in paths]? regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
Le Wednesday 31 December 2008 08:46:09 Stephen J. Turnbull, vous avez écrit :
> Would you review your own code in the same way that other committers
> review their own?
I'm unable to review my own code. I always re-read my code and test it, but I
can not see every possibles cases. That's why I prefer external eyes to
review my code for parts of the code that I don't understand/known well
enough.
> Would you make the same decisions about which fixes to commit,
> which changes to wait for others' review, and which to propose
> on Python-Dev first?
I think that I'm able to know if a patch needs a review or not. Especially if
the patch changes the behaviour or the API (or if the patch is complex), I
always prefer a review.
I will not use svn as I use the tracker. Sometimes, I write a quick and dirty
patch to demonstrate a feature or to propose a solution to fix the bug. If
the solution is accepted, I try to write a better patch.
> > The bigger patch was the bytes filename support for Python3,
> > accepted by Guido (after a long review ;-)).
>
> Would you have committed that patch if nobody else had reviewed it?
Certainly not. The patch changed the behaviour of most functions related to
files. The mailing list + the bug tracker were the right tools.
> > Just because there are not enough people to review/commit patches
> > on the tracker and
>
> Are you planning to review and commit other people's patches, and help
> reduce this backlog? Or just your own?
It depends on the issue. There are many trivial fixes that doesn't change the
behaviour / API but just improve the project and are waiting for a review or
are reviewed but not commited yet.
About my own patch: yes, I would like to use direclty on the svn without using
the tracker to fix trivial bugs. Example: during one month, there were two
gcc warnings in _testcapi module. The fix was trivial and it requires too
much efforts to open an issue for such stupid warning.
> Again, I'm more supportive of
> people who want commit privileges in part to help improve the
> project's process, as well as to remove obstacles to their own work.
My not-so-secret goal is also to improve Python stability against fuzzing. I
stopped to work on fuzzing because it took sometimes months to fix a dummy
bug (dummy : easy to understand but also easy to fix without side effects).
Example of such issue: "import _tkinter; _tkinter.mainloop()" crashs Python
(maybe not directly but later on garbage collection). I opened the issue
(with a patch) in august, gpolo reviewed the patch ("Looks fine to me.") two
weeks later, but 4 months later the isue is still open:
http://bugs.python.org/issue3638
Is it was you called "An open issue is not a lost patch."?
> An open issue is not a lost patch. It's an open issue. In my own
> projects, I oppose candidates who seem to think that the presumption
> is that a patch should be applied quickly unless there's good reason
> given not to. Your phrasing suggests that attitude to me.
Even after a review, some issues stay open for months or years.
Another example of issue: nntplib doesn't support IPv6, dmorr proposed a
simple and good patch reusing the nice function socket.create_connection()
one year ago. In this case, I think that nobody was able to test the change.
But without testing it, I'm sure that the patch is better than the current
situation. Well, if I have to commit the patch, I will test it before. My
computer has a public IPv6 address :-)
http://bugs.python.org/issue1664
> You don't have to pay attention to me,
No, your opinion is interresting. I hope that my answers will help you to
understand my expectations about an svn account :-)
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] opcode dispatch optimization
Hello, I would like to mention that I've written a patch which enables "threaded interpretation" on the ceval loop with gcc (*). On my computer (an Athlon X2 3600+), it is good for a 15-20% speedup of the interpreter on pystone and pybench. I also had the opportunity to test it on a Core2-derived CPU, where it doesn't make a difference (I conjecture it's because Core2 CPUs have hardware-based indirect branch optimizations). It will make no difference if the interpreter is compiled with something else than gcc (I tested on Windows). The additional complexity is very small. There's a separate script which is run to build the dispatch table (only if needed, that is if dis.py has been modified). In ceval.c, there are a couple of macros and some #ifdef's. That's all. It breaks no test in the regression suite. Could other people test and report their results here? (the patch is for py3k, btw). Also, what are you thoughts for/against integrating this patch in the standard interpreter? Regards Antoine. (*) please note: it has nothing to see with multithreading. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] opcode dispatch optimization
Antoine Pitrou pitrou.net> writes: > > I would like to mention that I've written a patch which enables "threaded > interpretation" ... and I forgot to give the URL: http://bugs.python.org/issue4753 Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
Victor Stinner writes: > Le Wednesday 31 December 2008 08:46:09 Stephen J. Turnbull, vous avez écrit : > > Would you review your own code in the same way that other committers > > review their own? > > I'm unable to review my own code. Of course not, in the formal "software process" sense. But in some sense to commit code you have to have reviewed it, that's all I meant. > Is it was you called "An open issue is not a lost patch."? Yes, and I'll say it again: > > An open issue is not a lost patch. It's an open issue. > Even after a review, some issues stay open for months or years. There *is* a process problem, though I don't claim to have an idea how to solve it. Some developers (especially well-known is Martin van Loewis) are trying to address this with the "one committer's review for five reviews" offer, but maybe there are even better ways to do it. However, this is a *different problem* from "lost patches", which many projects do suffer from, and shouldn't be called by that name, which is insulting to the Python committers. In particular, we know that effort is devoted to tracking open issues by the developers, both individually and as a formal matter (the weekly report). It is insufficient in some sense, but way better than, say, in XEmacs (a project I'm supposed to be leading :-/ ). And IIRC the statistics show that the number of issues closed is of the same order of magnitude as those opened, although consistently lower by 10-20%. Actually, I think that's pretty amazing for a project that has nobody whose salary depends on getting the numbers up. > > You don't have to pay attention to me, > > No, your opinion is interresting. I hope that my answers will help you to > understand my expectations about an svn account :-) Well, as I say I have no vote. But I hope your answers will help to convince any doubters among the committers. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] lost patches
Hi, Stephen J. Turnbull xemacs.org> writes: > > There *is* a process problem, though I don't claim to have an idea how > to solve it. Some developers (especially well-known is Martin van > Loewis) are trying to address this with the "one committer's review > for five reviews" offer, but maybe there are even better ways to do > it. However, this is a *different problem* from "lost patches", which > many projects do suffer from, and shouldn't be called by that name, > which is insulting to the Python committers. I don't think it is insulting (I say that as a young Python committer), and I do think it is fair to call them "lost patches". Perhaps not after four months, but when a good patch hasn't been committed after two years, it is potentially lost because the code base has changed a lot since that and 1) the patch doesn't apply completely anymore 2) it must be reassessed whether the patch is good/useful/necessary with respect to the current code base, which can be tricky. As for reviews, we don't seem to use Rietveld a lot, although it offers a nice interface for comfortably viewing changes, and possibly commenting them. The overhead of having to open a separate issue in Rietveld and upload the patch there is a bit annoying, though. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] opcode dispatch optimization
Antoine Pitrou wrote: > I would like to mention that I've written a patch which enables "threaded > interpretation" on the ceval loop with gcc (*). On my computer (an Athlon X2 > 3600+), it is good for a 15-20% speedup of the interpreter on pystone and > pybench. I also had the opportunity to test it on a Core2-derived CPU, where > it > doesn't make a difference (I conjecture it's because Core2 CPUs have > hardware-based indirect branch optimizations). It will make no difference if > the > interpreter is compiled with something else than gcc (I tested on Windows). The patch makes use of a GCC feature where labels can be used as values: http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html . I didn't know about the feature and got confused by the unary && operator. A happy new your to you all! Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] opcode dispatch optimization
On Wed, Dec 31, 2008 at 11:44 AM, Christian Heimes wrote: > The patch makes use of a GCC feature where labels can be used as values: > http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html . I didn't know > about the feature and got confused by the unary && operator. Right. SpiderMonkey (Mozilla's JavaScript interpreter) does this, and it was good for a similar win on platforms that use GCC. (It took me a while to figure out why it was so much faster, so I think this patch would be better with a few very specific comments!) SpiderMonkey calls this optimization "threaded code" too, but this isn't the standard meaning of that term. See: http://en.wikipedia.org/wiki/Threaded_code -j ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] lost patches
On Wed, Dec 31, 2008 at 07:11, Antoine Pitrou wrote: > > Hi, > > Stephen J. Turnbull xemacs.org> writes: >> >> There *is* a process problem, though I don't claim to have an idea how >> to solve it. Some developers (especially well-known is Martin van >> Loewis) are trying to address this with the "one committer's review >> for five reviews" offer, but maybe there are even better ways to do >> it. However, this is a *different problem* from "lost patches", which >> many projects do suffer from, and shouldn't be called by that name, >> which is insulting to the Python committers. > > I don't think it is insulting (I say that as a young Python committer), and I > do > think it is fair to call them "lost patches". Perhaps not after four months, > but > when a good patch hasn't been committed after two years, it is potentially > lost > because the code base has changed a lot since that and 1) the patch doesn't > apply completely anymore 2) it must be reassessed whether the patch is > good/useful/necessary with respect to the current code base, which can be > tricky. > It is unfortunate when a good patch for a real issue doesn't get applied during the current development cycle. But I honestly think, in general, the important ones do get looked at and handled. Yes, some slip through the cracks, but overall I think we do pretty well. > As for reviews, we don't seem to use Rietveld a lot, although it offers a nice > interface for comfortably viewing changes, and possibly commenting them. The > overhead of having to open a separate issue in Rietveld and upload the patch > there is a bit annoying, though. My hope is that some day we get around to fixing this and getting a code review application tied into the issue workflow so it is no more than pressing a button. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
On Tue, Dec 30, 2008 at 16:55, Victor Stinner wrote: > Hi, > > I already asked in September to get an svn account to be able to commit > directly patches to trunk (or other branches like py3k). My query was > rejected because I didn't know Python core enough (and maybe other reasons > that I don't know). > I am going to stick my neck out on this one and say why I have not spoken up for giving you commit privs, Victor, and my general thoughts on handing them out since I don't think this has been stated by anyone before. When it comes to commit privs in general, I am of the school that they should be handed out carefully. I for one do not want to have to babysit other committers to make sure that they did something correctly. That's a waste of my time since that defeats the purpose of having more committers. This is why I think Benjamin got is privs too soon. Luckily Georg took it upon himself, I assume because he gave Benjamin the privileges, to double-check all of Benjamin's checkins and fix them until Benjamin absorbed enough of the development process to no longer need to be watched over. But I was honestly rather close to suggesting Benjamin lose is privileges early on until he had more time to figure out how things worked. Luckily it didn't come to that and Benjamin has turned out to be a good developer. I also want people who have no agenda. It's okay to have an area you care about, but that doesn't mean you should necessarily say "I will only work on math, ever, even if something is staring me right in the face!", etc. There is also dedication. I don't like giving commit privileges to people who I don't think will definitely stick around. It's fine if they come and go, but if I am not sure if they will typically come back I would prefer to not bother giving them the privilege of saying they are a developer of Python. Typically this takes a year of regular contributions for me to believe this. And lastly, general cohesion with the other committers. Once you become a committer you become a co-worker in a way and that means getting along with everybody. And since we don't have some manager who forces a new co-worker down our throats we tend to be very picky about this. Plus I already lived through high school and I don't want that kind of drama here. So that is my personal criteria on whether or not I speak up for someone getting commit privileges. How do you play into all of this in my head? To start, your focus on security, for me at least, goes too far sometimes. I have disagreed with some of your decisions in the name of security in the past and I am not quite ready to say that if you committed something I wouldn't feel compelled to double-check it to make sure you didn't go too far. This worry, though, has gone down a lot compared to the last time you asked for commit privs. And I do worry about your attitude. I remember at one point you basically threatened to stop helping because your patches were not been looked at quickly. That really pissed me off personally. You have improved here and are a lot less abrasive than you were, but I am still smarting a little from some comments you made a few months back that came off as pushy. And as I said, I prefer to give commit privileges to people who I think will stick around and have been contributing regularly for a year (I just checked bugs.python.org and it looks like you got really involved only five months ago). Saying you stopped doing your fuzzing work simply because the turn-around was not to your liking does not cause me to instantly think you will stick around when it gets nasty around here (which in variably does a couple times a year). In other words I think you are on the right track to get commit privileges in the future, but just not right now (although if you did get them right now I wouldn't throw up a roadblock). -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 - Mac Installer?
On 30 Dec 2008, at 13:45, Barry Scott wrote: ... Since I've been building 3.0 for a while now I looked at the script. build-install.py seems to have been half converted to py 3.0. Going full 3.0 was not hard but then there is the problem of the imports. Python 3.0 does not have MacOS or Carbon modules. Seems that there are two ways to go. Put back the Carbon and MacOS modules into 3.0. Use Python 2 to build the python 3 package. As far as I can tell the Carbon and MacOS modules are _only_ used in the setIcon() function, which is used to give pretty icon to the python folder. Perhaps it might be better to have a fully Python 3 build system and loose the prettiness for the time being. Nicko ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] floatformat vs float_format
Hi, In python 2.6, there have been some effort to make float formatting more consistent between platforms, which is nice. Unfortunately, there is still one corner case, for example on windows: print a -> print 'inf' print '%f' % a -> print '1.#INF' The difference being that in the second case, the formatting is done in floatformat.c (in stringobject.c), whereas in the first case, it is done in format_float (in floatobject.c). Shouldn't both functions be calling the same underlying implementation, to avoid those inconsistencies ? thanks, David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
