Re: [Python-Dev] [Distutils] PEP 365 (Adding the pkg_resources module)
On 19/03/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > I'm currently working on an addition to pkgutil to provide this type > > of function. I'm considering going a little further (adding functions > > to get a file-like object, test for existence, and list available > > resources, modelled on the pkg_resources functions - but these extra > > ones are not supported by the loader protocol, so I'm undecided as to > > whether it's worth it, I'll see how complex the code gets). > > I'd only do what __loader__ offers. People can always wrap a StringIO around > it. > > > Once I have a patch, I'll post it to the tracker. What's the best > > approach? Code a patch for 3.0 and backport, or code for 2.6 and let > > the merging process do its stuff? > > Code for 2.6, let the merge do its thing. I've had a patch in http://bugs.python.org/issue2439 for a few weeks now. It just adds a get_data function, on the basis that that's all the loader API offers. I think it's complete - Phillip Eby helped thrash out a couple of problems. Is there anything I can do to get it applied, or should I just leave it now for someone to decide if they care enough? (As it's a library change, I don't know to what extent the "no API changes after the next alpha" rule will apply). 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] r62342 - python/branches/py3k/Objects/bytesobject.c
Neal Norwitz wrote: > Iteration with the dict methods (e.g., keys -> iterkeys()), > map/zip/filter returning iterator rather than list. That's only an optimisation, it's not functionally required. A list behaves like an iterator in most use cases, so it's rather unlikely that Py3 code will break in the backport because of this (and it's very unlikely that static analysis can catch the cases where it breaks). There should be a rule to optimise "list(map(...))" into "map(...)" and "list(x.keys())" into plain "x.keys()" etc., but I don't think there is much more to do here. > int -> (int, long) Is there any case where this might be required? I don't see any reason why back-converted Py3 code should break here. What would "long()" be needed for in working Py3 code that "int()" doesn't provide in Py2? Although you might have been referring to "isinstance(x, int)" in Py3? > str -> basestring or (str, unicode) This is an issue, although I think that Py3 is explicit enough here to make this easy to handle by static renaming (and maybe optimising "isinstance(s, (str, bytes))" into "..., basestring))"). > __bool__ -> __nonzero__ > exec/execfile > input -> rawinput Also valid issues that can be handled through renaming and static syntactic adjustments. > Most things that have a fixer in 2to3 would also require one in 3to2. I think the more explicit syntax in Py3 will actually make it easier to back-convert the code statically from 3to2 than to migrate it from 2to3. Stefan ___ 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] [Distutils] PEP 365 (Adding the pkg_resources module)
Paul Moore wrote: > Is there anything I can do to get it applied, or should I just leave > it now for someone to decide if they care enough? (As it's a library > change, I don't know to what extent the "no API changes after the next > alpha" rule will apply). I'm looking into it now - assuming it applies cleanly and the tests run happily afterwards (and I don't see any reason it won't after reading the patch), it should be checked in later tonight. Cheers, 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] weird configure (autotools) setup
Hi Jeroen On Sat, 2008-04-12 at 12:00 +0200, Jeroen Ruigrok van der Werven wrote: > Why is CFLAGS in Makefile.pre.in specified as > CFLAGS= $(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS) > whereas that will negate any CFLAGS you pass to configure? I suggest you read (and follow) this issue: http://bugs.python.org/issue1628484 Bob and I are discussing the same thing, so if you want to help us in this effort of making Python's build system more flexible and correct, you're really welcome. Regards, -- Sérgio Durigan Júnior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil ___ 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] Deco
Neal, Martin, We're in the process of decommissioning the box the 'x86 FreeBSD 3' build slave is running on, can you remove it from the list? Our new FreeBSD 7.0 server is up, which we're slowly migrating to, and I'll be able to set a slave up on that probably some time next week once we've moved our production stuff over. Trent. ___ 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] NeedsReview keyword
> Just name your patch files .patch or .diff the next time, not .txt, and > the keyword will get automatically set. > > > fine. I used .txt cause I wanted to view it in my browser (without the > browser asking me for an application) .diff would have done the same thing. > as it only affects the mmap module. I also don't see how this could > cause data loss if the application works correctly. > > > the flush fails but the programs fails to recognize it? i.e. the program > assumes the data is written to disk but it isn't? Why would the program fail to recognize it? It should just look at the result being returned. I agree that this is fairly unpythonic, but I also think that there is any data loss that this may cause is the application's fault. 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] NeedsReview keyword
> > > > the flush fails but the programs fails to recognize it? i.e. the program > > assumes the data is written to disk but it isn't? > > Why would the program fail to recognize it? It should just look at the > result being returned. > sorry no. everything else raises an error. this is not documented (as far as I can see) and mmap.flush returns 0 on unix if it succeeds, and raises an exception on unix if it fails. on windows it returns 1 if it succeeds and 0 if it doesn't (One more time: on unix it returns 0 if it succeeds). Regards, - Ralf > I agree that this is fairly unpythonic, but I also think that there is > any data loss that this may cause is the application's fault. > > ___ 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] NeedsReview keyword
> > the flush fails but the programs fails to recognize it? i.e. the > program > > assumes the data is written to disk but it isn't? > > Why would the program fail to recognize it? It should just look at the > result being returned. > > > sorry no. Sorry no what? 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] mmap.flush [was: NeedsReview keyword]
On Tue, Apr 15, 2008 at 11:20 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > the flush fails but the programs fails to recognize it? i.e. the > > program > > > assumes the data is written to disk but it isn't? > > > > Why would the program fail to recognize it? It should just look at > the > > result being returned. > > > > > > sorry no. > > Sorry no what? > mmap.flush returns different values for windows/unix like platforms in case it succeeds. mmap.flush raises an exception on unix like platforms for errors. mmap.flush returns 0 on windows for errors. This is the value which is returned on unix like platforms for a successful call. The documentation for mmap.flush does not even mention a return value. so, still: sorry no, the application should not just look at the result being returned. The mmap.flush method should be fixed. > 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] mmap.flush [was: NeedsReview keyword]
> so, still: sorry no, the application should not just look at the result > being returned. If it doesn't want to lose data, it *has* to, because of the way it's currently implemented. There is no other way (other than ignoring the error) in Python 2.5.x and earlier. > The mmap.flush method should be fixed. I never debated that. I debated whether that is a "rather severe" issue, which I still don't think it 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] string representation of range in 3.0
Brad Miller wrote: > It was suggested that a broader discussion might be in order around the > issue of iterators and how they are displayed in the command line > interpreter. Whatever is done, I don't think it would be a good idea to make the str() of these things look *too* much like a list. I think that would make things more confusing for a newcomer rather than less. The way they are, at least it's obvious that they're something special. -- Greg ___ 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] string representation of range in 3.0
That's why I proposed <0, 1, ..., 9> for repr(range(10)). (And I meant the '...' literally, i.e. if there are more than 4 values, replace all but the first two and the last with three dots. And yes, I mean that str(range(4)) == '<0, 1, 2, 3>' but str(range(5)) == '<0, 1, ..., 4>'. I'm not at all sure that we should go the same way for dict views though. They are quite different beasts -- the fact that they change depending on the underlying dict ought to be somehow emphasized, and I'd be happier to keep these as they are in 3.0a4. --Guido On Tue, Apr 15, 2008 at 2:53 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: > Brad Miller wrote: > > It was suggested that a broader discussion might be in order around the > > issue of iterators and how they are displayed in the command line > > interpreter. > > Whatever is done, I don't think it would be a good idea > to make the str() of these things look *too* much like > a list. I think that would make things more confusing > for a newcomer rather than less. > > The way they are, at least it's obvious that they're > something special. > > -- > Greg > > > ___ > 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/archive%40mail-archive.com
Re: [Python-Dev] thoughts on having EOFError inherit from EnvironmentError?
Guido van Rossum wrote: > No, that's some kind of parsing error. EnvironmentError doesn't > concern itself with the contents of files. Often I raise EnvironmentErrors of my own to signal parsing errors. This makes it easy to wrap everything in a try-except that catches anything that's the user's fault rather than the program's. > But what operations raise EOFError? Surely you're not using > raw_input()? It's really only there for teaching. I'm fairly sure there are some others, although I can't point to them on the spur of the moment. However, thinking about it a bit more, anything that calls something that can raise EOFError should be catching it anyway, so an escaped EOFError represents a program bug. So it's probably okay. -- Greg ___ 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] thoughts on having EOFError inherit from EnvironmentError?
On Tue, Apr 15, 2008 at 3:27 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > > No, that's some kind of parsing error. EnvironmentError doesn't > > concern itself with the contents of files. > > Often I raise EnvironmentErrors of my own to signal > parsing errors. This makes it easy to wrap everything > in a try-except that catches anything that's the user's > fault rather than the program's. Well, that's your problem. That's not what EnvironmentErrors are for. > > But what operations raise EOFError? Surely you're not using > > raw_input()? It's really only there for teaching. > > I'm fairly sure there are some others, although I > can't point to them on the spur of the moment. > > However, thinking about it a bit more, anything that > calls something that can raise EOFError should be > catching it anyway, so an escaped EOFError represents > a program bug. So it's probably okay. Right. -- --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] string representation of range in 3.0
Hi folks, Been lurking for a while, this is my first post. As I recall, this discussion was started because of concern that Python 3 had introduced features that made it less friendly to beginners. If I can quote Brad Miller: "Several new iterators have appeared in Python 3.0 that makes the language less transparent to beginning programmers. The examples that immediately come to mind are shown below..." It hasn't been that many years since I was a beginner myself, and I'm pretty sure that had I seen Guido's suggestion: > That's why I proposed <0, 1, ..., 9> for repr(range(10)). (And I > meant the '...' literally, i.e. if there are more than 4 values, > replace all but the first two and the last with three dots. And yes, > I mean that str(range(4)) == '<0, 1, 2, 3>' but str(range(5)) == '<0, > 1, ..., 4>'. in the interpreter back then, I would have tried writing the literal <0, 1, 2, 3> as an alternative to [0, 1, 2, 3] or (0, 1, 2, 3) and been rather distressed that it didn't do what I expected. As a beginner I was rather hazy on the difference between lists and tuples, and I would have imagined that <> was just another sort of delimiter pair for a list-like thing. I'd like to say that I'd only make the mistake once, but thinking about how often I still write dict(key) instead of dict[key], it's quite possible that some people might take a long time to drive the <> pseudo-delimiters out of their head. I'm -1 on <>. In my experience, real beginners aren't going to using range() except in the context of for loops, hence are unlikely to be printing the range object directly except by accident. Personally, I find it a feature that this happens in Python 2.x: >>> xrange(5) xrange(5) and would say the same thing about range() in Python 3, regardless of whether you wrap it in a str() or a repr(). As for the use of dots to keep stringified-sequences short, I'd vote +1 except I think that four items is rather short and would prefer the dots to come in around six or eight items. That's not entirely an aesthetic preference, I also have a reason for thinking that it might actually make a difference, but to avoid turning this discussion into bike-shedding I'll keep it to myself unless asked. -- Steven ___ 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] string representation of range in 3.0
Guido van Rossum wrote: > That's why I proposed <0, 1, ..., 9> for repr(range(10)). My worry is that this will lead a newcomer into thinking this is some kind of valid expression syntax. -- Greg ___ 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] thoughts on having EOFError inherit from EnvironmentError?
Guido van Rossum wrote: >> Often I raise EnvironmentErrors of my own to signal >> parsing errors. > > Well, that's your problem. That's not what EnvironmentErrors are for. But it seems like it's what it *should* be for. I'd be happy to use some other standard exception type if one existed at the right point in the hierarchy to catch what I want to catch, but there isn't one. -- Greg ___ 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] thoughts on having EOFError inherit from EnvironmentError?
On Tue, Apr 15, 2008 at 8:40 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > >> Often I raise EnvironmentErrors of my own to signal > >> parsing errors. > > > > > Well, that's your problem. That's not what EnvironmentErrors are for. > > But it seems like it's what it *should* be for. You are unique in demanding this. > I'd be happy to use some other standard exception > type if one existed at the right point in the hierarchy > to catch what I want to catch, but there isn't one. -- --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] string representation of range in 3.0
On Tue, Apr 15, 2008 at 8:34 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > That's why I proposed <0, 1, ..., 9> for repr(range(10)). > > My worry is that this will lead a newcomer into thinking > this is some kind of valid expression syntax. You and Steven D'Aprano both. So if this is indeed a bad idea, I'm stumped -- the 3.0 status quo is the best we can do, and teachers will just have to teach their students to write list(range(10)) if they want to see what it means. Or they can write an explicit for-loop (always useful on the first day): for i in range(10): print i -- --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] mmap.flush [was: NeedsReview keyword]
On Tue, Apr 15, 2008 at 11:49 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > so, still: sorry no, the application should not just look at the result > > being returned. > > If it doesn't want to lose data, it *has* to, because of the way it's > currently implemented. There is no other way (other than ignoring the > error) in Python 2.5.x and earlier. > My point is it will ignore this error, because the programmer didn't even know about the return value. So it will possibly use data. But, it's all in the bug report and I'm only repeating myself. > > > The mmap.flush method should be fixed. > > I never debated that. I debated whether that is a "rather severe" issue, > which I still don't think it is. > I didn't recognize that we discussed this phrase. Sorry if I wasted your time. Regards, Ralf ___ 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
