i found several places in my code where i use positive infinity
(posinf) for various things, i.e.,
def readline(self, limit = -1):
if limit < 0:
limit = 1e1 # posinf
chars = []
while limit > 0:
ch = self.read(1)
chars.append(ch)
On 11/26/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> i found several places in my code where i use positive infinity
> (posinf) for various things, i.e.,
>
> def readline(self, limit = -1):
> if limit < 0:
> limit = 1e1 # posinf
> chars = []
> while lim
> sys.maxint makes more sense there.
no, it requires *infinity* to accomplish x - y == x; y != 0, for example:
while limit > 0:
limit -= len(chunk)
with limit = posinf, the above code should be equivalent to "while True".
> There is already a PEP 754 for float constants
okay, that would suff
tomer filiba wrote:
> no, it requires *infinity* to accomplish x - y == x; y != 0, for example:
>
> while limit > 0:
> limit -= len(chunk)
>
> with limit = posinf, the above code should be equivalent to "while True".
that's a remarkably stupid way to count bytes. if you want to argue for
At 07:07 PM 11/26/2006 +0200, tomer filiba wrote:
> > sys.maxint makes more sense there.
>no, it requires *infinity* to accomplish x - y == x; y != 0, for example:
>
>while limit > 0:
> limit -= len(chunk)
Um, you do realize that you're not going to be able to fit sys.maxint
strings into a li
> -Original Message-
> From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 21, 2006 12:01 AM
> To: Julian
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] Suggestion/ feature request
>
> Julian schrieb:
> > I am using python with swig and I get a lot of macr
> -Original Message-
> From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 21, 2006 12:22 PM
> To: Julian
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] Suggestion/ feature request
>
> Julian schrieb:
> > SWIG seems to have done it properly by checking
Hi everyone,
Guido van Rossum suggested I send this email here.
I'm CTO of the Free Standards Group and chair of the Linux Standard
Base (LSB), the interoperability standard for the Linux distributions.
We're wanting to add Python to the next version of the LSB (LSB 3.2) [1]
and are looking for s
Mr. Rossum,
I saw an old post you made about the Google Internships (Jan
25,2006). As a prospective for next summer, you mention that it would
be in my best interest to contact brett Cannon. I have many questions
I'd love to have answered, how do I go about contacting him? I look
forward t
tomer filiba schrieb:
> okay, that would suffice. but why isn't it part of stdlib already?
> the pep is three years old... it should either be rejected or accepted.
> meanwhile, there are lots of missing API functions in the floating-point
> implementation...
It's not rejected because people keep
Ian Murdock schrieb:
> I'm CTO of the Free Standards Group and chair of the Linux Standard
> Base (LSB), the interoperability standard for the Linux distributions.
> We're wanting to add Python to the next version of the LSB (LSB 3.2) [1]
> and are looking for someone (or, better, a few folks) in t
On Sun, Nov 26, 2006, "Martin v. L?wis" wrote:
>
> I wrote to Ian that I would be interested; participating in the meeting
> in Berlin is quite convenient. I can try to keep python-dev updated.
Please do -- it's not something I have a lot of cycles for but am
interested in.
--
Aahz ([EMAIL PROTEC
At 11:09 AM 11/22/2006 -0500, Ian Murdock wrote:
>The first question we have to answer is: What does it mean to "add
>Python to the LSB"? Is it enough to say that Python is present
>at a certain version and above, or do we need to do more than that
>(e.g., many distros ship numerous Python add-ons
> Um, you do realize that you're not going to be able to fit sys.maxint
> strings into a list, right?
i can multiply by four, thank you. of course i don't expect anyone to read
a string *that* long.
besides, this *particular example* isn't important, it was just meant to
show why someone might wan
I've been looking once again over the docs for distutils and setuptools,
and thinking to myself "this seems a lot more complicated than it ought
to be".
Before I get into detail, however, I want to explain carefully the scope
of my critique - in particular, why I am talking about setuptools on
Talin wrote:
> But it isn't just the docs that are at fault here - otherwise, I'd be
> posting this on a different mailing list. It seems like the whole
> architecture is 'diff'-based, a series of patches on top of patches,
> which are in need of some serious refactoring.
so to summarize, you
Fredrik Lundh wrote:
> Talin wrote:
>
>> But it isn't just the docs that are at fault here - otherwise, I'd be
>> posting this on a different mailing list. It seems like the whole
>> architecture is 'diff'-based, a series of patches on top of patches,
>> which are in need of some serious refact
On 11/26/06, Talin <[EMAIL PROTECTED]> wrote:
> I've been looking once again over the docs for distutils and setuptools,
> and thinking to myself "this seems a lot more complicated than it ought
> to be".
>
> Before I get into detail, however, I want to explain carefully the scope
> of my critique
At 01:21 PM 11/26/2006 -0800, Mike Orr wrote:
>A comprehensive third-party manual that integrates the documentation
>would be a good place to start. Even the outline of such a manual
>would be a good. That would give a common baseline of understanding
>for package users, package developers, and cor
Excellent! Like Aahz, I have no cycles, but I think it's a worthy goal.
--Guido
On 11/26/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Ian Murdock schrieb:
> > I'm CTO of the Free Standards Group and chair of the Linux Standard
> > Base (LSB), the interoperability standard for the Linux dis
On 11/26/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I have noticed, however, that a signficant number of help requests for
> setuptools can be answered by internal links to one of its manuals -- and
> when a topic comes up that isn't in the manual, I usually add it.
Hmm, I may have a couple t
Mike Orr wrote:
> On 11/26/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> I have noticed, however, that a signficant number of help requests for
>> setuptools can be answered by internal links to one of its manuals -- and
>> when a topic comes up that isn't in the manual, I usually add it.
>
> H
22 matches
Mail list logo