Hi all
First, some background.
I've recently tried to port a certain library that manipulates dates
from C. Some of the core functions contain heavy integer math (very long
formulae), and after implementing them I tested them to see the give the
desired results.
I got very odd results, which su
2007/8/29, dany <[EMAIL PROTECTED]>:
> For some reason, the integer division behaves unexpectedly for negative
> integers.
>
> Looking deeper in the python PEPs, I saw that division on integers is
> defined as: idiv(a, b) = floor(fdiv(a, b)).
> This non-quotient division leads to some odd results,
On 8/29/07, dany <[EMAIL PROTECTED]> wrote:
> Looking deeper in the python PEPs, I saw that division on integers is
> defined as: idiv(a, b) = floor(fdiv(a, b)).
> This non-quotient division leads to some odd results, e.g. Python seems
> to think -3/2+3/2 = -1. This is clearly, and correct me if I'
> apt-get install openssl will fix that on those systems. on windows
> you're unlikely to ever have an openssl binary present and available to
> execute.
OTOH, having openssl(1) installed is not a prerequisite for Python
buildbots currently, and IMO shouldn't be.
Regards,
Martin
___
Bill Janssen schrieb:
>> Well, that's just what you get with two independent implementations of
>> a spec. We don't try to hide the differences between the sockets stack
>> in Unix and Windows -- you'll just have to work around it.
>
> No problem. But I think it's still a bug -- the "spec" (where
> This non-quotient division leads to some odd results, e.g. Python seems
> to think -3/2+3/2 = -1. This is clearly, and correct me if I'm mistaken
> - wrong.
Lino already pointed you to the relevant FAQ entry, but since you
explicitly asked for it: you are mistaken, the result is right.
It wou
2007/8/29, "Martin v. Löwis" <[EMAIL PROTECTED]>:
> It would have been good if you had indicated what result you had
> expected instead. I assume 0; to get 0, you have to write -(3/2)+3/2,
> or 0-3/2+3/2.
Wow, that caught me:
>>> -3/2+3/2
-1
>>> 0-3/2+3/2
0
>>>
I'm not talking about division he
> I think "the spec" would be the socket API. For sockets, that is POSIX.
> According to
>
> http://www.opengroup.org/pubs/online/7908799/xns/getsockname.html
>
> the result is unspecified if the socket has not been bound to a local
> name.
>
> However, Windows does not implement POSIX here; ins
> Do you know why? Thanks!
It's a matter of precedence: ** has higher precedence
than unary + and -, which has higher precedence than / and *,
which have higher precedence than binary + and -. See
power, factor, term in Grammar/Grammar.
I'm not sure why precedence was defined that
way, though.
R
> Transmitting file data .subversion/libsvn_client/commit.c:832:
> (apr_err=165001)
> svn: Commit failed (details follow):
> /build/buildd/subversion-1.4.2dfsg1/subversion/libsvn_repos/hooks.c:135:
> (apr_err=165001)
> svn: 'pre-commit' hook failed with error output:
> file /python/trunk/
On 8/29/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
>
> > Transmitting file data .subversion/libsvn_client/commit.c:832:
> (apr_err=165001)
> > svn: Commit failed (details follow):
> > /build/buildd/subversion-1.4.2dfsg1/subversion/libsvn_repos/hooks.c:135:
> (apr_err=165001)
> > svn: 'pre-
> So, the pre-commit hook is blocking me; how do I trouble-shoot this?
Run Tools/scripts/reindent.py Lib/ssl.py
Alternatively, run "reindent.py -drv .|grep ' changed'" to analyse your
entire sandbox.
Regards,
Martin
___
Python-Dev mailing list
Python-D
Create a zip file with a file inside consisting of several GB (say 2 or 5 GB).
The zipfile module will fail, when attempting to extract the large file.
The issue is near line 490 in zifile.py. It appears that read (a file
operation) is unable to read such large amounts of data. I tried editi
Martin v. Löwis wrote:
>> Do you know why? Thanks!
>
> I'm not sure why precedence was defined that
> way, though.
>
Because it is consistent with C's precedence rules.
-Scott
--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing
> Does anyone know how to fix this limitation in the zipfile module?
See http://bugs.python.org/issue1189216
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.
Please file a bug at the new bug tracker (bugs.python.org). Please add
a small self-contained code sample that shows the issue, and specify
what you would like to see instead (keeping in mind that you just
can't allocate 2 GB on a 32-bit box).
--Guido
On 8/29/07, Kevin Ar18 <[EMAIL PROTECTED]> wr
>>> Do you know why? Thanks!
>>
>> I'm not sure why precedence was defined that
>> way, though.
Scott> Because it is consistent with C's precedence rules.
True enough, however Python doesn't support negative numbers as individual
tokens at the lexical analysis level. -3.41
Hi,
I'm new to the Python source and I have a (hopefully) quick question
that someone more familiar with it should be able to answer so I can
continue on my way to understanding how Python is put together.
I have started looking at the parser and have gotten a little confused
about how the gram
Scott Dial schrieb:
> Martin v. Löwis wrote:
>>> Do you know why? Thanks!
>> I'm not sure why precedence was defined that
>> way, though.
>>
>
> Because it is consistent with C's precedence rules.
Maybe I'm missing something - how exactly is the exponentiation
operator spelled in C?
Regards,
Mar
> True enough, however Python doesn't support negative numbers as individual
> tokens at the lexical analysis level. -3.41 is '-' followed by '3.41'. In
> C it's a single token resolved at compile time.
That is not true. ISO C99 defines (6.4.4.1)
integer-constant:
> Can someone explain how this works please?
Don't try reading these files. They are generated; read Parser/pgen
instead (which generates these files), or see how they are used.
> I've never come across
> escape sequences like this; I've only ever seen \0 (nul) before; not \2,
> \3 etc. or are
On 8/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Scott Dial schrieb:
> > Martin v. Löwis wrote:
> >>> Do you know why? Thanks!
> >> I'm not sure why precedence was defined that
> >> way, though.
> >>
> >
> > Because it is consistent with C's precedence rules.
>
> Maybe I'm missing somethi
All right, this is committed. Let's see if the Windows buildbots like
it.
Bill
> So, the patch is attached to issue 1052. I sent it out to python-dev,
> but it got blocked (too big).
>
> http://bugs.python.org/file8352/ssl-patch-5
>
> This contains a number of things:
>
> 1) Improve the docu
Yes, the Windows buildbots seem happy now with ssl. I'm going to
expand the test suite.
Bill
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
Martin v. Löwis wrote:
> Alexandre Vassalotti schrieb:
>> C doesn't have an exponentiation operator. You use the pow() function,
>> instead:
>
> Right. Then Scott's claim ("Because it is consistent with C's precedence
> rules.") can't be true - from C precedence, it does not follow that **
> must
Alexandre Vassalotti wrote:
> C doesn't have an exponentiation operator. You use the pow() function,
> instead:
Wouldn't it make more sense, then, to have unary +/- have higher
precedence than the ** operator, so that -3**2 == 9?
Regards,
Dirkjan
__
26 matches
Mail list logo
