[issue3041] autodoc does not support unicode docstrings

[Christophe de Vienne]

New submission from Christophe de Vienne <[EMAIL PROTECTED]>:

If I define unicode docstrings in my python source, autodoc crash
because it tries to decode them, which force a ascii encode first.

A trivial patch fix the issue :

Index: sphinx/ext/autodoc.py
===
--- sphinx/ext/autodoc.py   (révision 63954)
+++ sphinx/ext/autodoc.py   (copie de travail)
@@ -218,7 +218,7 @@
 module = getattr(todoc, '__module__', None)
 if module is not None:
 charset = get_module_charset(module)
-docstrings = [docstring.decode(charset) for docstring in
docstrings]
+docstrings = [docstring.decode(charset) for docstring in
docstrings if not isinstance(docstring, unicode)]
 
 # add docstring content
 for docstring in docstrings:

--
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 67710
nosy: cdevienne, georg.brandl
severity: normal
status: open
title: autodoc does not support unicode docstrings
type: crash

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3039] tarfile.TarFileCompat.writestr(ZipInfo, str) raises AttributeError

[Lars Gustäbel]

Changes by Lars Gustäbel <[EMAIL PROTECTED]>:


--
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3042] Add PEP 8 compliant aliases to threading module

[Nick Coghlan]

New submission from Nick Coghlan <[EMAIL PROTECTED]>:

PEP 371 highlighted the non-PEP 8 compliant nature of the threading API.
Since part of that PEP involves updating the multiprocessing API to be
PEP 8 compliant before addition the standard library, the threading API
should also be updated to be PEP 8 compliant in 3.0.

That part's easy - the trickier part if to provide both the existing API
and a PEP 8 compliant API in 2.6, with the old names triggering a
warning when run with the -3 switch, but not suffering a performance hit
otherwise.

The trick with that is to define the renamed API's differently depending
on whether or not sys.py3kwarning is set, rather than checking it every
time the old APIs are invoked.

(Left unassigned for the moment, since I'm about to go completely
offline for a few days, so it will be tough for me to get to this before
the first beta)

--
components: Library (Lib)
messages: 67711
nosy: ncoghlan
priority: high
severity: normal
status: open
title: Add PEP 8 compliant aliases to threading module
type: feature request
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:

I've attached the latest version of the module as an actual patch
against Python SVN.

It differs slightly from the last version uploaded as separate files, in
that in-place operations on a proxied object will no longer strip the
proxy wrapper off the object. Instead, either the same proxy object will
be returned if the target returned itself from the in-place operation
(mutable objects), or a new proxy wrapper around the result of the
target returned a different object (immutable objects).

Example with a mutable target:
>>> from typetools import ProxyMixin as p
>>> x = p([])
>>> last_x = x
>>> x += [1]
>>> x

>>> last_x


Example with an immutable target:
>>> from typetools import ProxyMixin as p
>>> x = p(1)
>>> last_x = x
>>> x += 1
>>> x

>>> last_x


Added file: http://bugs.python.org/file10521/issue643841_typetools.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]

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

Note that I'll be offline for the next few days, so I want be able to
respond to any comments until some time next week.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3004] Bug in slice.indices()

[Mark Dickinson]

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

I agree that those -1s should really be 0s.

Do you have any examples of real-life code
that's affected by this bug?  It doesn't seem
like something that would be a problem in
practice.

--
nosy: +marketdickinson
priority:  -> normal

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3042] Add PEP 8 compliant aliases to threading module

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Is this what you were looking for? (in the patch) What I did could also
be done with metaclasses, but I thought that would be overkill. Warning:
this patch causes test threading to crash when run with the -3 flag.

--
keywords: +patch
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file10522/new_threading_api.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Peter N]

Peter N <[EMAIL PROTECTED]> added the comment:

Martin,

On solaris 10 x86, this patch makes it possible to build python 2.5.x.
Without it, there is no way for the automated build to work. I believe
that your characterization of it as "Therefore, I claim that this makes
things more complex, and doesn't solve an actual problem." is strangely
disconnected from the facts that have been presented to you.

So, since this patch allows python to be built 64-bit on a biarch
system, and without it, the build doesn't work, what would need to
change so that you/the python maintainers would accept a fix? Assuming
this patch isn't it, what needs to change? I think that in this entire
conversation a set of viable parameters haven't been presented.

As it is, python is ridiculously difficult to build for my company's
environment which has separate packages in separate directories (eg
/usr/local/amd64/expat/ for expat, /usr/local/amd64/gnu/lib for readline
and ncurses, etc.)

Thanks,

-Peter

--
nosy: +spacey

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3042] Add PEP 8 compliant aliases to threading module

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Attaching a patch which fixes everything.

Added file: http://bugs.python.org/file10523/new_threading_api2.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3038] Return results from Python callbacks to Tcl as Tcl objects, please backport it.

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
assignee:  -> loewis
nosy: +loewis

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3041] autodoc does not support unicode docstrings

[Georg Brandl]

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

Thanks, fixed in r63958.

--
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

[Adam Olsen]

Adam Olsen <[EMAIL PROTECTED]> added the comment:

The inplace operators aren't right for weakref proxies.  If a new object
is returned there likely won't be another reference to it and the
weakref will promptly be cleared.

This could be fixed with another property like _target, which by default
type(self)(result).  Weakref proxies could override it to raise an
exception instead.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Martin v. Löwis]

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

> So, since this patch allows python to be built 64-bit on a biarch
> system, and without it, the build doesn't work

This is simply not true. I can build Python 2.5 just fine for 64-bit
SPARC, using gcc, with

CC="gcc -m64" ./configure
make

Or, using SunPRO, with

CC="cc -m64" ./configure
make

I tested it myself, and it successfully builds a Python executable
(For gcc, the extension modules fail to load because it picks up
the wrong libgcc_s, which I believe is a gcc installation bug. For
SunPRO, the extension modules also build fine).

So before anything is fixed, I'd like to see an actual, reliable,
reproducable error report. The subject of this report (Python 2.5
64 bit compile fails on Solaris 10 with gcc) is not reproducable,
so I'm tempted to close this report as "works for me".

___
Python 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:

I now think the proposed changes wouldn't be bad thing, after all. I
have been bitten myself by the confusing naming of the Unicode API. So,
there is definitely a potential for errors. 

The main problem with PyUnicode_AsString(), as Marc-André pointed out,
is it doesn't follow the API signature of the rest of the Unicode API:

char *PyUnicode_AsString(PyObject *unicode);
PyObject *PyUnicode_AsUTF8String(PyObject *unicode);
PyObject *PyUnicode_AsASCIIString(PyObject *unicode);

On the other hand, I do like the simple API of PyUnicode_AsString. Also,
I have to admit that the apparent similarity between the PyString and
the PyUnicode API helped me to port my code to Py3K when I first started
working on Python core. So, pragmatism might beat purity here.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Martin v. Löwis]

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

> Your method is just flat wrong - equivalent to using a sledgehammer. The 
> libraries fail to link not because gcc install is wrong but because the 
> -m64 flag needs to be passed to the linker.

And indeed, the flag *is* passed to the linker. Python links with CC
unless specified otherwise, which will be "gcc -m64". That ought to
work, and it does work when linking Python itself.

> Your method just fixes the compilation stage.

Not true.

> To be sure I really don't care anymore - we will continue to apply the 
> patches that we have to fix the build problem however, we will also 
> actively discourage the use of Python for our customers and all future 
> development/deployment since it is obvious that as the maintainer you 
> are completely closed minded and uncooperative when it comes to fixing 
> things.

I'm sorry you feel that way. Feel free to bring up the issue on
python-dev if you think you are being ignored. I assure you this is
not the case - but I want to see the problem first before accepting
fixes.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Bob Atkins]

Bob Atkins <[EMAIL PROTECTED]> added the comment:

Martin,

Your method is just flat wrong - equivalent to using a sledgehammer. The 
libraries fail to link not because gcc install is wrong but because the 
-m64 flag needs to be passed to the linker. Your method just fixes the 
compilation stage. You are blaming the gcc installation for your problem 
when in fact the /_*rest*_/ of the open source world builds just fine 
using gcc when the proper flags are passed at the proper stages of the 
build.

This situation is so sad to see. This isn't the way open source 
development is supposed to be. Basically _/*you*/_ alone are the 
gatekeeper and you are refusing to deal with what is a very simple problem.

To be sure I really don't care anymore - we will continue to apply the 
patches that we have to fix the build problem however, we will also 
actively discourage the use of Python for our customers and all future 
development/deployment since it is obvious that as the maintainer you 
are completely closed minded and uncooperative when it comes to fixing 
things.

My suggestion for the rest of the Python community is to branch and 
re-host the Python project elsewhere if anyone wants to see it move forward.

Added file: http://bugs.python.org/file10524/unnamed
Added file: http://bugs.python.org/file10525/DigiLink_esig_logo.jpg

___
Python tracker <[EMAIL PROTECTED]>

___


  


Martin,

Your method is just flat wrong - equivalent to using a sledgehammer.
The libraries fail to link not because gcc install is wrong but because
the -m64 flag needs to be passed to the linker. Your method just fixes
the compilation stage. You are blaming the gcc installation for your
problem when in fact the rest of the open source
world builds just fine using gcc when the proper flags are passed at
the proper stages of the build.

This situation is so sad to see. This isn't the way open source
development is supposed to be. Basically you
alone are the gatekeeper and you are refusing to deal with what is a
very simple problem.

To be sure I really don't care anymore - we will continue to apply the
patches that we have to fix the build problem however, we will also
actively discourage the use of Python for our customers and all future
development/deployment since it is obvious that as the maintainer you
are completely closed minded and uncooperative when it comes to fixing
things.

My suggestion for the rest of the Python community is to branch and
re-host the Python project elsewhere if anyone wants to see it move
forward.

-- 

Untitled Document


  

  Bob
Atkins  


  President/CEO


  
  http://www.digilink.net";>
  Business Inter-net-working
  The Cure for the Common 
ISP!
  
  
  Phone: (310) 577-9450
  Fax: (310) 
577-3360
  eMail: mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]
  
  

  




Martin v. Löwis wrote:

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

  
  
So, since this patch allows python to be built 64-bit on a 
biarch
system, and without it, the build doesn't work

  
  
This is simply not true. I can build Python 2.5 just fine for 64-bit
SPARC, using gcc, with

CC="gcc -m64" ./configure
make

Or, using SunPRO, with

CC="cc -m64" ./configure
make

I tested it myself, and it successfully builds a Python executable
(For gcc, the extension modules fail to load because it picks up
the wrong libgcc_s, which I believe is a gcc installation bug. For
SunPRO, the extension modules also build fine).

So before anything is fixed, I'd like to see an actual, reliable,
reproducable error report. The subject of this report (Python 2.5
64 bit compile fails on Solaris 10 with gcc) is not reproducable,
so I'm tempted to close this report as "works for me".

___
Python tracker mailto:[EMAIL 
PROTECTED]"><[EMAIL PROTECTED]>
http://bugs.python.org/issue1628484";>;
___


  



  



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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Martin v. Löwis]

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

Just to demonstrate there is really a problem with the gcc installation
(gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)), here is the
linker line:

gcc -m64 -shared
build/temp.solaris-2.10-sun4u-2.5/net/tb0/home/loewis/25/Modules/_struct.o
-L/usr/local/lib -o build/lib.solaris-2.10-sun4u-2.5/_struct.so

and here is what gcc actually invokes (printed with -v):

/usr/sfw/libexec/gcc/sparc-sun-solaris2.10/3.4.3/collect2 -V -G -dy -z
text -Y P,/usr/lib/sparcv9 -Qy -o
build/lib.solaris-2.10-sun4u-2.5/_struct.so
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crti.o
/usr/ccs/lib/sparcv9/values-Xa.o
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtbegin.o
-L/usr/local/lib -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9
-L/usr/ccs/lib/sparcv9
-L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../sparcv9
-L/lib/sparcv9 -L/usr/lib/sparcv9
build/temp.solaris-2.10-sun4u-2.5/net/tb0/home/loewis/25/Modules/_struct.o
-R/usr/sfw/lib -lgcc_s_sparcv9 -R/usr/sfw/lib -lgcc_s_sparcv9
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtend.o
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtn.o

As you can see, it's picking up -lgcc_s_sparcv9 (from
/usr/sfw/lib/sparcv9/libgcc_s_sparcv9.so), so it does link with the
64-bit libgcc_s.so.1. However, when then trying to import the module, it
complains 

ImportError: ld.so.1: python: fatal: /usr/sfw/lib/libgcc_s.so.1: wrong
ELF class: ELFCLASS32

This is due to the option -R/usr/sfw/lib, which should have been
-R/usr/sfw/lib/sparcv9. Fixing the specs file to change the -R option
actually fixes that problem.

So please don't claim that I did something wrong when there is really a
bug in sfw version of gcc.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Bob Atkins]

Bob Atkins <[EMAIL PROTECTED]> added the comment:

I rest my case - you found /_*one*_/ of the problems which you are 
blaming on gcc but in fact is not gcc's fault. You /_*must*_/ specify 
the correct -L and -R paths to the various alternate 64 bit libs. Don't 
expect the compiler to figure it out. Of course you can also fix the 
problem by changing the defaults to the system link/loader and I'm sure 
other non-standard methods.

The bottom line is that I just don't know how to describe daylight to a 
blind man

FYI, we are using gcc 4.1.1 - same problem and we aren't using or 
relying on just the /usr/sfw tree sine much of what comes with Solaris 
isn't 64 bit we have had to build our own libs which are kept in /opt/lib

---
Bob

Martin v. Löwis wrote:
> Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>
> Just to demonstrate there is really a problem with the gcc installation
> (gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)), here is the
> linker line:
>
> gcc -m64 -shared
> build/temp.solaris-2.10-sun4u-2.5/net/tb0/home/loewis/25/Modules/_struct.o
> -L/usr/local/lib -o build/lib.solaris-2.10-sun4u-2.5/_struct.so
>
> and here is what gcc actually invokes (printed with -v):
>
> /usr/sfw/libexec/gcc/sparc-sun-solaris2.10/3.4.3/collect2 -V -G -dy -z
> text -Y P,/usr/lib/sparcv9 -Qy -o
> build/lib.solaris-2.10-sun4u-2.5/_struct.so
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crti.o
> /usr/ccs/lib/sparcv9/values-Xa.o
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtbegin.o
> -L/usr/local/lib -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9
> -L/usr/ccs/lib/sparcv9
> -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../sparcv9
> -L/lib/sparcv9 -L/usr/lib/sparcv9
> build/temp.solaris-2.10-sun4u-2.5/net/tb0/home/loewis/25/Modules/_struct.o
> -R/usr/sfw/lib -lgcc_s_sparcv9 -R/usr/sfw/lib -lgcc_s_sparcv9
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtend.o
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtn.o
>
> As you can see, it's picking up -lgcc_s_sparcv9 (from
> /usr/sfw/lib/sparcv9/libgcc_s_sparcv9.so), so it does link with the
> 64-bit libgcc_s.so.1. However, when then trying to import the module, it
> complains 
>
> ImportError: ld.so.1: python: fatal: /usr/sfw/lib/libgcc_s.so.1: wrong
> ELF class: ELFCLASS32
>
> This is due to the option -R/usr/sfw/lib, which should have been
> -R/usr/sfw/lib/sparcv9. Fixing the specs file to change the -R option
> actually fixes that problem.
>
> So please don't claim that I did something wrong when there is really a
> bug in sfw version of gcc.
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> 
> ___
>
>
>

Added file: http://bugs.python.org/file10526/unnamed
Added file: http://bugs.python.org/file10527/DigiLink_esig_logo.jpg

___
Python tracker <[EMAIL PROTECTED]>

___


  



I rest my case - you found one of the problems
which you are blaming on gcc but in fact is not gcc's fault. You 
must
specify the correct -L and -R paths to the various alternate 64 bit
libs. Don't expect the compiler to figure it out. Of course you can
also fix the problem by changing the defaults to the system link/loader
and I'm sure other non-standard methods.

The bottom line is that I just don't know how to describe daylight to a
blind man

FYI, we are using gcc 4.1.1 - same problem and we aren't using or
relying on just the /usr/sfw tree sine much of what comes with Solaris
isn't 64 bit we have had to build our own libs which are kept in
/opt/lib

---
Bob

Martin v. Löwis wrote:

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

Just to demonstrate there is really a problem with the gcc installation
(gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)), here is the
linker line:

gcc -m64 -shared
build/temp.solaris-2.10-sun4u-2.5/net/tb0/home/loewis/25/Modules/_struct.o
-L/usr/local/lib -o build/lib.solaris-2.10-sun4u-2.5/_struct.so

and here is what gcc actually invokes (printed with -v):

/usr/sfw/libexec/gcc/sparc-sun-solaris2.10/3.4.3/collect2 -V -G -dy -z
text -Y P,/usr/lib/sparcv9 -Qy -o
build/lib.solaris-2.10-sun4u-2.5/_struct.so
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crti.o
/usr/ccs/lib/sparcv9/values-Xa.o
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtbegin.o
-L/usr/local/lib -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9
-L/usr/ccs/lib/sparcv9
-L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../sparcv9
-L/lib/sparcv9 -L/usr/lib/sparcv9
build/temp.solaris-2.10-sun4u-2.5/net/tb0/home/loewis/25/Modules/_struct.o
-R/usr/sfw/lib -lgcc_s_sparcv9 -R/usr/sfw/lib -lgcc_s_sparcv9
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtend.o
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtn.o

As you can see, it's picking up -lgcc_s_s

=?utf-8?q?[issue2799]_Remove_PyUnicode=5FAsString(), =09rework_PyUnicode=5FAsStringAndSize(), _add_PyUnicode=5FAsChar()?=

[Marc-Andre Lemburg]

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

On 2008-06-05 21:14, Alexandre Vassalotti wrote:
> Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment:
> 
> I now think the proposed changes wouldn't be bad thing, after all. I
> have been bitten myself by the confusing naming of the Unicode API. So,
> there is definitely a potential for errors. 
> 
> The main problem with PyUnicode_AsString(), as Marc-André pointed out,
> is it doesn't follow the API signature of the rest of the Unicode API:
> 
> char *PyUnicode_AsString(PyObject *unicode);
> PyObject *PyUnicode_AsUTF8String(PyObject *unicode);
> PyObject *PyUnicode_AsASCIIString(PyObject *unicode);
> 
> On the other hand, I do like the simple API of PyUnicode_AsString. Also,
> I have to admit that the apparent similarity between the PyString and
> the PyUnicode API helped me to port my code to Py3K when I first started
> working on Python core. So, pragmatism might beat purity here.

There are a few cases in the interpreter where it is indeed useful
to have direct access to the buffer with the default encoded (= UTF-8
in Py3k) char* buffer.

However, the naming of the API is poorly chosen, since the other
PyUnicode_AsXYZ() APIs either return a PyObject* or copy the
data to an output variable.

How about PyUnicode_GetUTF8Buffer() or just PyUnicode_UTF8() ?!

Note that the function *must* check the UTF-8 buffer for embedded
NUL bytes and then raise an exception if it finds one. Otherwise,
the API would silently cause truncations.

--
title: Remove PyUnicode_AsString(), rework PyUnicode_AsStringAndSize(), add 
PyUnicode_AsChar() -> Remove PyUnicode_AsString(),  rework 
PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()

___
Python 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()

[Martin v. Löwis]

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

> How about PyUnicode_GetUTF8Buffer() or just PyUnicode_UTF8() ?!

-1

> Note that the function *must* check the UTF-8 buffer for embedded
> NUL bytes and then raise an exception if it finds one. Otherwise,
> the API would silently cause truncations.

PyString_AsString doesn't check for null bytes, either, and will also
silently truncate. This has never been a problem, so I fail to see why
it is a problem for Unicode strings.

--
title: Remove PyUnicode_AsString(), rework PyUnicode_AsStringAndSize(), add 
PyUnicode_AsChar() -> Remove PyUnicode_AsString(), rework 
PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3043] Recursion bug in deepcopy

[Tyler Laing]

New submission from Tyler Laing <[EMAIL PROTECTED]>:

With the following code:
class Vertex:
def __init__(self, type):
self.type = type
self.color=-1
self.edges=[]


class Edge:
def __init__(self, V1, V2):
self.vertexes=[V1, V2]
V1.edges.append(self)
V2.edges.append(self)

Where the references are cyclic(this is for a research project into
graph algorithms), and using deepcopy, even on a tiny graph of five
vertexes and 25 edges causes deepcopy to run into the recursion limit.
At the very least, it should warn it can't copy the indicated object, as
the references are cyclic. At the very most, it should be able to handle
complex cyclic references like this properly.

--
components: Library (Lib)
messages: 67728
nosy: Zeroth
severity: normal
status: open
title: Recursion bug in deepcopy
type: behavior
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

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

[Marc-Andre Lemburg]

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

On 2008-06-05 22:50, Martin v. Löwis wrote:
>> Note that the function *must* check the UTF-8 buffer for embedded
>> NUL bytes and then raise an exception if it finds one. Otherwise,
>> the API would silently cause truncations.
> 
> PyString_AsString doesn't check for null bytes, either, and will also
> silently truncate. This has never been a problem, so I fail to see why
> it is a problem for Unicode strings.

Just because a bug hasn't surfaced yet, doesn't make it a non-issue.

The problem is also somewhat different for Unicode:

Unlike PyString_AsString() a Unicode API PyUnicode_UTF8() would not
provide easy access to the length of the returned char*.

And there is no PyString_GET_SIZE() you could use to quickly verify that
there are no embedded NULs.

Which is why using PyUnicode_AsStringAndSize() is the overall better
and safer solution.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3043] Recursion bug in deepcopy

[Tyler Laing]

Tyler Laing <[EMAIL PROTECTED]> added the comment:

Whoops, sorry, correction, when there are 100 vertexes and 500 edges.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3043] Recursion bug in deepcopy

[Guilherme Polo]

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

This should have been fixed at 2.2, as long as you change your classes
to new-style classes. If it still happens, post a sample code using your
new code that uses new-style classes.

--
nosy: +gpolo

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3043] Recursion bug in deepcopy

[Tyler Laing]

Tyler Laing <[EMAIL PROTECTED]> added the comment:

Same problem, even with new-style classes. Here, I'll show the function
I use to generate the graph as well.

class Vertex(object):
def __init__(self, type):
self.type = type
self.color=-1
self.edges=[]



class Edge(object):
def __init__(self, V1, V2):
self.vertexes=[V1, V2]
V1.edges.append(self)
V2.edges.append(self)

def generate(graph={'V':[], 'E':[]}, seed=777, vertexes=5, edges=25):
#generates a graph similar to the KEGG pathway database format.
# Purpose is for testing algorithms on a smaller scale "predicatible" 
graph
# For that reason, the "random" selections are seeded with a known
number. This is to be able
# to measure efficacy, in that on the same graph, if algorithm A
performs in half the time, its 
# not a characteristic of the graph, but the algorithm.
r=random.Random(seed)
p=[0, 0, 0, 0]
c=0
#generate vertices, with a regularly incremented set of numbers, to
appear like the KEGG pathway database does.
while c!=vertexes:
#This is ugly, could be done easier in a loop. Fix later.
p[3]+=1
if p[3]>9:
p[3]=0
p[2]+=1
if p[2]>9:
p[2]=0
p[1]+=1
if p[1]>9:
p[1]=0
p[0]+=1
#we copy the set of numbers, due to the way python passes lists 
by
reference, instead of by copy.
v=Vertex(p[:])
graph['V'].append(v)
c+=1


v=graph['V']
if len(v)!=vertexes:
print "Not enough vertices, aborting."
return graph
c=0
#randomly choose two vertices. Could even, randomly, be the same vertex.
# Then, connect an edge between them. Just creating the edge by
implication,
# with the vertices passed, connects them all together.
while c!=edges:
v1=r.choice(v)
v2=r.choice(v)
graph['E'].append(Edge(v1, v2))
c+=1

if len(graph['E']) !=edges:
print "Not enough edges, aborting."
return graph

And here is how I use it:

>>>import graph, copy
>>>g=graph.generate(vertexes=100, edges=500)
>>>g2=copy.deepcopy(g)

Thanks for the prompt response, this isn't critical in nature, just
playing around with the graph, and wanted to alter a copy of it. Ran
into this bug, thought I should report it. :)

-Zeroth

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3004] Bug in slice.indices()

[Arnaud Bergeron]

Arnaud Bergeron <[EMAIL PROTECTED]> added the comment:

It's for code that I am developping.  I developped a class to allow
full slicing over iterators (like what islice does, but with negative
indexes).  When I have a positive step I just foward the call to
isclice using slice.indices() to compute my limits.  But with this
behavior, I am forced to wrap the indices() call with a function that
patches this case.

I agree that for the common usage of computing the limits of a for
loop it doesn't matter.  But it is really surprising when you realise
this behavior is what is causing these exceptions after having passed
half a day trying to debug your code.

In fact, I think this bug should really be more of a documentation bug
and I should propose a patch to add clearer documentation to this
method.  But the fix proposed should also go in because:
- it's trivial
- it's better

Documentation for the method will be submitted later tomorrow.  Should
I post another report or just attach it to this one?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3044] Simplify the Integral ABC

[Raymond Hettinger]

New submission from Raymond Hettinger <[EMAIL PROTECTED]>:

See attached patches.

The PEP is also updated for Exact/Inexact which were removed a good
while ago.

--
assignee: gvanrossum
components: Library (Lib)
files: numbers.diff
keywords: patch
messages: 67734
nosy: gvanrossum, rhettinger
severity: normal
status: open
title: Simplify the Integral ABC
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10528/numbers.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3044] Simplify the Integral ABC

[Raymond Hettinger]

Changes by Raymond Hettinger <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file10529/pep.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3044] Simplify the Integral ABC

[Guido van Rossum]

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

Looks like you accidentally removed 2-arg __pow__ from the Complex ABC.
 This should stay of course.

Also, please add the binary operators back in a new ABC called Binary
deriving from Integral.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2582] Unpickling of range objects fail in Py3k

[Alexandre Vassalotti]

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

Weird. I wonder why it succeeds to pickle to range object at all. It
seems the __reduce_ex__ method emits bogus value.

  >>> r.__reduce_ex__(2)
  (, (,), None, None,
None)

Anyway, that is easy to fix when you know the trick. So, here is the fix.

--
assignee:  -> alexandre.vassalotti
keywords: +patch
nosy: +alexandre.vassalotti
Added file: http://bugs.python.org/file10530/fix_range_pickling.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2582] Unpickling of range objects fail in Py3k

[Alexandre Vassalotti]

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

Oh, here is a slightly more efficient version.

Added file: http://bugs.python.org/file10531/fix_range_pickling-2.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3044] Simplify the Integral ABC

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

Apologies.  Didn't know you wanted to go that direction.  Will leave
this for someone who wants to expand numbers.py rather than simplifying it.

--
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

[issue2582] Unpickling of range objects fail in Py3k

[Alexandre Vassalotti]

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

xrange() in Python 2.x is also affected by this bug. So, here is the fix.

--
versions: +Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10532/fix_xrange_pickling.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3044] Simplify the Integral ABC

[Guido van Rossum]

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

Excuse me? Have you actually been following the thread?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3008] Let bin() show floats

[Alexandre Vassalotti]

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

Kind of a cool hack. I am not sure how useful it is though. Personally,
I find ``struct.pack('d', f)`` slightly more educative (more useful
too), but that is just me. 

And if you allow bin() to accept floats, will you make Python accept
binary float literals too?

--
nosy: +alexandre.vassalotti

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3042] Add PEP 8 compliant aliases to threading module

[Nick Coghlan]

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

The code changes in the patch look pretty good to me (although you
probably want to actually use @wraps inside _old_api!)

There are obviously also documentation and test suite changes that will
be needed.

___
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:

Ah, that would answer my #XXX comment regarding that in the patch.
Agreed, the best answer will be to factor out the _rewrap operation into
a new class method. (Next week though...)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3042] Add PEP 8 compliant aliases to threading module

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

On Thu, Jun 5, 2008 at 8:56 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Nick Coghlan <[EMAIL PROTECTED]> added the comment:
>
> The code changes in the patch look pretty good to me (although you
> probably want to actually use @wraps inside _old_api!)

That won't work because we are creating the method than we would pass
to wraps. Changing old's __name__ to old_name should do the trick.
>
> There are obviously also documentation and test suite changes that will
> be needed.

Of course. I can do that.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3042] Add PEP 8 compliant aliases to threading module

[Adam Olsen]

Changes by Adam Olsen <[EMAIL PROTECTED]>:


--
nosy: +Rhamphoryncus

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3045] Windows online help broken when spaces in TEMP environ

[Peter Whaite]

New submission from Peter Whaite <[EMAIL PROTECTED]>:

If the environ vars TEMP or TMP contain spaces on w32 the on-line help
will not work.  e.g. help('or') gives the message

The system cannot find the file specified.

This is because pydoc.tempfilepager sets filename=tempfile.mktemp()
which will have spaces in it if TEMP does.  The filename is then used to
constuct the system command:

 os.system(cmd + ' ' + filename)

which in windows ends up as  os.system('more < FILE WITH SPACES').  The
filename should be quoted, e.g.

 os.system('%s "%s"' % (cmd,filename))

I only ran across this problem because I use uwin on windows and it sets
TEMP to a w32 style long path.  The normal windows command shell uses
the dos spaceless sort form for the TMP and TEMP env vars so the problem
doesn't arise when python is invoked from there.

And isn't tempfile.mktemp() deprecated?

--
components: Library (Lib), Windows
messages: 67746
nosy: peta
severity: normal
status: open
title: Windows online help broken when spaces in TEMP environ
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

[issue3046] Locking should be removed from the new buffer protocol

[Stefan Behnel]

New submission from Stefan Behnel <[EMAIL PROTECTED]>:

Here is a patch against the current PEP 3118 that removes the LOCK flag.
It follows this discussion on the Py3k mailing list:

http://comments.gmane.org/gmane.comp.python.python-3000.devel/13409?set_lines=10

It has not yet been approved by the PEP owners and requires
implementation, preferably before beta1.

--
components: Interpreter Core
files: pep-3118-no-locking.patch
keywords: patch
messages: 67747
nosy: scoder
severity: normal
status: open
title: Locking should be removed from the new buffer protocol
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10533/pep-3118-no-locking.patch

___
Python tracker <[EMAIL PROTECTED]>

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