[issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6

[tav]

tav <[EMAIL PROTECTED]> added the comment:

What's holding back the backport to 2.6?

--
nosy: +tav

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3228] mailbox.mbox creates files with execute bit set

[Niels Gustäbel]

Niels Gustäbel <[EMAIL PROTECTED]> added the comment:

I agree regarding the os.open call in MH.__setitem__. It does not
include the O_CREAT flag, so the mode would never be used.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3487] sre "bytecode" verifier

[Antoine Pitrou]

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

Shouldn't there be any unit tests? :)

--
nosy: +pitrou

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1432] Strange behavior of urlparse.urljoin

[Senthil]

Senthil <[EMAIL PROTECTED]> added the comment:

Yes, I agree with you, Roman. 

I have made changes to urlparse.urljoin which would behave confirming to
RFC3986. The join of BASE ("http://a/b/c/d;p?q";) with REL("?y") would
result in "http://a/b/c/d;p?y"; as expected.

I have added a set of testcases for conformance with RFC3986 as well.

Facundo: would you like to review this patch and commit it?

Thanks!

--
keywords: +patch
nosy: +facundobatista
versions: +Python 3.0
Added file: http://bugs.python.org/file11053/issue1432-py26.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1432] Strange behavior of urlparse.urljoin

[Senthil]

Senthil <[EMAIL PROTECTED]> added the comment:

Patch for py3k

Added file: http://bugs.python.org/file11054/issue1432-py3k.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1432] Strange behavior of urlparse.urljoin

[Senthil]

Changes by Senthil <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file9035/urlparse.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3455] os.remove()method document error

[香槟酒]

香槟酒 <[EMAIL PROTECTED]> added the comment:

I can't understand you. Could you explain more?

2008/7/29 Georg Brandl <[EMAIL PROTECTED]>

>
> Georg Brandl <[EMAIL PROTECTED]> added the comment:
>
> Can a file be "in use" other than being opened? If not, wouldn't be
> "opened" be a better wording?
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> 
> ___
>

Added file: http://bugs.python.org/file11055/unnamed

___
Python tracker <[EMAIL PROTECTED]>

___I can't understand you. Could you explain more?2008/7/29 Georg Brandl [EMAIL PROTECTED]>

Georg Brandl [EMAIL PROTECTED]> 
added the comment:

Can a file be "in use" other than being opened? If not, wouldn't 
be
"opened" be a better wording?

___
Python tracker [EMAIL 
PROTECTED]>
http://bugs.python.org/issue3455>
___

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

[issue3455] os.remove()method document error

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Well, you seemed to be misled by the wording "in use". Therefore, I
propose to change "in use" to "opened", but only if "in use" always
means "opened".

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3297] Python interpreter uses Unicode surrogate pairs only before the pyc is created

[Antoine Pitrou]

Changes by Antoine Pitrou <[EMAIL PROTECTED]>:


--
priority:  -> critical
versions: +Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

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

[issue643841] New class special method lookup change

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

Attaching a documentation patch for the moment until I get some info
back from Georg as to why I can't build the docs locally.

Once I get my local doc build working again, I'll check the formatting
and check it in.

--
assignee:  -> ncoghlan
Added file: http://bugs.python.org/file11056/special_method_lookup_docs.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue643841] New class special method lookup change

[Nick Coghlan]

Changes by Nick Coghlan <[EMAIL PROTECTED]>:


--
components: +Documentation -Library (Lib)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3487] sre "bytecode" verifier

[Barry A. Warsaw]

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:

Guido, this is fine for 3.0 and 2.6.  As Terry points out, it's not user
visible and it improves reliability.  I'm -0 on backporting it to 2.5,
but don't really feel strongly about that.

Go for it!

--
assignee: barry -> gvanrossum
priority: release blocker -> high
resolution:  -> accepted
versions:  -Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

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

[issue643841] New class special method lookup change

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

Committed for 2.6 as r65487.

I also blocked the automatic merge to 3.0 since the references to
old-style classes don't make sense there.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3498] mod_cls

[Robert Schuppenies]

New submission from Robert Schuppenies <[EMAIL PROTECTED]>:

Using sphinx I get the following error if I want to document methods via
automethod:

reading sources... copyright glossary [..] refbrowser Exception
occurred: File
  "[..]/doctools/sphinx/ext/autodoc.py", line 313, in resolve_name
if not mod_cls:
UnboundLocalError: local variable 'mod_cls' referenced before
assignment. [..]

I am not familiar with the code base, but from the comments the attached
patch should address the issue.

--
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: mod_cls.patch
keywords: patch
messages: 70697
nosy: georg.brandl, schuppenies
severity: normal
status: open
title: mod_cls
type: behavior
Added file: http://bugs.python.org/file11057/mod_cls.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3498] mod_cls

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Thanks, fixed in r65489.

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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue643841] New class special method lookup change

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

But don't the docs with patch describe the behavior of new-style classes
better?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue643841] New class special method lookup change

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

I meant to say that I will be merging it manually to avoid bringing the
old-style class specific parts over (that's why I left the issue open
and assigned to me).

___
Python tracker <[EMAIL PROTECTED]>

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

[issue643841] New class special method lookup change

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Ah, I'm sorry for the noise then.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3451] Asymptotically faster divmod and str(long)

[Mark Dickinson]

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

There's also the recursive division algorithm due
to Burnikel and Ziegler;  this might be worth a look.
I think it's the same asymptotic complexity (constant
times karatsuba multiplication complexity), but may
turn out to be faster for one reason or another.

I had a Python implementation of this somewhere;
I'll see if I can dig it out.

Assigning this to me so that it doesn't get lost or
forgotten;  but note that I don't intend to do
anything about it before 2.6/3.0 final.  If anyone else
wants to take it off my hands before then, feel free.

--
assignee:  -> marketdickinson
priority:  -> normal
type:  -> performance
versions: +Python 2.7, Python 3.1

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1746088] long.__str__ is quadratic time

[Mark Dickinson]

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

Closing this as a duplicate; it's superseded by issue 3451.

--
resolution:  -> duplicate
status: open -> closed
superseder:  -> Asymptotically faster divmod and str(long)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3451] Asymptotically faster divmod and str(long)

[Mark Dickinson]

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

See also issue 1746088.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3358] 2to3 Iterative Wildcard Matching

[Nick Edds]

Nick Edds <[EMAIL PROTECTED]> added the comment:

Here is a patch that tries to use the faster recursive matching, but if
there is a RuntimeError, it will use the iterative matching. It passes
all the tests and works on the ssl.py file that were known to break the
recursive matching.

Added file: http://bugs.python.org/file11058/iterative_recursive.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3499] Python 2.6 requires pre-installed Python to build

[Marc-Andre Lemburg]

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

Here's the "make -d" output:

 Prerequisite `Parser/Python.asdl' is older than target
`Include/Python-ast.h'.
 Prerequisite `Parser/asdl.py' is older than target
`Include/Python-ast.h'.
 Prerequisite `Parser/asdl_c.py' is newer than target
`Include/Python-ast.h'.
Must remake target `Include/Python-ast.h'.
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
/usr/bin/env: No such file or directory

And these are the file times:

orig/Python-2.6b2> ls -l Include/Python-ast.h
-rw-r--r-- 1 lemburg users 20081 2008-03-30 08:40 Include/Python-ast.h
orig/Python-2.6b2> ls -l Parser/asdl*
-rw-r--r-- 1 lemburg users 11306 2006-03-01 23:49 Parser/asdl.py
-rwxr-xr-x 1 lemburg users 39771 2008-06-09 06:58 Parser/asdl_c.py

Because Python-ast.h is older than the script used for generating it
(asdl_c.py), it always tries to rebuild the .h file. Since this requires
Python to be installed, it fails on a machine that doesn't always have
an existing Python binary installed.

This happens in both 2.6b1 and 2.6b2.

I guess the release process should make sure that the Python-ast.h and
Python-ast.c are always newer than the scripts used to build them.

--
components: Build
messages: 70706
nosy: lemburg
priority: critical
severity: normal
status: open
title: Python 2.6 requires pre-installed Python to build
versions: Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3499] Python 2.6 requires pre-installed Python to build

[Marc-Andre Lemburg]

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:

As work-around, you can untar the source tarball and then touch the
files in question:

touch Include/Python-ast.h
touch Python/Python-ast.c

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3463] make life.py use more rendering characters

[A.M. Kuchling]

A.M. Kuchling <[EMAIL PROTECTED]> added the comment:

I agree with tjreedy that this change is not very interesting for a demo
program.  It would be more interesting to add larger features such as
different cellular automata, mouse or colour support, or something like
that.

Thanks for your patch, anyway.

--
nosy: +akuchling
resolution:  -> rejected
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2305] Update What's new in 2.6

[A.M. Kuchling]

Changes by A.M. Kuchling <[EMAIL PROTECTED]>:


--
priority:  -> critical

___
Python tracker <[EMAIL PROTECTED]>

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

[issue836088] Update htmllib to HTML 4.01

[A.M. Kuchling]

A.M. Kuchling <[EMAIL PROTECTED]> added the comment:

Closing -- I'm not going to work on this patch further, and it seems
irrelevant.

--
status: pending -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2396] Backport memoryview object to Python 2.6

[A.M. Kuchling]

A.M. Kuchling <[EMAIL PROTECTED]> added the comment:

Is there still time to do the backport for 2.6 at this late date?

--
nosy: +akuchling

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2396] Backport memoryview object to Python 2.6

[Antoine Pitrou]

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

Not only there may not be enough time, but:
1. the memoryview implementation itself is not finished (that is, in py3k)
2. polishing and documenting the buffer API is more important
3. there doesn't seem to be any use for memoryview objects right now

So, IMO, this can be re-targeted to 2.7.

--
nosy: +pitrou

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2470] Need fixer for dl (removed) -> ctypes module

[Nick Edds]

Nick Edds <[EMAIL PROTECTED]> added the comment:

If nobody else is interested in or currently in the process of making a
fixer for this, I can do it. I'm not sure if I completely understand the
changes I need to make though. Importing dl needs to be replaced by
importing ctypes, calls to dl.open() need to be replaced by calls to
ctypes.CDLL(), and calls to call() from an open dl object need to be
replaced to calls to funcname, where funcname is the first argument to
call(). Also, any strings in the other arguments should be preceded with
b to make them byte objects. Is this all that needs doing or am I
missing something else? Are there more complicated cases that I should
also take into account?

--
nosy: +nedds

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2470] Need fixer for dl (removed) -> ctypes module

[Collin Winter]

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

I'd prefer it if someone better-versed in ctypes/dl wrote this fixer (or
at the very least, someone with access to Windows to test the translation).

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3500] unbound methods of different classes compare equal

[Jean-Paul Calderone]

New submission from Jean-Paul Calderone <[EMAIL PROTECTED]>:

If a method is inherited by two different classes, then the unbound
method objects which can be retrieved from those classes compare equal
to each other.  For example:

  Python 2.6b2+ (trunk:65502M, Aug  4 2008, 15:05:07)
  [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> class X:
  ... def y(self):
  ... pass
  ...
  >>> class A(X):
  ... pass
  ...
  >>> class B(X):
  ... pass
  ...
  >>> A.y == B.y
  True

This is bad behavior because A.y and B.y are otherwise distinguishable
(for example, they repr differently, they have different values for the
`im_class´ attribute, they cannot be used interchangably for invoking
the method because they place different type restrictions on the `self´
parameter, etc).

--
components: Interpreter Core
messages: 70714
nosy: exarkun
severity: normal
status: open
title: unbound methods of different classes compare equal
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3500] unbound methods of different classes compare equal

[Antoine Pitrou]

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

Well, I'm not sure. One could also argue that 1 and 1.0 mustn't compare
equal because they cannot be used equally in all circumstances (e.g.
__index__), they have different repr's, different types, etc.

The question is: what kind of use case does it help to have them compare
unequal? I can see the utility of having them compare equal: to check
whether a method has been overriden or not.

(I'm removing 2.4 and 2.5 anyway since the change would break compatibility)

--
nosy: +pitrou
versions: +Python 3.0 -Python 2.4, Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3500] unbound methods of different classes compare equal

[Jean-Paul Calderone]

Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment:

The reason I noticed this is that since they compare and hash equal, if
you put two such methods into a set, you end up with a set with one
method.  Currently, this is preventing me from running two test methods
because the method itself is defined on a base class and two subclasses
which customize several other methods inherit it.  I can only run one
test at a time.

Having them compare unequal means you can't actually trust unbound
method comparison, nor using unbound methods as keys in a dictionary. 
This means some other mapping structure is required if you want to keep
around a bunch of methods and arguments to pass to them.  It also means
that any time you want to check two methods against each other with the
goal of eventually calling one or both of them, you need to use
something other than `==´.  It seems like calling methods is likely to
be a more common use-case than anything else.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3500] unbound methods of different classes compare equal

[Antoine Pitrou]

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

> The reason I noticed this is that since they compare and hash equal, if
> you put two such methods into a set, you end up with a set with one
> method.  Currently, this is preventing me from running two test methods
> because the method itself is defined on a base class and two subclasses
> which customize several other methods inherit it.  I can only run one
> test at a time.

But you acknowledge they are really the same method attached to
different classes, right? The notion of "unbound method" is mostly an
implementation detail. The term occurs only 4 times in the whole Python
documentation (according to Google). And in py3k they are gone. (*)

Moreover, you say you want them to compare unequal because you
*explicitly* want the same method called separately for each class it is
defined on. Is there anything preventing you to have a set of (class,
method) tuples instead? Because it sounds like the logical thing to do
in your case.

> Having them compare unequal means you can't actually trust unbound
> method comparison, nor using unbound methods as keys in a dictionary.

"Trust" is a strong word. You can trust the comparison operator if you
agree with its semantics, you cannot trust it if you want different
semantics. But that doesn't mean it is generally trustworthy or
untrustworthy.

Really, this is the same as with numbers:

'b'

There are probably use cases where the above is annoying. But,
conversely, there are probably use cases where a stricter behaviour
would be annoying too.

> This means some other mapping structure is required if you want to keep
> around a bunch of methods and arguments to pass to them.

I disagree. The general use case of keeping a bunch of callables with
their respective arguments implies storing bound, not unbound, methods.
(how often do you feed an unbound method to an addCallback() ?)

> It also means
> that any time you want to check two methods against each other with the
> goal of eventually calling one or both of them, you need to use
> something other than `==´.

I don't think there are lots of use cases for comparing *unbound*
methods. One such use case is checking for redefinition of inherited
methods, and the current __eq__ semantics look fine for that.

(*)
Python 3.0b2+ (py3k, Jul 29 2008, 20:37:34) 
[GCC 4.3.1 20080626 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
...  def f(): pass
... 
>>> type(A.f)

>>> a = A()
>>> type(a.f)

>>> def g(): pass
... 
>>> class B:
...  g = g
... 
>>> B.g is g
True

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3500] unbound methods of different classes compare equal

[Antoine Pitrou]

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

Apparently Roundup snipped my numbers example :-)
Here it is, hoping it will pass through this time :

>>> d = {}
>>> d[1] = 'a'
>>> d[1.0] = 'b'
>>> d[1]
'b'

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3451] Asymptotically faster divmod and str(long)

[Mark Dickinson]

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

Here's a pure Python implementation of the Burnikel and Ziegler recursive 
division algorithm.  I've no idea whether it's faster or slower than 
Newton, but it might be worth a look.  It depends heavily on bit 
operations, which ought to be much faster when coded in C.  (Some of the 
shifts would be completely unnecessary---replaced by changes in indexing 
instead.)

The original paper describing the algorithm is available here:

http://cr.yp.to/bib/1998/burnikel.ps

Added file: http://bugs.python.org/file11059/fast_str.py

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3451] Asymptotically faster divmod and str(long)

[Mark Dickinson]

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

Oops.  Wrong file.  Here's the right one.

Added file: http://bugs.python.org/file11060/fast_div.py

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3451] Asymptotically faster divmod and str(long)

[Mark Dickinson]

Changes by Mark Dickinson <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11059/fast_str.py

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1481296] long(float('nan'))!=0L

[Mark Dickinson]

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

New patch committed, r65518.  Conversion of a nan to an integer now raises 
ValueError consistently across platforms.

--
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2211] Cookie.Morsel interface needs update

[Toshio Kuratomi]

Changes by Toshio Kuratomi <[EMAIL PROTECTED]>:


--
nosy: +a.badger

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3501] expm1 missing

[Mike Speciner]

New submission from Mike Speciner <[EMAIL PROTECTED]>:

The math module contains log1p but is missing expm1 (the inverse of
log1p). These functions are necessary to avoid loss of precision in
floating point calculations, and are part of the C99 standard math library.

--
components: None
messages: 70722
nosy: ms
severity: normal
status: open
title: expm1 missing
type: feature request
versions: Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3501] expm1 missing

[Mark Dickinson]

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

Mike,

Can you propose an implementation, for those platforms that haven't yet 
caught up with C99?  Something comparable to the implementation of log1p 
in Python/pymath.c would be appropriate.  Ideally, such an 
implementation would:

- be accurate to within a few ulps across the whole domain,
- be not too long, and not too slow
- have a decent chance of working with strange floating-point formats 
(Python doesn't assume IEEE 754)
- handle IEEE 754 values 'correctly' (i.e., as recommended by Annex F to 
the C99 standard)

It's too late to get this into Python 2.6/3.0, but patches aimed at 2.7 
or 3.1 would be welcome.

--
nosy: +marketdickinson

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3501] expm1 missing

[Mark Dickinson]

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

A cheap trick would be to use the identity

  expm1(x) = 2*exp(x/2)*sinh(x/2)

This could also be used in Python as a
workaround, for now.  But I agree that
expm1 should go into the math library.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3502] Inconsistency between string.letters and default encoding.

[Ramon Garcia]

New submission from Ramon Garcia <[EMAIL PROTECTED]>:

In python on Windows, under Idle, the string.letters includes extended
characters. But the default codec, used when translating from string to
unicode, is still ascii. This behaviour causes crashes with python win32
extensions.

>>> string.letters

'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\x83\x8a\x8c\x8e\x9a\x9c\x9e\x9f\xaa\xb5\xba\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff'

But still, unless the user customizes the installation,
sys.getdefaultencoding() returns ascii.

The consequence is that after instating a COM object, pywin32 211 issues
this exception:

  File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
297, in MakeFuncMethod
return self.MakeDispatchFuncMethod(entry, name, bMakeClass)
  File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
318, in MakeDispatchFuncMethod
s = linePrefix + 'def ' + name + '(self' + BuildCallList(fdesc,
names, defNamedOptArg, defNamedNotOptArg, defUnnamedArg, defOutArg) + '):'
  File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
604, in BuildCallList
argName = MakePublicAttributeName(argName)
  File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
542, in MakePublicAttributeName
return filter( lambda char: char in valid_identifier_chars, className)
  File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
542, in 
return filter( lambda char: char in valid_identifier_chars, className)
UnicodeDecodeError: 'ascii' codec can't decode byte 0x83 in position 52:
ordinal not in range(128)



The line that causes this exception is from win32com.client.build.

This fragment is enough to reproduce the bug (from build.py in
win32com/client):

valid_identifier_chars = string.letters + string.digits + "_"
...
return filter( lambda char: char in valid_identifier_chars, className)

Try to print the expression in the return statement and set className to
anything you wish in Unicode. It will crash

It is contradictory that the default codec does not allow translation of
characters  0x83, and that string.letters includes it. If one regards
this character as printable, then it should be encoded successfully.

--
components: Windows
messages: 70725
nosy: ramong
severity: normal
status: open
title: Inconsistency between string.letters and default encoding.
versions: Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3228] mailbox.mbox creates files with execute bit set

[A.M. Kuchling]

A.M. Kuchling <[EMAIL PROTECTED]> added the comment:

I took one test and an idea from Niels' patch -- checking for the
existence of 
os.stat as well as os.umask -- and applied it as rev. 65536.  

Closing this issue now.  Thanks, everyone!

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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3503] Calls to print() function in Python 3.0 tutorial

[Jim Sizelove]

New submission from Jim Sizelove <[EMAIL PROTECTED]>:

I decided to learn more about the coming changes in Python 3.0 by
installing the beta and working through the tutorial.  I found some
discrepancies between the code examples and the output I got.  The
attached patch shows several places where the print() function is called
incorrectly.  These are mostly examples that are missing the parentheses.

The rest of this comment pertains to only one change included in the
patch that I find less than satisfactory.  In introduction.html, there
is an example of printing a fibonacci sequence in one line of output by
using the end keyword.  When actually run in the python interpreter, the
>>> prompt shows at the end of the same line as the fibonacci numbers. 
The patch fixes this by enclosing a "print()" within an else clause.

This "fix" produces the expected output, but I don't think the else
clause has been described yet in the tutorial.  A better fix would be to
wrap the while statement in a function with a print() function call
after the end of the while statement (this is how the fib() function is
defined in http://docs.python.org/dev/3.0/tutorial/modules.html).  But
functions have not been explained this early in the tutorial.

Perhaps it would be best to drop this example of using the end keyword
to the print function in the introduction and explain it later in the
tutorial.

--
assignee: georg.brandl
components: Documentation
files: print.diff
keywords: patch
messages: 70727
nosy: georg.brandl, jsizelove
severity: normal
status: open
title: Calls to print() function in Python 3.0 tutorial
versions: Python 3.0
Added file: http://bugs.python.org/file11061/print.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3367] Uninitialized value read in parsetok.c

[A.M. Kuchling]

A.M. Kuchling <[EMAIL PROTECTED]> added the comment:

This patch was applied in rev. 65539, but then reverted; it turns out to 
break Lib/test/test_parser.py.  The exception is:

raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_parser.py", line 222, in test_position
terminals)
AssertionError: [(1, 'def', 1, 0), (1, 'f', 1, 4), (7, '(', 1, 5), (1,
'x', 1, 6), (8, ')', 1, 7), (11, ':', 1, 8), (4, '', 1, 9), (5, '', 2,
-1), (1, 'return', 2, 4), (1, 'x', 2, 11), (14, '+', 2, 13), (2, '1', 2,
15), (4, '', 2, 16), (6, '', 2, -1), (4, '', 2, -1), (0, '', 2, -1)] != 
[(1, 'def', 1, 0), (1, 'f', 1, 7033504), (7, '(', 1, 7033505), (1, 'x',
1, 7033506), (8, ')', 1, 7033507), (11, ':', 1, 7033508), (4, '', 1,
7033509), (5, '', 2, -1), (1, 'return', 2, 7033514), (1, 'x', 2,
7033521), (14, '+', 2, 7033523), (2, '1', 2, 7033525), (4, '', 2,
7033526), (6, '', 2, 0), (4, '', 2, 0), (0, '', 2, 0)]

In the resulting output, the columns are incorrect large values
(7033504, 7033505) or they're 0 where -1 is expected.

I took a look into why this happened, but made no progress.  Removing
the 'easy' keyword.  :)

--
keywords:  -easy
nosy: +akuchling

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3487] sre "bytecode" verifier

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

Submitted to 2.6 as r65544.

Will propagate to 3.0 as it gets merged -- should be a perfect merge.

Antoine: the re module has tons of unittests; showing that attempts to
break in are thwarted would be pretty boring. ;-)

--
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3502] Inconsistency between string.letters and default encoding.

[Martin v. Löwis]

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

That's a bug in the Win32 extensions. They shouldn't use string.letters,
but string.ascii_letters, in particular when they check for valid
identifier chars.

Closing this report as "won't fix".

--
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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