[issue2796] Build issues in DragonFly BSD

[Hasso Tepper]

New submission from Hasso Tepper <[EMAIL PROTECTED]>:

The attached patch fixes obvious problems with build in DragonFly BSD 
platform.

Modules/socketmodule.c part adds NetBSD to the blacklist as well - 
both OS'es use the same Bluetooth stack. Although the code seems to 
have support for NetBSD stack, the code is stub and it doesn't build.

--
components: Build
files: dragonfly-python25.patch
keywords: patch
messages: 66457
nosy: hasso
severity: normal
status: open
title: Build issues in DragonFly BSD
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file10227/dragonfly-python25.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2796] Build issues in DragonFly BSD

[Hasso Tepper]

Changes by Hasso Tepper <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file10228/dragonfly-python24.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2797] Trunk build issues in DragonFly BSD

[Hasso Tepper]

New submission from Hasso Tepper <[EMAIL PROTECTED]>:

The attached patch fixes trunk build problems in DragonFly BSD.

It's trunk version of the issue #2796, but adds one (not DragonFly 
specific) fix to the Modules/mmapmodule.c - in case of 
(!HAVE_SYSCONF || !_SC_PAGESIZE) my_getallocationgranularity will not 
be defined.

--
components: Build
files: dragonfly-python-trunk.patch
keywords: patch
messages: 66458
nosy: hasso
severity: normal
status: open
title: Trunk build issues in DragonFly BSD
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file10229/dragonfly-python-trunk.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2723] Truncate __len__() at sys.maxsize

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Well apparently the Java guys think raising an exception would have been
a much better idea than the behaviour they are stuck with.
There's also in interesting proposal there:

""" The ReturnValueTooBigException could even have a method declared as
"long size()" that reports the actual size of the collection. """

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1342] Crash on Windows if Python runs from a directory with umlauts

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

There are some problems under Linux too:

$ pwd
/home/antoine/py3k/héhé
$ ./python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "/home/antoine/py3k/pristine/Lib/encodings/__init__.py", line 32,
in 
TypeError: zipimporter() argument 1 must be string without null bytes,
not str
Abandon

--
nosy: +pitrou

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2789] Comparsion datetime objects with None

[Ralf Schmitt]

Changes by Ralf Schmitt <[EMAIL PROTECTED]>:


--
nosy: +schmir

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2798] Crash on non-Windows if Python runs from a non-ASCII directory

[Antoine Pitrou]

New submission from Antoine Pitrou <[EMAIL PROTECTED]>:

(Note: I'm splitting this from #1342 because the fix is much simpler in
the non-Windows case)

py3k does not accept running from a path with non-ascii characters.

$ pwd
/home/antoine/py3k/héhé
$ ./python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "/home/antoine/py3k/pristine/Lib/encodings/__init__.py", line 32,
in 
TypeError: zipimporter() argument 1 must be string without null bytes,
not str
Abandon

The following patch solves the problem by fixing a bug in getargs.c
where the "no null bytes" check for non-ASCII strings was wrong.

There is still a failing test, test_xmlrpc, apparently because xmlrpc
wants to output its path in an HTTP header using the "ascii" encoding...
I'd say this is an xmlrpc issue and not an issue with the patch.

--
components: Interpreter Core
files: getargs.patch
keywords: patch
messages: 66461
nosy: christian.heimes, pitrou
severity: normal
status: open
title: Crash on non-Windows if Python runs from a non-ASCII directory
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file10230/getargs.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1342] Crash on Windows if Python runs from a directory with umlauts

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

See #2798 for the non-Windows case, with a patch.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2798] Crash on non-Windows if Python runs from a non-ASCII directory

[Antoine Pitrou]

Changes by Antoine Pitrou <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file10230/getargs.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2798] Crash on non-Windows if Python runs from a non-ASCII directory

[Antoine Pitrou]

Changes by Antoine Pitrou <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file10231/getargs.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2799] Remove PyUnicode_AsString(), rework PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()

[Marc-Andre Lemburg]

New submission from Marc-Andre Lemburg <[EMAIL PROTECTED]>:

The API PyUnicode_AsString() is pretty useless by itself - there's
no way to access the size information of the returned string without
again going to the Unicode object.

I'd suggest to remove the API altogether and not only deprecating it.

Furthermore, the API PyUnicode_AsStringAndSize() does not follow the API
signature of PyString_AsStringAndSize() in that it passes back the
pointer to the string as output parameter. That should be changed as
well. Note that PyString_AsStringAndSize() already does this for both
8-bit strings and Unicode, so the special Unicode API is not really
needed at all or you may want to rename PyString_AsStringAndSize() to
PyUnicode_AsStringAndSize().

Finally, since there are many cases where the string buffer contents are
copied to a new buffer, it's probably worthwhile to add a new API which
does the copying straight away and also deals with the overflow cases in
a central place. I'd suggest PyUnicode_AsChar() (with an API like
PyUnicode_AsWideChar()).

(this was taken from a comment on #1950)

--
components: Unicode
messages: 66463
nosy: lemburg
severity: normal
status: open
title: Remove PyUnicode_AsString(), rework PyUnicode_AsStringAndSize(), add 
PyUnicode_AsChar()
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2800] make htmlhelp creates python30a5.chm but msi.py expects pydoc.chm

[Christian Heimes]

New submission from Christian Heimes <[EMAIL PROTECTED]>:

The sphinx tool chain now creates the htmlhelp files as python30a5.* but
the MSI installer packages expects pydoc.chm. Either msi.py or the doc
tool chain must be altered.

By the way Martin:
Should the RM set snapshot to 0 in Tools/msi/msi.py before tagging a
release?

--
assignee: georg.brandl
components: Windows
messages: 66464
nosy: christian.heimes, georg.brandl, loewis
priority: high
severity: normal
status: open
title: make htmlhelp creates python30a5.chm but msi.py expects pydoc.chm
type: behavior
versions: Python 2.6, Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2801] Py30a5 float.is_integer() raises ValueError

[Mark Summerfield]

New submission from Mark Summerfield <[EMAIL PROTECTED]>:

The new method float.is_integer() introduced in Py30a5 behaves unexpectedly:

>>> x = 5.0
>>> x.as_integer_ratio()
(5, 1)
>>> x.is_integer()
Traceback (most recent call last):
  File "", line 1, in 
x.is_integer()
ValueError: (11, 'Resource temporarily unavailable')

I was expecting True.

--
messages: 66465
nosy: mark
severity: normal
status: open
title: Py30a5 float.is_integer() raises ValueError
type: behavior
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2772] Add PendingDeprecationWarning for % formatting

[Eric Smith]

Eric Smith <[EMAIL PROTECTED]> added the comment:

The attached patch (percent_formatting_pending_deprecation_0.diff) adds
both the simple global lock to unicode_mod() and changes warnings.py to
use .format() instead of % formatting.

I think this is good enough.  We should add a warning to the docs saying
user code used for warnings should also avoid % formatting.  The only
problem they'll see, however, is dropping an occasional warning in a
multi-threaded app.  But I'm not sure yet exactly where this mention
would go.

I also don't have any tests for this.  I haven't found a test of a
PendingDeprecationWarning.

The biggest problem is that this patch breaks test_doctest with
"RuntimeError: dictionary changed size during iteration".  I've tried to
find out why, but so far it escapes me.  If someone else could look at
the issue, I'd appreciate it.

Added file: 
http://bugs.python.org/file10232/percent_formatting_pending_deprecation_0.diff

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2748] ceil(), floor() and round() broken in Decimal

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

Thanks for reviewing this, Raymond!

Committed, r62938.

--
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2801] Py30a5 float.is_integer() raises ValueError

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

Is this on Windows?  I can't reproduce it on OS X 10.5.2:

Python 3.0a5+ (py3k:62937M, May  9 2008, 09:32:27) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 5.0
>>> x.is_integer()
True

--
nosy: +marketdickinson

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2801] Py30a5 float.is_integer() raises ValueError

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

This should be fixed in r62938.  Mark, can you confirm?

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2801] Py30a5 float.is_integer() raises ValueError

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

That should be r62939, not r62938.  Sorry.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2801] Py30a5 float.is_integer() raises ValueError

[Mark Dickinson]

Changes by Mark Dickinson <[EMAIL PROTECTED]>:


--
assignee:  -> marketdickinson
priority:  -> normal

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2802] str.format() :n integer output

[Mark Summerfield]

New submission from Mark Summerfield <[EMAIL PROTECTED]>:

In Py30a5 the 'n' format option is not v. useful for integers:

>>> for x in range(8):
print("{0:n} ".format(10**x), end="")

1 10 100 1,000 10,000 100,000 1e+06 1e+07

This is because it behaves like g once a number grows large. That makes
sense for floats, but since Python has unlimited size integers there is
currently no built-in way to get, 10**6 to output as 1,000,000 (or using
whatever the user's locale-dependent separator is). (It is easy to write
a suitable function for this, but it just seems that n is a bit of a
teaser in this regard.)

I think that n should stay the same for floats, but for integers should
never switch to g, but just use as many separators as needed.

--
messages: 66471
nosy: mark
severity: normal
status: open
title: str.format() :n integer output
type: feature request
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2802] str.format() :n integer output

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

> I think that n should stay the same for floats, but for integers should
> never switch to g, but just use as many separators as needed.

I agree with this, in principle.  It might be some work to implement, 
though:  for floats, Python gets to use the OS-supplied formatting 
functions.  Indeed, it looks as though all that happens here is that the 
integer is converted to a float before formatting:

>>> print("{0:n} ".format(10**400), end="")
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: Python int too large to convert to C double

For integers, we'd have to roll our own code. I had similar problems 
trying to implement the 'n' format code for Decimal;  in the end I just 
gave up and left it unimplemented.  Maybe using 'n' for an integer should 
just raise an exception, for now?

Eric, what do you think?

--
assignee:  -> eric.smith
nosy: +eric.smith, marketdickinson
priority:  -> normal

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2801] Py30a5 float.is_integer() raises ValueError

[Mark Summerfield]

Mark Summerfield <[EMAIL PROTECTED]> added the comment:

On 2008-05-09, Mark Dickinson wrote:
> Mark Dickinson <[EMAIL PROTECTED]> added the comment:
>
> Is this on Windows?  I can't reproduce it on OS X 10.5.2:
>
> Python 3.0a5+ (py3k:62937M, May  9 2008, 09:32:27)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>
> >>> x = 5.0
> >>> x.is_integer()
>
> True

I'm on Linux:

'3.0a5 (r30a5:62856, May  9 2008, 11:23:06) \n[GCC 4.1.2 20070925 (Red Hat 
4.1.2-33)]'
>>> (5.).as_integer_ratio()
(5, 1)
>>> (5.).is_integer()
Traceback (most recent call last):
  File "", line 1, in 
(5.).is_integer()
ValueError: (11, 'Resource temporarily unavailable')

(I can't test on Windows because Py30a5 isn't available for it yet.)

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2802] str.format() :n integer output

[Eric Smith]

Eric Smith <[EMAIL PROTECTED]> added the comment:

The reason for this is that 'n' is defined in PEP 3101 as being a float
format only, and the rule is that if an integer sees a float format, it
does a float conversion and then prints the float with the supplied format.

I'd be okay with adding 'n' as an integer format, with the loose
definition of "just like 'd', but adding thousands separators".

As to the implementation, the OS supplied float formatting does not add
thousands separators.  I added the function add_thousands_grouping() to
Python/pystrtod.c in order implement this for floats.  It would be easy
to make this same code work for integers (and in fact it might already
work, although there are probably memory allocation issues to deal with).

Maybe we should bring up modifying the PEP on python-dev or python-3000.

This issue exists in 2.6 as well.

--
components: +Interpreter Core
versions: +Python 2.6

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2802] str.format() :n integer output

[Mark Summerfield]

Mark Summerfield <[EMAIL PROTECTED]> added the comment:

On 2008-05-09, Mark Dickinson wrote:
> Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> > I think that n should stay the same for floats, but for integers should
> > never switch to g, but just use as many separators as needed.
>
> I agree with this, in principle.  It might be some work to implement,
> though:  for floats, Python gets to use the OS-supplied formatting
> functions.  Indeed, it looks as though all that happens here is that the
>
> integer is converted to a float before formatting:
> >>> print("{0:n} ".format(10**400), end="")
>
> Traceback (most recent call last):
>   File "", line 1, in 
> OverflowError: Python int too large to convert to C double
>
> For integers, we'd have to roll our own code. I had similar problems
> trying to implement the 'n' format code for Decimal;  in the end I just
> gave up and left it unimplemented.  Maybe using 'n' for an integer should
> just raise an exception, for now?
>
> Eric, what do you think?

It isn't hard (in Python):

import locale
locale.setlocale(locale.LC_ALL, "")
separator = locale.localeconv()["thousands_sep"]

def n_format(integer, separator):
chars = []
for i, char in enumerate(reversed("{0:d}".format(integer))):
if i and not i % 3:
chars.insert(0, separator)
chars.insert(0, char)
return "".join(chars)

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2801] Py30a5 float.is_integer() raises ValueError

[Mark Summerfield]

Mark Summerfield <[EMAIL PROTECTED]> added the comment:

OK, I've just built against your fix and it works fine now!

Python 3.0a5+ (py3k:60668:62940, May  9 2008, 15:48:15)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (5.).as_integer_ratio()
(5, 1)
>>> (5.).is_integer()
True

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2802] str.format() :n integer output

[Eric Smith]

Eric Smith <[EMAIL PROTECTED]> added the comment:

> It isn't hard (in Python):



It's more complex, because the "3" is locale dependent, and is allowed
to be something like "3, then 2, then 3, then 1, repeating until the
start of the string".

See _group() in Lib/locale.py.

In any event, the code needs to be in C (sadly).  But as I said in my
previous comment (which probably crossed paths with yours), this C code
already exists.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2802] str.format() :n integer output

[Mark Summerfield]

Mark Summerfield <[EMAIL PROTECTED]> added the comment:

On 2008-05-09, Eric Smith wrote:
> Eric Smith <[EMAIL PROTECTED]> added the comment:
>
> The reason for this is that 'n' is defined in PEP 3101 as being a float
> format only, and the rule is that if an integer sees a float format, it
> does a float conversion and then prints the float with the supplied format.
>
> I'd be okay with adding 'n' as an integer format, with the loose
> definition of "just like 'd', but adding thousands separators".
>
> As to the implementation, the OS supplied float formatting does not add
> thousands separators.  I added the function add_thousands_grouping() to
> Python/pystrtod.c in order implement this for floats.  It would be easy
> to make this same code work for integers (and in fact it might already
> work, although there are probably memory allocation issues to deal with).
>
> Maybe we should bring up modifying the PEP on python-dev or python-3000.

I hope that you do:-)

> This issue exists in 2.6 as well.
>
> --
> components: +Interpreter Core
> versions: +Python 2.6
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2802] str.format() :n integer output

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

> As to the implementation, the OS supplied float formatting does not add
> thousands separators.  I added the function add_thousands_grouping() to
> Python/pystrtod.c in order implement this for floats.

Excellent!  I didn't realise this code was already there.  Maybe there's 
also some way to use it to implement 'n' formatting for Decimal (which in 
some ways behaves like a hybrid floating-point and integer type).

I can't think of any reason that the LC_NUMERIC stuff shouldn't apply to 
integers as well as floats.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2803] heapq.heappush called with too few arguments in sched.py

[Matt Harden]

New submission from Matt Harden <[EMAIL PROTECTED]>:

In the method scheduler.run in the sched module, heapq.heappush is
called with single argument (event).  It's a two argument function.  The
correct call would be heapq.heappush(q, event).

This problem is probably not frequently experienced because it only
occurs if the delay function modifies the queue, deleting the top entry
while sched.run() is waiting to execute it.

A patch is attached based on the trunk.

--
components: Library (Lib)
files: sched.py.patch
keywords: patch
messages: 66480
nosy: mthard
severity: normal
status: open
title: heapq.heappush called with too few arguments in sched.py
type: crash
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10233/sched.py.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2801] Py30a5 float.is_integer() raises ValueError

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

Thanks, Mark.

I've also backported the fix to the trunk in r62943.

--
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2487] ldexp(x,n) misbehaves when abs(n) is large

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

I've committed a (slightly reworked) version of this patch in r62948.
Closing this issue; the problem with 1 >> 2**31 is a separate issue.  

Thanks for the report, Fredrik.

--
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2664] The position of special value tables (cmathmodule.c)

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

I'm actually pretty happy with the tables the way they are;  everything's 
working at the moment, and the current code seems clear enough.

Do you have a strong reason to want this change?

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2782] datetime/date strftime() method and time.strftime() inconsistency

[broadus jones]

Changes by broadus jones <[EMAIL PROTECTED]>:


--
nosy: +sbj3

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2804] Integer right shift raises OverflowError when second operand is large

[Mark Dickinson]

New submission from Mark Dickinson <[EMAIL PROTECTED]>:

In Python 2.6a3:

>>> 1 >> (2**31)  # unexpected exception
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: long int too large to convert to int
>>> 1 >> (2**31-1)  # works as expected
0L

It might make more sense for the first expression to return 0 instead.
Similarly, perhaps 0 << (2**31) should also return 0.

--
components: Interpreter Core
messages: 66484
nosy: marketdickinson
severity: normal
status: open
title: Integer right shift raises OverflowError when second operand is large
type: behavior
versions: Python 2.6, Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2804] Integer right shift raises OverflowError when second operand is large

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

Attached patch makes a >> b return 0 for b > maxsize.

--
keywords: +patch
nosy: +belopolsky
Added file: http://bugs.python.org/file10234/issue2804.diff

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2805] 2to3 doesn't correct divisions

[Guilherme Polo]

New submission from Guilherme Polo <[EMAIL PROTECTED]>:

Given the sample code:

  for i in range(len([1, 2]) / 2): pass

  print 2 / 3

2to3 tells no files need to be modified after running it over this code,
but range doesn't accept float values and the print result will differ.
Would it be too expensive for 2to3 to suggest changing '/' to '//' ?

--
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 66486
nosy: collinwinter, gpolo
severity: normal
status: open
title: 2to3 doesn't correct divisions

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2804] Integer right shift raises OverflowError when second operand is large

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

On the second thought, it is theoretically possible to have a long int a
for which a >> maxsize is not zero because that would require only
maxsize/15 digits.  I am not sure it is worth the trouble to account for
that.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2805] 2to3 doesn't correct divisions

[Collin Winter]

Collin Winter <[EMAIL PROTECTED]> added the comment:

My gut feeling is that the number of cases where both operands are
written as literals is exceedingly small when compared to the number of
cases where one or both is an identifier. Since 2to3 doesn't support
type inference, we'd miss the relevant, interesting cases. However, if
you're interested in implementing a fix_literal_division fixer module
that would catch these cases, I'd be happy to advise on such a thing :)

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2804] Integer right shift raises OverflowError when second operand is large

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

> On the second thought, it is theoretically possible to have a long int 
a
> for which a >> maxsize is not zero

This occurred to me too; somehow this hardly seems worth worrying about-
--there are already other problems in longobject.c when integers get 
very large, and I don't think one more is going to hurt.  Perhaps a 
warning somewhere in the documentation would be appropriate.

(It seems to me that if anyone really cares, the *right* thing to do is
to limit all integers to be at most maxsize bits long.)

Thanks for the patch!  I'll take a look.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2805] 2to3 doesn't correct divisions

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

If I were to add such fixer, should I wait for changes coming by gsoc
projects ? I did a quick pass through 2to3 code a while ago, but I'm
very far from understanding it in a good manner so I'm not sure if I
should starting doing that now because it looks like a GSoC project is
planning to change how 2to3 works.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1733134] sqlite3.dll cannot be relocated

[Mark Summerfield]

Mark Summerfield <[EMAIL PROTECTED]> added the comment:

Unfortunately, this bug appears to affect Py30a5 too (at least on Win XP
Home):

Python 3.0a5 (py3k:62932M, May  9 2008, 16:23:11) [MSC v.1500 32 bit
(Intel)] on win32

IDLE 3.0a5  
>>> import sqlite3
Traceback (most recent call last):
  File "", line 1, in 
import sqlite3
  File "c:\Python30\lib\sqlite3\__init__.py", line 24, in 
from sqlite3.dbapi2 import *
  File "c:\Python30\lib\sqlite3\dbapi2.py", line 27, in 
from _sqlite3 import *
ImportError: DLL load failed: The specified module could not be found.

--
nosy: +mark

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2806] Py30a5: Tk Menu Alt-f behaves differently Linux vs Windows

[Mark Summerfield]

New submission from Mark Summerfield <[EMAIL PROTECTED]>:

#Python 3.0a5 (py3k:62932M, May  9 2008, 16:23:11) [MSC v.1500 32 bit
#(Intel)] on win32
#
# If you run this tiny program on Linux and press Alt+F (Alt-f in Tk 
# terminology) the File menu pops up as expected. But run it on
# Windows Home XP and nothing happens when you press Alt+F.
# The problem may be with the code below since IDLE works fine on
# Windows, in which case sorry!
# However, Grayson's AppB/menu.py example (with suitably fixed print
# statements since it was writtend for Py2) is exactly the same: 
# works fine on Linux but Alt+key does not invoke the menus on Windows.
from Tkinter import *

class MainWindow:

def __init__(self, parent):
self.parent = parent

menuBar = Frame(self.parent, relief=RAISED, borderwidth=2)
menuBar.pack(anchor=N, fill=X)
fileMenu = Menubutton(menuBar, text="File", underline=0)
fileMenu.pack(side=LEFT)
fileMenu.menu = Menu(fileMenu, tearoff=False)
for label, command in (
("New...", self.fileNew),
("Open...", self.fileOpen),
("Quit", self.fileQuit)):
fileMenu.menu.add_command(label=label, command=command)
fileMenu["menu"] = fileMenu.menu
menuBar.tk_menuBar(fileMenu)

def fileNew(self, *args):
print("fileNew", args)

def fileOpen(self, *args):
print("fileOpen", args)

def fileQuit(self, *args):
self.parent.destroy()

root = Tk()
window = MainWindow(root)
root.protocol("WM_DELETE_WINDOW", window.parent.destroy)
root.mainloop()

--
messages: 66492
nosy: mark
severity: normal
status: open
title: Py30a5: Tk Menu Alt-f behaves differently Linux vs Windows
type: behavior
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2805] 2to3 doesn't correct divisions

[Collin Winter]

Collin Winter <[EMAIL PROTECTED]> added the comment:

I say do it before the GSoC projects complete. Those projects will take
months, and we can't stop development for that long.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2807] Remove the API PyUnicode_AsString()

[Alexandre Vassalotti]

New submission from Alexandre Vassalotti <[EMAIL PROTECTED]>:

Marc-Andre Lemburg noted:

  BTW: The API PyUnicode_AsString() is pretty useless by itself - there's
  no way to access the size information of the returned string without
  again going to the Unicode object.
  
  I'd suggest to remove the API altogether and not only deprecating it.
  
  Furthermore, the API PyUnicode_AsStringAndSize() does not follow the API
  signature of PyString_AsStringAndSize() in that it passes back the
  pointer to the string as output parameter. That should be changed as
  well. Note that PyString_AsStringAndSize() already does this for both
  8-bit strings and Unicode, so the special Unicode API is not really
  needed at all or you may want to rename PyString_AsStringAndSize() to
  PyUnicode_AsStringAndSize().
  
  Finally, since there are many cases where the string buffer contents are
  copied to a new buffer, it's probably worthwhile to add a new API which
  does the copying straight away and also deals with the overflow cases in
  a central place. I'd suggest PyUnicode_AsChar() (with an API like
  PyUnicode_AsWideChar()).

--
components: Interpreter Core, Unicode
messages: 66495
nosy: alexandre.vassalotti, lemburg
priority: normal
severity: normal
status: open
title: Remove the API PyUnicode_AsString()
type: feature request
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2807] Remove the API PyUnicode_AsString()

[Alexandre Vassalotti]

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment:

Honestly, I am not sure if removing PyUnicode_AsString() is a good idea.
There is many cases where the size of the returned string is not needed.
Furthermore, this would be a rather major backward-incompatible change
to be included in a beta release.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2807] Remove the API PyUnicode_AsString()

[Alexandre Vassalotti]

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment:

Oops, it seems Marc-André has already opened an issue about this.

Closing as duplicate.

--
resolution:  -> duplicate
status: open -> closed
superseder:  -> Remove PyUnicode_AsString(), rework 
PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2799] Remove PyUnicode_AsString(), rework PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()

[Alexandre Vassalotti]

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment:

Honestly, I am not sure if removing PyUnicode_AsString() is a good idea.
There is many cases where the size of the returned string is not needed.
Furthermore, this would be a rather major backward-incompatible change
to be included in a beta release.

[copied from duplicate issue #2807]

--
nosy: +alexandre.vassalotti

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2800] make htmlhelp creates python30a5.chm but msi.py expects pydoc.chm

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

This is now fixed in r62949.

I don't quite understood why this had the priority "high" - it just
worked fine the way it was - you just have to manually rename the result
file.

In any case, I'd appreciate if the file name scheme stays as-is unless a
change is mutually agreed upon.

As for setting snapshot to 0: absolutely no. This is the privilege of
whoever builds the official releases. Even somebody checking out a
release tag should not automatically build a release version of the MSI,
as it would then be questionable which of them is the official one (they
would use the same product code). Setting snapshot to 0 is a privilege
of the release engineer.

--
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2804] Integer right shift raises OverflowError when second operand is large

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

I'm -1 on this patch (or any other fixing the perceived problem).
Special cases aren't special enough to break the rules.

If you ever see this error in a real application, you have deeper
problems than the exception.

--
nosy: +loewis

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1267629] pdb: implement "until",fix for 1248119

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file6759/until.patch

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1267629] pdb: implement "until",fix for 1248119

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file10235/until.patch

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1733134] sqlite3.dll cannot be relocated

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> Unfortunately, this bug appears to affect Py30a5 too (at least on Win XP
> Home):

I'm somewhat skeptical that this is the same bug, though. Much more
likely related to switching to VS 2008 (and I'm skeptical that we
can resolve all VS 2008 issues before the release of 3.1).

Regards,
Martin

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2664] The position of special value tables (cmathmodule.c)

[Hirokazu Yamamoto]

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment:

Nope, I don't have strong reason. I just thought exceeding 80 line width
is a little ugly, and if data and function are close you can refer both
more easily. Please feel free to close this entry as "WONT FIX".

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2804] Integer right shift raises OverflowError when second operand is large

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

I'm not sure I understand.  What rule would be broken by this patch?

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2804] Integer right shift raises OverflowError when second operand is large

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> I'm not sure I understand.  What rule would be broken by this patch?

The (implicit) rule that there is a range limitation on the shift width.
The limitation would continue to exist, just not for selected left-hand
parameters. This is fairly arbitrary.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2804] Integer right shift raises OverflowError when second operand is large

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

On Fri, May 9, 2008 at 7:08 PM, Martin v. Löwis <[EMAIL PROTECTED]> wrote:
..
> I'm -1 on this patch (or any other fixing the perceived problem).
> Special cases aren't special enough to break the rules.
>
> If you ever see this error in a real application, you have deeper
> problems than the exception.

That was my first reaction as well, but then I thought that it was
easy to fix because the answer is guaranteed to be 0 for ridiculously
large right shifts.  However, since the patch is not theoretically
correct, I would only be +0 on applying it.

I also note that the current requirement is that shift fits long
rather than Py_ssize_t, which may lead to a >> sys.maxsize being
invalid on platforms where sizeof(long) < sizeof(Py_ssize_t).  This
may be a problem because sys.maxsize is likely to be used as a
placeholder for an arbitrary large number.

This said, I sill don't feel strongly one way or another.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2804] Integer right shift raises OverflowError when second operand is large

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

It's the current behaviour that seems arbitrary to me: a >> b is well-
defined, and efficiently computable, for any integer a and nonnegative 
integer b;  it seems odd to have an unnecessary and (from a user's 
viewpoint) arbitrary limit on the size of b.  It's simple to have the 
operation always succeed, and this seems to me like both the least 
surprising, and the most correct, thing to do.

On the other hand, I can't really think of any real-world uses for large 
shifts:  I'm guessing that in applications a shift of more than 63 or so  
must be rare.  So it probably doesn't matter that much one way or 
another.

Changing the limit on the shift to sys.maxsize rather than LONG_MAX 
would seem to make some sense, though.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2755] IDLE ignores module change before restart

[Terry J. Reedy]

Terry J. Reedy <[EMAIL PROTECTED]> added the comment:

On Windows, I tested this in both 2.5.2 and 3.0a4.
In both cases, at paragraph 4 of your report, I got 2 in the shell, as
you expected,not 1.  I have no idea whether the system difference makes
a difference (the TCL and TK binaries are obviously different also), or
you did not do what you think you did, or you encountered some random
glitch.  Perhaps you can try again?

If no one can reproduce, we will have to close, but I will wait for now.

--
nosy: +tjreedy

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2789] Comparsion datetime objects with None

[Terry J. Reedy]

Terry J. Reedy <[EMAIL PROTECTED]> added the comment:

You actually have it backwards ;-)  The arbitrary responses to
nonsensical cross-class order comparisons found in 1.x and 2.x are now
considered a design bug.  They are disappearing in 3.0.

Datetime is a fairly recent module (new in 2.3) written to the new
standard.  The number 1, for instance, in the same comparisons, raises
the same exceptions.  And the manual specifies this.  For instance, the
time class section on comparison explicitly says: "In order to stop
mixed-type comparisons from falling back to the default comparison by
object address, when a time object is compared to an object of a
different type, TypeError is raised unless the comparison is == or !=."

Closing as invalid.

As indicated in the quote, equality comparisons are different from order
comparisons.  None really is not equal to anything else.  This is still
true in 3.0.

--
nosy: +tjreedy
resolution:  -> invalid
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2782] datetime/date strftime() method and time.strftime() inconsistency

[Alexandr Zamaraev]

Changes by Alexandr Zamaraev <[EMAIL PROTECTED]>:


--
nosy: +shura_zam

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2295] cPickle corner case - docs or bug?

[Alexandre Vassalotti]

Changes by Alexandre Vassalotti <[EMAIL PROTECTED]>:


--
nosy: +alexandre.vassalotti

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2804] Integer right shift raises OverflowError when second operand is large

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

I still don't think the improvement in observable behavior is worth the
cost of additional code (and as Alexander observes, the patch in
file10234 is incorrect in boundary cases).

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com