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
__
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
Yes, the Windows buildbots seem happy now with ssl. I'm going to
expand the test suite.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
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
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
> 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
> 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:
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
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
>>> 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
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
> Does anyone know how to fix this limitation in the zipfile module?
See http://bugs.python.org/issue1189216
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.
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
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
> 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
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-
> 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/
> 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
> 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
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
> 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
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
> 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
___
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'
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,
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
26 matches
Mail list logo
