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, mode
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 i
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
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:/
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 mo
> 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
> >
> > 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 docume
> > 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,
M
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 ju
> 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 shoul
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
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 s
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
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 ma
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
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:/
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
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 *sh
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 bot
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 (o
20 matches
Mail list logo
