[Python-Dev] PEP 238 - The // operator should truncate instead of floor

2007-08-29 Thread dany 
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 surprised me since I copied the formula 
letter to letter.

I decided to investigate further, and after trying to evaluate several 
expressions in the python console, I realized it was the integer 
division's fault.

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, e.g. Python seems 
to think -3/2+3/2 = -1. This is clearly, and correct me if I'm mistaken 
- wrong.

Now, seeing as Python 3000 is getting closer, and backwards 
compatibility isn't an issue, I believe it would be a good idea to 
change the // operator (which will be used for integer division) to 
behave as quotient, i.e.: a // b = trunc(a / b)

Dany
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 238 - The // operator should truncate instead of floor

2007-08-29 Thread Lino Mastrodomenico 
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, e.g. Python seems
> to think -3/2+3/2 = -1. This is clearly, and correct me if I'm mistaken
> - wrong.

FAQ: Why does -22 / 10 return -3?

http://www.python.org/doc/faq/programming/#why-does-22-10-return-3

Past discussion:



Also, FYI, TCL and Ruby behave the same way.

-- 
Lino Mastrodomenico
E-mail: [EMAIL PROTECTED]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 238 - The // operator should truncate instead of floor

2007-08-29 Thread Fredrik Johansson 
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'm mistaken
> - wrong.

Rounding integer division can't be defined such that fractional
information is preserved. For example, the sum 1/2 + 1/2 (with
rounding division), doesn't equal 1 whether the rounding is done up or
down. Python's choice to round to the floor of the exact quotient is
entirely in order, and in fact, I've found it very useful in some of
my code.

There is an easy fix for your problem: write a custom division function, e.g.

def div(a, b):
if a*b > 0:
return a // b
else:
return -(abs(a)//abs(b))

Either that, or use any of the modules for rational arithmetic
available for Python.

Fredrik
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Other SSL issues in the tracker have been marked

2007-08-29 Thread Martin v. Löwis 
> 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
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Other SSL issues in the tracker have been marked

2007-08-29 Thread Martin v. Löwis 
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 is it?)
> should say what we want.  I'll file an issue on it.

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; instead, it implements
WinSock, which specifies that WSAEINVAL is returned.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 238 - The // operator should truncate instead of floor

2007-08-29 Thread Martin v. Löwis 
> 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 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.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Order of operations (was: PEP 238 - The // operator should truncate instead of floor)

2007-08-29 Thread Facundo Batista 
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 here, just the fact that in the first
case, it was (-3) / 2 and not -(3/2).

It's a surprise to me, taking into account that

>>> -3**2
-9
>>> 0-3**2
-9

Here, the behavior is always the same: -(3**2).

Do you know why? Thanks!

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Other SSL issues in the tracker have been marked

2007-08-29 Thread Bill Janssen 
> 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; instead, it implements
> WinSock, which specifies that WSAEINVAL is returned.

So, two different specs meet in the Python API, which means that we
have to define the behavior ourselves.  I'd suggest returning None from
an unbound socket.

Bill
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Order of operations (was: PEP 238 - The // operator should truncate instead of floor)

2007-08-29 Thread Martin v. Löwis 
> 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.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] whitespace-normalized commit hook...

2007-08-29 Thread Bill Janssen 
> 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/Lib/ssl.py is not whitespace-normalized

So, the pre-commit hook is blocking me; how do I trouble-shoot this?

What's the client-side way to run this scan?  Can I add it to the
regression-test harness?

Bill
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] whitespace-normalized commit hook...

2007-08-29 Thread Thomas Wouters 
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-commit' hook failed with error output:
> > file /python/trunk/Lib/ssl.py is not whitespace-normalized
>
> So, the pre-commit hook is blocking me; how do I trouble-shoot this?
>
> What's the client-side way to run this scan?  Can I add it to the
> regression-test harness?


It basically calls Tools/scripts/reindent.py with --dry-run (although I
notice the version we call from SVN is more forgiving towards tokenizer
errors. I'm not sure we need that here.) Incorporating it in the normal test
suit would be good, as I've been caught by the same problem several times
:-)

-- 
Thomas Wouters <[EMAIL PROTECTED]>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] whitespace-normalized commit hook...

2007-08-29 Thread Martin v. Löwis 
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] zipfile module can't handle large files

2007-08-29 Thread Kevin Ar18 

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 editing 
zipfile.py so that read would read things piece by piece but just got a memory 
error.

Does anyone know how to fix this limitation in the zipfile module?
_
See what you’re getting into…before you go there
http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Order of operations (was: PEP 238 - The // operator should truncate instead of floor)

2007-08-29 Thread Scott Dial 
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 list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] zipfile module can't handle large files

2007-08-29 Thread Martin v. Löwis 
> 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.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] zipfile module can't handle large files

2007-08-29 Thread Guido van Rossum 
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]> wrote:
>
> 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 editing 
> zipfile.py so that read would read things piece by piece but just got a 
> memory error.
>
> Does anyone know how to fix this limitation in the zipfile module?
> _
> See what you're getting into…before you go there
> http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507
> ___
> Python-Dev mailing list
> [email protected]
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Order of operations (was: PEP 238 - The // operator should truncate instead of floor)

2007-08-29 Thread skip 

>>> 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 is '-' followed by '3.41'.  In
C it's a single token resolved at compile time.  In the not-too-distant past
negative numeric constants were tried, but that caused some other grief.  I
can't remember what.

Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] newb question

2007-08-29 Thread Ty Newton 
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 grammar is instantiated (perhaps the wrong term).

Here's how I understand things at the moment.  graminit.c contains the 
definition of the grammar in terms of static structures.  Everything 
seems simple enough until I get to the DFA (in graminit.c):

static dfa dfas[84] = {
{256, "single_input", 0, 3, states_0, 
"\004\050\014\000\000\000\000\025\074\005\023\310\011\020\004\000\300\020\222\006\201"},
...

I assume that the last bit of my snippet (\004\050\014\ ...) is a bitset 
structure.  When I look at bitset it is defined as a char array.

Can someone explain how this works please?  I've never come across 
escape sequences like this; I've only ever seen \0 (nul) before; not \2, 
\3 etc.  or are they not escape sequences, but literal forward slashes.


Thanks,
Ty
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Order of operations

2007-08-29 Thread Martin v. Löwis 
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,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Order of operations

2007-08-29 Thread Martin v. Löwis 
> 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:
   decimal-constant integer-suffix-opt
   octal-constant integer-suffix-opt
   hexadecimal-constant integer-suffix-opt

   decimal-constant:
   nonzero-digit
   decimal-constant digit

and then (6.5.3)

   unary-expr:
   postfix-expr
   ++ unary-expr
   -- unary-expr
   unary-operator cast-expr
   sizeof unary-expr
   sizeof ( type-name )

   unary-operator: one of
   &  *  +  -  ~  !

So -3.41 is definitely two tokens in C.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] newb question

2007-08-29 Thread Martin v. Löwis 
> 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 they not escape sequences, but literal forward slashes.

They are octal escapes; this is a standard C construct. You need three
octal digits to build one character. So it's \222, not \2, and \310, not
\3. The integer values are 0222 and 0310, respectively (i.e. 146 and
200).

HTH,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Order of operations

2007-08-29 Thread Alexandre Vassalotti 
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 something - how exactly is the exponentiation
> operator spelled in C?
>

C doesn't have an exponentiation operator. You use the pow() function, instead:

  #include 
  double pow(double x, double y);

-- Alexandre
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Other SSL issues in the tracker have been marked

2007-08-29 Thread Bill Janssen 
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 documentation of the SSL module, with a fuller
>explanation of certificate usage, another reference, proper 
>formatting of this and that.
> 
> 2) Fix Windows bug in ssl.py, and general bug in sslsocket.close().  
>Remove some unused code from ssl.py.  Allow accept() to be called on 
>sslsocket sockets.
> 
> 3) Use try-except-else in import of ssl in socket.py.  Deprecate use of
>socket.ssl().
> 
> 4) Remove use of socket.ssl() in every library module, except for
>test_socket_ssl.py and test_ssl.py.
> 
> Bill
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/janssen%40parc.com


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Other SSL issues in the tracker have been marked

2007-08-29 Thread Bill Janssen 
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-dev/archive%40mail-archive.com

Re: [Python-Dev] Order of operations

2007-08-29 Thread Scott Dial 
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 have higher precedence than unary -.
> 

I believe the confusion with my claim is that I thought the oddity in 
question was that -3/2 != 0-3/2, but I believe you took the other half 
about exponentiation as the oddity in question that -3**2 == -(3**2). My 
original comment was to say that unary - was higher precedence than 
division because of C's ordering. With respect to the original question, 
then my answer was poor as I ignored the exponentiation part. Since we 
tacked this on, my answer was to be an implicit zen answer of "because 
it makes the most sense."

Sorry for the added noise.

-Scott

-- 
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Order of operations

2007-08-29 Thread Dirkjan Ochtman 
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

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com