[issue4769] b64decode should accept strings or bytes

[James Brotchie]

Changes by James Brotchie :


--
nosy: +brotchie

___
Python tracker 

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

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

[James Brotchie]

Changes by James Brotchie :


--
nosy: +brotchie

___
Python tracker 

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

[issue2995] Idle, some Linuxes, cannot position Cursor by mouseclick

[Matthias Sommer]

Matthias Sommer  added the comment:

Retry is a bit difficult now, sinc I reverted back to Windows after 
getting quite some answers in some places, but none of them really 
helpful.

It happend under Madriva Linux (and some other tested Linuxes). Now I'm 
using Gentoo (this is, IF I'm using Linux). And there it works all fine.

The problem was: Usually one can set the cursorposition in any given 
(gui) text editor by mouse click in the text. Using Madriva, I can 
click, but the cursor is not affected.

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Armin Rigo]

Changes by Armin Rigo :


--
nosy:  -arigo

___
Python tracker 

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

[issue4800] little inaccuracy in Py_ssize_t explanation

[Kandalintsev Alexandre]

New submission from Kandalintsev Alexandre :

Documentation says that


There’s no chance that the reference count can overflow; at least as many bits 
are used to hold the reference count as there are distinct memory locations in 
virtual memory (assuming sizeof(Py_ssize_t) >= sizeof(void*)). Thus, the 
reference count increment is a simple operation.


But Py_ssize_t is a signed type so in case of sizeof(Py_ssize_t) == sizeof
(void*)) it can only reference a half of memmory :). But because any python 
object consumes much more than 2bytes this is not a problem.

--
assignee: georg.brandl
components: Documentation
messages: 78695
nosy: exe, georg.brandl
severity: normal
status: open
title: little inaccuracy in Py_ssize_t explanation
versions: Python 3.0, Python 3.1

___
Python tracker 

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

[issue4100] xml.etree.ElementTree does not read xml-text over page bonderies

[Georg Brandl]

Georg Brandl  added the comment:

Thanks, applied in r68116.

--
assignee: effbot -> georg.brandl
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue4136] merge json library with simplejson 2.0.4

[Georg Brandl]

Georg Brandl  added the comment:

Bumping priority a bit.

--
nosy: +georg.brandl
priority:  -> critical

___
Python tracker 

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

[issue4156] Docs for BaseHandler.protocol_xxx methods are unclear

[Georg Brandl]

Georg Brandl  added the comment:

Fixed in r68117.

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

___
Python tracker 

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

[issue4185] re module treats raw strings as normal strings

[Georg Brandl]

Georg Brandl  added the comment:

Added a bit to the re.sub(n) docstrings in r68118.

--
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue4222] dis.findlinestarts is missing from dis.__all__ and from the online documentation

[Georg Brandl]

Georg Brandl  added the comment:

Documented dis.findlinestarts() and put it into dis.__all__ in r68119.

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

___
Python tracker 

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

[issue4228] struct.pack('L', -1)

[Georg Brandl]

Georg Brandl  added the comment:

Committed to trunk in r68120.

--
nosy: +georg.brandl
status: open -> closed

___
Python tracker 

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

[issue3959] Add Google's ipaddr.py to the stdlib

[David Moss]

David Moss  added the comment:

ipaddr appears to be on a fast track for "batteries included" status
without much consultation in the wider Python community. As BDFL it's
ultimately Guido's call, but it would be disappointing to see one
solution being chosen wholesale without much additional discussion.

There is no point in wrangling over the individual features of one
library at revision x versus another at revision y. Software is a moving
target. Omissions and bugs are easily dispatched. Ultimately we all want
the same thing, better software that makes our lives easier.

As for netaddr it is intended to cover more ground that all the other
solutions out there. Here is a handy list of them :-

http://code.google.com/p/netaddr/wiki/YetAnotherPythonIPModule

This may preclude its suitability for the standard library in any event
being intended to support any and all network address types, not just
IPv4 and IPv6. It is also currently, very much in beta, being about 75%
feature complete with 6-9 months work of (part-time) work left on it
before it can reach version 1.0 ready. A Python 3.0 version is also
planned for release soon.

In answer to various specific issues raised about netaddr.

The need for separate IP and CIDR classes is set out in the FAQ page :-

http://code.google.com/p/netaddr/wiki/NetAddrFAQ

FYI, AddrRange is a (not yet abstract) base class with a start and end
address covering the shared functionality of 3 subclasses (IPRange,
CIDR, Wildcard) which should all interchangeable (within reason). It is
also supports generic address (Addr objects) rather than just IP
specific ones. Base 2 slices is not always the best way of expressing
groups of network hosts, they are *one* way.

With netaddr, I wanted to avoid the 'super object' syndrome that seems
to dog virtuall all other existing efforts out there, and not only those
in Python.

In any event confusion will hopefully be dealt with as the docs improve.

As for performance, netaddr's current speed for certain operations areas
may be slower than other implementations but the optimisation phase of
development hasn't even begun. There are loads more features to add and
get working before that starts.

One point I will make is on licensing. netaddr is BSD, so you can do
whatever you want with it and contribute as you see fit.

At the present time, contributing to ipaddr for anyone outside Google
seems like the software equivalent of climbing Mount Everest! Even if I
personally wanted to contribute to this particular project's efforts,
having to sign the individual CLA would automatically preclude me from
doing so. This is a *major* sticking point.

Regardless of whatever decision is taken, netaddr will always be
available as long as it has a user base, either as built in, optional
extra or as a part of some wider standardisation effort.

___
Python tracker 

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

[issue4742] 3.0 distutils byte-compiling -> Syntax error: unknown encoding: cp1252

[Georg Brandl]

Changes by Georg Brandl :


--
status: open -> closed

___
Python tracker 

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

[issue4772] undesired switch fall-through in socketmodule.c

[Georg Brandl]

Georg Brandl  added the comment:

TypeError or ValueError?

--
nosy: +georg.brandl

___
Python tracker 

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

[issue4798] Update deprecation of 'new' module in PEP 4.

[Georg Brandl]

Georg Brandl  added the comment:

Applied the doc patch in r68121.  Updated PEP 4 to point to PEP 3108
(which contains a list of all modules removed in 3k and deprecated in
2.6, not just "new") in r68122.

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

___
Python tracker 

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

[issue4784] Mismatch in documentation for module "webbrowser"

[Georg Brandl]

Georg Brandl  added the comment:

Fixed in r68123.

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

___
Python tracker 

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

[issue4782] json documentation missing load(), loads()

[Georg Brandl]

Georg Brandl  added the comment:

Fixed in r68124.

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

___
Python tracker 

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

[issue4776] distutils documentation

[Georg Brandl]

Georg Brandl  added the comment:

Thanks, documented in r68125.

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

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Hi,

> Why don't you use the C preprocessor instead of that Python code?
> Sample code:

We would have to change opcode.h for this to be truely useful (in order
to re-use OPCODE_LIST()). I think that should be the subject of a
separate bug entry for code reorganization.

Thanks for all the explanation and pointers! About register allocation,
I wonder if the "temporary variables" u,v,w could be declared separately
in each opcode rather than at the top of the eval function, so that the
compiler doesn't try to store their values between two opcodes.

As for the "register" declarations, I think they're just remains of the
past.

Antoine.

___
Python tracker 

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

[issue4767] email.mime incorrectly documented (or implemented)

[Georg Brandl]

Georg Brandl  added the comment:

Thanks, fixed in r68127.

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

___
Python tracker 

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

[issue4789] Documentation changes break existing URIs

[Georg Brandl]

Georg Brandl  added the comment:

I've added the redirects. I hope that mailman updates its links in the
next release though :)

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

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Skip Montanaro]

Skip Montanaro  added the comment:

Skip> You could backport it to 2.4 & 2.5 and just put it up on PyPI...

Paolo> I was thinking to a private backport as well.  I didn't know
Paolo> about PyPI, it looks like PyPI is more for contributed modules
Paolo> than for this, would that work?

I don't see why it wouldn't.

Skip

___
Python tracker 

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

[issue4797] test_fileio error (windows)

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Please go ahead.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue3680] Cycles with some iterator are leaking.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Committed to trunk and py3k, thanks!

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

___
Python tracker 

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

[issue4797] test_fileio error (windows)

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

Done. Fixed in r68134(trunk) and r68139(py3k).

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

___
Python tracker 

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

[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail

[Roumen Petrov]

Roumen Petrov  added the comment:

I would like to confirm issue for trunk.

--
nosy: +rpetrov
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1

___
Python tracker 

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

[issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support

[Derek Morr]

Derek Morr  added the comment:

Senthil,

I don't think your gethost_addrinfo() function will work. On a v6-
enabled machine, it will only return v6 or v4 names. Shouldn't it 
return both (since a machine could have both v4 and v6 addresses)? For 
example, on my machine, I have the following addresses for 
"localhost": ::1, fe80::1%lo0, 127.0.0.1.

Also, why is the AI_CANONNAME flag set? The canonname field isn't used. 
And you only appear to take the last IP address returned (sa[0]). 
Shouldn't you return all the addresses?

--
nosy: +dmorr

___
Python tracker 

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

[issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support

[Derek Morr]

Derek Morr  added the comment:

Question: Why does FTPHandler.ftp_open() try to resolve the hostname()? 
The hostname will be passed into connect_ftp(), then into 
urllib.ftpwrapper(), and eventually into ftplib.FTP.connect(), which is 
IPv6-aware.

___
Python tracker 

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

[issue4035] Support bytes for os.exec*()

[STINNER Victor]

STINNER Victor  added the comment:

> Hmm, I think the supported types should be the same for all
> platforms, otherwise it creates unnecessary headaches.

I'm don't know Windows very well, but I read many times that Windows 
uses unicode everywhere. I'm unable to decide if it's a good thing or 
not to support also bytes on Windows, and anyway I'm unable to write 
such patch.

See also issue #4036 (bytes for subprocess.Popen), especially Martin's 
message msg74305 (Martin is our Windows expert ;-)).

___
Python tracker 

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

[issue4751] Patch for better thread support in hashlib

[STINNER Victor]

Changes by STINNER Victor :


___
Python tracker 

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

[issue4751] Patch for better thread support in hashlib

[STINNER Victor]

STINNER Victor  added the comment:

Ooooh, I suggested to ebfe to remove the GIL unlock/lock, but I was 
wrong :-( I hate locks! What is the right fix? Replace
   ENTER_HASHLIB(self)
   Py_BEGIN_ALLOW_THREADS
   ...
   Py_END_ALLOW_THREADS
   LEAVE_HASHLIB(self)
by
   Py_BEGIN_ALLOW_THREADS
   ENTER_HASHLIB(self)
   ...
   LEAVE_HASHLIB(self)
   Py_END_ALLOW_THREADS
?

___
Python tracker 

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

[issue4791] retrlines('LIST') and dir hang at end of listing in ftplib (python3.0)

[STINNER Victor]

STINNER Victor  added the comment:

I'm unable to reproduce the issue. I tried to create files on my FTP 
server with non-ASCII characters or spaces in the filenames, but 
everything is fine. Can you reproduce the problem outside IDLE? Or is 
the issue specific to IDLE? I mean: write a script and execute "python 
script.py" in a terminal.

___
Python tracker 

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

[issue4780] Makefile.pre.in patch to run regen on OSX (framework build)

[Roumen Petrov]

Roumen Petrov  added the comment:

The issue is same for trunk.
Step to reproduce(as example on linux):
- remove existing python installation (optional)
- rename Lib/plat-linux2
...
python$EXE ../../Tools/scripts/h2py.py -i '(u_long)'
/usr/include/netinet/in.h
python: error while loading shared libraries: libpython2.7.so.1.0:
cannot open shared object file: No such file or directory

--
nosy: +rpetrov
versions: +Python 2.6, Python 2.7, Python 3.0

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Paolo 'Blaisorblade' Giarrusso]

Paolo 'Blaisorblade' Giarrusso  added the comment:

> We would have to change opcode.h for this to be truely useful (in
order to re-use OPCODE_LIST()).

Yep.

> I think that should be the subject of a separate bug entry for code
reorganization.

Agreed, I'll maybe try to find time for it.

> Thanks for all the explanation and pointers!
You're welcome, thanks to you for writing the patch! And 
> About register allocation, I wonder if the "temporary variables" u,v,w
could be declared separately in each opcode rather than at the top of
the eval function, so that the compiler doesn't try to store their
values between two opcodes.

I didn't look at the output, but that shouldn't be needed with decent
optimizers, since they are local variables, so the compiler has a full
picture of their usage (this does not happen with the content of the
heap, where the frame object may lie).

I think that change would just save some compilation time for dataflow
analysis, maybe :-). Or could make clearer which variables is used
where, but that is a matter of taste (what's there is fine for me).

I just studied liveness analysis in compilers, and it computes whether a
variable is live before and after each statement; if the value of a
variable is not used in some piece of code until the next write to the
variable, it is considered dead in that piece of code, and that variable
does not take space; since u, v, w are either unused or are written to
before usage in all opcodes, they're dead at the beginning of each
opcode, so they're also dead just before dispatch.


The only important thing is that the content of the jump table are known
to the compiler and that the compiler makes use of that. Simply passing
a non-const jump table to some function defined elsewhere (which could
in theory modify it) would make the output much worse.

___
Python tracker 

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

[issue4801] _collections module fail to build on cygwin

[Roumen Petrov]

New submission from Roumen Petrov :

make log:
gcc -shared -Wl,--enable-auto-image-base
.../Modules/_collectionsmodule.o -L/usr/local/lib -L. -lpython2.7 -o
build/lib.cygwin-1.5.25-i686-2.7/_collections.dll
.../Modules/_collectionsmodule.o: In function `deque_iter':
.../Modules/_collectionsmodule.c:970: undefined reference to
`__PyGC_generation0'


--
components: Build
files: py-trunk-incl-objimpl.h-patch
messages: 78723
nosy: rpetrov
severity: normal
status: open
title: _collections module fail to build on cygwin
versions: Python 2.7
Added file: http://bugs.python.org/file12519/py-trunk-incl-objimpl.h-patch

___
Python tracker 

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

[issue4802] detect_tkinter for cygwin

[Roumen Petrov]

New submission from Roumen Petrov :

Check for installed X on cygwin can't find X11/Xlib.h in detect_tkinter
from setup.py

--
files: py-trunk-detect_tkinter-cygwin.patch
keywords: patch
messages: 78724
nosy: rpetrov
severity: normal
status: open
title: detect_tkinter for cygwin
Added file: 
http://bugs.python.org/file12520/py-trunk-detect_tkinter-cygwin.patch

___
Python tracker 

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

[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail

[Roumen Petrov]

Roumen Petrov  added the comment:

I'm not sure that installation work if slash is removed and DESTDIR is
not specified. What about to replace "slash before $(DESTDIR)" with "/./" ?

___
Python tracker 

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

[issue4791] retrlines('LIST') and dir hang at end of listing in ftplib (python3.0)

[Daniel Diniz]

Daniel Diniz  added the comment:

Hi Chris

Since dir calls retrlines and retrlines has a 'while 1:' loop, the bug
probably comes from there. Either it hangs in the fp.readline call or
the break condition is never met.

Can you put some print diagnostics inside Lib/ftplib.py->FTP.retrlines
(around line 405) to help pinpointing the issue?

HTH,
Daniel

--
nosy: +ajaksu2

___
Python tracker 

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

[issue4791] retrlines('LIST') and dir hang at end of listing in ftplib (python3.0)

[STINNER Victor]

STINNER Victor  added the comment:

> Can you put some print diagnostics inside Lib/ftplib.py (...)

.set_debuglevel(2) already prints a lot of 
informations.

___
Python tracker 

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

[issue4772] undesired switch fall-through in socketmodule.c

[STINNER Victor]

STINNER Victor  added the comment:

makesockaddr() raise a TypeError("Invalid address type") for an 
invalid AF_TIPC address, but I would prefer a ValueError.

--
nosy: +haypo

___
Python tracker 

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

[issue4775] Incorrect documentation - UTC time

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

FWIW: POSIX defines Unix time_t *not* to include leap seconds.

You can easily check whether your platform or C lib behaves
POSIX-ly correct or not:

   POSIX: 1986-12-31 23:59:59 UTC == 536457599 ticks

   With leap seconds: == 536457612 ticks

   (since there were 13 leap seconds in the years 1972-1985)

For most practical purposes the difference doesn't really matter,
since date differences are usually counted in days, not seconds.

In cases where it does matter, you're better off with a custom
solution, since applications or other libraries tend not to handle
leap seconds well.

--
nosy: +lemburg

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Alexandre Vassalotti]

Alexandre Vassalotti  added the comment:

Antoine Pitrou wrote:
> [...] count the number of indirect jump instructions in ceval.c:
> 
> grep -E "jmp[[:space:]]\*%" ceval.s
>
> There should be 85 to 90 of them, roughly. If there are many less, then
> the compiler has tried to optimize them by "sharing" them.

I get 86 with GCC 4.x and SUNCC. However, with GCC 3.4 I only get a
single computed goto. Is there some hidden option to make GCC avoid
sharing jumps? 

> Because otherwise the measurements these options are meant to do would
> be meaningless.

Ah, I see now. Maybe you should add a quick comment that mentions this. 

> I don't have a Sun machine to test, so I'll leave to someone else to
> check and enable if they want to.

I tested it and it worked, no test failures to report. Just change the
macro test: 

#ifdef __GNUC__ && \
...

to

#ifdef (__GNUC__ || __SUNPRO_C) && \
...


I attached some additional benchmarks on SunOS. So far, it seems the
benefits of the proposed optimization are highly compiler-dependent.

Added file: http://bugs.python.org/file12521/amd-athlon64-x2-suncc-pybench.txt

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Alexandre Vassalotti]

Changes by Alexandre Vassalotti :


Added file: 
http://bugs.python.org/file12522/amd-athlon64-x2-gcc-sunos-pybench.txt

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Alexandre Vassalotti]

Alexandre Vassalotti  added the comment:

> Attached new patch for fixes suggested by Alexandre (rename
> opcode_targets.c to opcode_targets.h, replace USE_THREADED_CODE with
> USE_COMPUTED_GOTOS).

You forgot to update your script to use the new name.

___
Python tracker 

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

[issue4566] 2.6.1 breaks many applications that embed Python on Windows

[Craig Holmquist]

Craig Holmquist  added the comment:

Here's an option, though unfortunately not a trivial one:  use a private
build of the C runtime.  The Windows version of Firefox does this
(mozcrt19.dll).  The private CRT build doesn't use SxS in any way, so it
gets around this issue, as well as other issues like not allowing "for
me" installs on Vista (#4018).

For me to build the CRT from the source included with Visual Studio 2008
took some tweaking - apparently having the CRT source build properly out
of the box wasn't a priority for MS (the Mozilla CRT seems to be built
from the VS2005 source; perhaps that version is more cooperative).  It
does yield a CRT that links like an ordinary DLL, but the fact that it
can't be built without modifications is a major drawback to this solution.

Also, I'd assume that the CRT source isn't included in the Express
version (and possibly other ones), so that's a downside, too.

As far as Python itself, the project configurations would have to be
changed to define _CRT_NOFORCE_MANIFEST, suppress the default linking to
the stock CRT (/NODEFAULTLIB:msvcrt.lib), and link to the import library
for the private CRT.  I might try to create an experimental solution
config for this.

___
Python tracker 

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

[issue4472] Is shared lib building broken on trunk for Mac OS X?

[Roumen Petrov]

Roumen Petrov  added the comment:

I just finish test for altbininstall make target on linux and cygwin.

Ronald,
About the SO issue - in makefile we may use $(LDLIBRARY) instead of
libpython$(VERSION)$(SO) (see py-issue-4472-makefile.patch).
For cygwin libpython$(VERSION)$(SO) is equal to $(DLLLIBRARY) and
DLLLIBRARY is set only on cygwin.

Added file: http://bugs.python.org/file12523/py-issue-4472-makefile.patch

___
Python tracker 

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

[issue4751] Patch for better thread support in hashlib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The right fix would probably be to define ENTER_HASHLIB(self) as
Py_BEGIN_ALLOW_THREADS
PyThread_acquire_lock(self->lock)
Py_END_ALLOW_THREADS

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I get 86 with GCC 4.x and SUNCC. However, with GCC 3.4 I only get a
> single computed goto. Is there some hidden option to make GCC avoid
> sharing jumps? 

Try -fno-crossjumping.

> I tested it and it worked, no test failures to report. Just change the
> macro test: 
> 
> #ifdef __GNUC__ && \
> ...
> 
> to
> 
> #ifdef (__GNUC__ || __SUNPRO_C) && \
> ...

Thanks.

> You forgot to update your script to use the new name.

Ah, that's rather dumb :)

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I've updated the comments as per Alexandre's request, added support for
SUN CC, and fixed the generation script to use the new filename.

Added file: http://bugs.python.org/file12524/threadedceval5.patch

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Antoine Pitrou]

Changes by Antoine Pitrou :


Removed file: http://bugs.python.org/file12514/threadedceval4.patch

___
Python tracker 

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

[issue4747] SyntaxError executing a script containing non-ASCII characters in its name or path

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Fixed in r68143 (py3k) and r68144 (3.0).
Thanks for the report!

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

___
Python tracker 

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

[issue4718] wsgiref package totally broken

[Graham Dumpleton]

Graham Dumpleton  added the comment:

One interesting thing of note that has occurred to me looking at the patch 
is that although with Python <3.0 you technically could return a str as 
iterable from application, ie., because iteration over str returns str for 
each character, the same doesn't really apply to bytes in Python 3.0. This 
is because iterating over bytes yields an int fdor each item.

Thus have odd situation where with Python 3.0, one could technically return 
str as iterable, with rule that would apply would be that each str returned 
would then be converted to bytes by way of latin-1 conversion, but for 
bytes returned as iterable, should fail.

Not sure how this plays out in wsgiref server yet as haven't looked. 
Anyway, make the validator code:

@@ -426,6 +436,6 @@
 # Technically a string is legal, which is why it's a really bad
 # idea, because it may cause the response to be returned
 # character-by-character
-assert_(not isinstance(iterator, str),
+assert_(not isinstance(iterator, (str, bytes)),
 "You should not return a string as your application iterator, "
 "instead return a single-item list containing that string.")

quite a good thing to have.

___
Python tracker 

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

[issue4035] Support bytes for os.exec*()

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Every function of the Windows API comes in pair: an Ansi function (which 
accepts char* names) and a Wide function (which accepts wchar_t* names; 
Py_UNICODE* can be passed as-is)

Don't perform conversion on Windows, just call the proper function.

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue3299] invalid object destruction in re.finditer()

[Nick Coghlan]

Nick Coghlan  added the comment:

It certainly looks like all direct calls to PyObject_DEL/PyObject_Del
from outside tp_dealloc implementations are going to be broken in
pydebug builds.

Replacing those calls with either Py_DECREF operations (as Victor's
patch does) or direct calls to _Py_Dealloc should get them to do the
right thing.

I'm a little wary of adding calls to _Py_ForgetReference into
PyObject_Del though, since most of the time the reference will already
have been forgotten by the time that PyObject_Del is called. My
suggestion would be:

1. Update the docs on PyObject_Del to specifically warn against using it
for error cleanup after a successful PyObject_New invocation, instead
pointing users of the C API to Py_DECREF. Basically, code that calls
PyObject_Del outside a tp_dealloc method is probably doing something
wrong. Note also that tp_dealloc implementations in such cases will need
to cope with instances that are only partially initialised (e.g. by
using Py_XDECREF instead of Py_DECREF).

2. Fix the instances in the standard library where _Py_Dealloc may be
bypassed by direct calls to PyObject_Del.

The alternative would be to change the pydebug version of PyObject_Del
to check if the reference count on the object is 1 rather than 0. That
should be a pretty good indication that we're dealing with a case of
cleaning up after a failure to fully initialise an object, and we can
call _Py_ForgetReference directly from PyObject_Del, retroactively
making all those direct invocations of PyObject_Del "correct".

Hmm, now that I write that idea down, it doesn't sound nearly as scary
as I thought it would...

--
nosy: +ncoghlan

___
Python tracker 

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

[issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for --with-pydebug

[Nick Coghlan]

Nick Coghlan  added the comment:

(changing title and unassigning from Fredrik since this isn't an RE
specific problem, flagged as also affecting interpreter core, flagged as
affecting all currently maintained versions)

--
assignee: effbot -> 
components: +Interpreter Core
title: invalid object destruction in re.finditer() -> Direct calls to 
PyObject_Del/PyObject_DEL are broken for --with-pydebug
versions: +Python 2.6, Python 3.0, Python 3.1

___
Python tracker 

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

[issue4801] _collections module fail to build on cygwin

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Committed a different correction in r68145: 
according to documention, _PyObject_GC_TRACK should not be used in 
extension modules.

Thanks for the report.

--
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for --with-pydebug

[Nick Coghlan]

Nick Coghlan  added the comment:

Ah, now that I go to implement it, I remember why I didn't like the idea
of doing anything directly in PyObject_Del. While the Python memory
allocator is primarily designed for allocation of Python objects, it
isn't actually *limited* to that. So there is no guarantee that the void
pointer passed in to PyObject_Del can be safely cast to a PyObject pointer.

The idea could still be implemented by scanning the list of active
objects to see if the passed in pointer refers to one of them, but that
would make object deallocation in pydebug builds extraordinarily slow.

___
Python tracker 

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

[issue4614] Document PyModule_Create()

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
priority:  -> critical

___
Python tracker 

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

[issue4614] Document PyModule_Create()

[Benjamin Peterson]

Changes by Benjamin Peterson :


___
Python tracker 

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

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

[STINNER Victor]

STINNER Victor  added the comment:

> I think the library function base64.b64encode() should return 
> a string, not bytes.

Yes, in the email module, the payload is an unicode string, not a 
bytes string. We have to be able to concatenate headers 
(eg. "Content-Type: image/fish\nMIME-Version: 
1.0\nContent-Transfer-Encoding: base64\n") and encoded data 
(eg. "R0lGO").

Attached patch implements this fix: encode_base64() returns str (and 
not bytes). The patchs fixes the unit tests and adds a new regression 
test for MIMEImage.as_string().

--
nosy: +haypo

___
Python tracker 

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

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

[STINNER Victor]

Changes by STINNER Victor :


--
keywords: +patch
Added file: http://bugs.python.org/file12525/email_base64_bytes.patch

___
Python tracker 

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

[issue3999] Real segmentation fault handler

[Antoine Pitrou]

Antoine Pitrou  added the comment:

As mentioned in python-dev, the patch would be more suitable for
inclusion if it was changed to simply print a stack trace and bail out,
rather than try to resume execution of the Python program.

--
nosy: +pitrou

___
Python tracker 

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

[issue4769] b64decode should accept strings or bytes

[STINNER Victor]

STINNER Victor  added the comment:

About quoted printable, there are two implementations:
 - binascii.a2b_qp() (Modules/binascii.c): C implementation, use 
PyArg_ParseTupleAndKeywords(args, kwargs, "s*|i", ...) to parse the 
data
 - quopri.decode() (Lib/quopri.py): Python implementation
   => quopri.decodestring() uses io.BytesIO() to parse the data

But quopri.decodestring() reuses binascii.a2b_qp() if the binascii 
module is present. So quopri.decodestring behaviour depends of the 
presence of binascii module...
 - binascii present: accept bytes or unicode
 - missing binascii: accept only bytes!

binascii.a2b_qp() encodes unicode string to UTF-8 bytes string.

--
nosy: +haypo

___
Python tracker 

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

[issue4769] b64decode should accept strings or bytes

[STINNER Victor]

STINNER Victor  added the comment:

> If the input to b64decode is a str, just do a encode('ascii')
> operation on it and proceed.  If that fails, it wasn't valid 
> Base64 to begin with.

On unicode encode error, should we raise an UnicodeEncodeError or a 
binascii.Error?

And there is also the problem of base64.b64decode() 
alternate "characters". Should we accept non-ASCII alternate 
characters?
   base64.b64decode('01a\xfeb\xffcd', altchars=b'\xfe\xff')

For the example, the result depends on the choosen charset:
 - ASCII (strict): encode input text raise an UnicodeDecodeError
 - ISO-8859-1 (ignore): works as expected
 - UTF-8 (strict): unexpected result

The only valid choice is ASCII because ISO-8859-1 or UTF-8 will 
reintroduce bytes/character mixture.

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Paolo 'Blaisorblade' Giarrusso]

Paolo 'Blaisorblade' Giarrusso  added the comment:

> I attached some additional benchmarks on SunOS. So far, it seems the
benefits of the proposed optimization are highly compiler-dependent.

Well, it would be more correct to say that as you verified for GCC 3.4,
"miscompilation" of the code happens easily.

Any literature research shows that threading in a fast interpreter does
help. My experience shows two exceptions to this rule:
a) bad compiler output
b) interpreters which are not efficient enough - when other operations
are even slower than instruction dispatch (which is really slow due to
costly mispredictions), threading can't help.

This is shown by the number of interpreters using threading.

Wikipedia has more pointers on this:
http://en.wikipedia.org/wiki/Threaded_code
Note that what I called "indirect threading" is called there instead
"token threading".

Another example of the importance of threading is also shown in this
article:
http://webkit.org/blog/189/announcing-squirrelfish/

Some clues about why Python does not use threading:

http://mail.python.org/pipermail/python-list/1999-May/002003.html

It is important to note that people in that mail are not aware of why
threading gives a speedup.

==
For SunCC, I can't say anything without looking at:
a) the generated code; if jump targets were aligned only for switch but
not for computed gotos, for instance, that could maybe explain such a
slowdown. Lots of other details might be relevant.
b) performance counters results, especially regarding mispredictions of
indirect branches.

___
Python tracker 

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

[issue4803] Manas Thapliyal sent you a Friend Request on Yaari

[Manas]

New submission from Manas :

Manas Thapliyal wants you to join Yaari!

Is Manas your friend?

http://yaari.com/?controller=user&action=mailregister&friend=1&sign=YaariNSF231MZA868MBK206SAQ399";>Yes,
 Manas is my friend! http://yaari.com/?controller=user&action=mailregister&friend=0&sign=YaariNSF231MZA868MBK206SAQ399";>No,
 Manas isn't my friend.

Please respond or Manas may think you said no :(

Thanks,
The Yaari Team

If you prefer not to receive this email tell us http://yaari.com/?controller=absn&action=addoptout&email=rep...@bugs.python.org";>here.
 If you have any concerns 
regarding the content of this message, please email ab...@yaari.com.  
Yaari LLC, 358 Angier Ave, Atlanta, GA 30312

YaariNSF231MZA868MBK206SAQ399

--
files: unnamed
messages: 78749
nosy: gravitywarrior1
severity: normal
status: open
title: Manas Thapliyal sent you a Friend Request on Yaari
Added file: http://bugs.python.org/file12526/unnamed

___
Python tracker 

___Manas Thapliyal wants you to join Yaari!

Is Manas your friend?

http://yaari.com/?controller=user&action=mailregister&friend=1&sign=YaariNSF231MZA868MBK206SAQ399";>Yes,
 Manas is my friend! http://yaari.com/?controller=user&action=mailregister&friend=0&sign=YaariNSF231MZA868MBK206SAQ399";>No,
 Manas isn't my friend.

Please respond or Manas may think you said no :(

Thanks,
The Yaari Team

If you prefer not to receive this email tell us http://yaari.com/?controller=absn&action=addoptout&email=rep...@bugs.python.org";>here.
 If you have any concerns 
regarding the content of this message, please email ab...@yaari.com.  
Yaari LLC, 358 Angier Ave, Atlanta, GA 30312

YaariNSF231MZA868MBK206SAQ399


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

[issue4803] Manas Thapliyal sent you a Friend Request on Yaari

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
resolution:  -> invalid
status: open -> closed

___
Python tracker 

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

[issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support

[Senthil]

Senthil  added the comment:

Derek, 

This patch was along the lines that when IPv6 address is present, return
the first address,which I assumed to be active address and would make
the urllib2 work.

I am not sure, if returning all the addresses would help and how would
we define which address to use?

AI_CANONNAME flag, I don't accurately remember it now. But I had
encountered issues when testing on IPv-4 systems without it.

I am having different opinion on this issue now.

First is, taking from Facundo's comment on having this functionality in
gethostbyname() and implementing it in C. 

Second is, the wrapper function and suitable way needs to be defined.

I am sorry, I fail to understand the question on why ftp_open does
hostname resolution. You mean to say without it, if we pass it to
ftplib.FTP.connect() it would work for IPv6 address?

___
Python tracker 

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

[issue4566] 2.6.1 breaks many applications that embed Python on Windows

[Mark Hammond]

Mark Hammond  added the comment:

I've no time to dig deeper now as I suspect testing will require removal
of the vc9 assembly from the GAC and testing with a local one, but some
comments:

test.c's error is "can't find the DLL" - this will be as we attempt to
load Python's DLL - but this isn't the same as the original error, which
is "DLL init routine failed".  To repro the initial error, I suspect you
will want to put the full assembly next to test.exe - that will allow
python.dll to load - then test.c should call PyExec_EvalString("import
socket\n") - it is at *that* point the error we care about is likely to
be thrown.

That specific error code means the DLL init routine in the CRT started
executing, but explicitly threw an error.  Its possible to use the
debugger to see exactly when this is thrown, and it relates to the
assembly configuration (the details escape me).  I suspect it will be
necessary to locate this CRT init code to determine exactly why it is
throwing the error, and possibly determine how to satisfy it (the DLL
*is* loaded, so it should be capable of working)

--
nosy: +mhammond

___
Python tracker 

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

[issue4566] 2.6.1 breaks many applications that embed Python on Windows

[Mark Hammond]

Mark Hammond  added the comment:

I meant to mention: FWIW, *some* py2exe apps work fine with the old
scheme - specifically, IIUC, any app will work fine so long as the .pyd
files were next to the executable, which is next to the assembly.  I
understand this is a significant restriction, but its worth mentioning
for completeness.

___
Python tracker 

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

[issue4804] Python on Windows disables all C runtime library assertions

[Mark Hammond]

New submission from Mark Hammond :

This block in exceptions.c:

#if defined _MSC_VER && _MSC_VER >= 1400 && defined(__STDC_SECURE_LIB__)
...
/* turn off assertions in debug mode */
prevCrtReportMode = _CrtSetReportMode(_CRT_ASSERT, 0);
#endif

Does exactly what the comment says it does - disables all assertions. 
It disables *all* CRT assertions in the process, which includes some
very useful ones related to memory corruption, and all 'assert' and
'ASSERT' statements in all Python extension modules.

The change was introduced in:
"""
r46894 | kristjan.jonsson | 2006-06-13 01:45:12 +1000 (Tue, 13 Jun 2006)
| 2 lines

Fix the CRT argument error handling for VisualStudio .NET 2005.  Install
a CRT error handler and disable the assertion for debug builds.  This
causes CRT to set errno to EINVAL.
This update fixes crash cases in the test suite where the default CRT
error handler would cause process exit.
"""

which seems like a very large hammer to be using (ie, the problem
causing the assertions to blow should probably have been fixed).  I'd
like to remove these 2 lines.  Any objections, or should I upload the
trivial patch?

--
components: Windows
messages: 78753
nosy: krisvale, mhammond
severity: normal
status: open
title: Python on Windows disables all C runtime library assertions
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

___
Python tracker 

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

[issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support

[Derek Morr]

Derek Morr  added the comment:

My understanding is that the FileHandler checks if the file:// URL 
contains the hostname or localhost IP of the local machine (isn't that 
what FileHandler.names is for?). So, shouldn't the following URLs all 
open the same file:

file:///foo.txt
file://localhost/foo.txt
file://127.0.0.1/foo.txt
file://[::1]/foo.txt

If that is the case, then doesn't FileHandler.names need to have all of 
those values in it?

I am a little confused by this though. It looks like 
FileHandler.file_open() checks if there is a hostname in the URL, and 
if so, uses FTPHandler instead. So why does FileHandler.open_local_file 
check the hostname value?

For your other points, gethostbyname() in libc can only handle IPv4 
addresses. The IETF defined the getaddrinfo() interface as an IP 
version neutral replacement. I would recommend using getaddrinfo().

Yes, FTPHandler creates an urllib.FTPWrapper object. That object calls 
into ftplib, which is already IPv6-capable. So, I don't think we need 
to do hostname resolution in FTPHandler.

___
Python tracker 

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

[issue4566] 2.6.1 breaks many applications that embed Python on Windows

[Craig Holmquist]

Craig Holmquist  added the comment:

> test.c's error is "can't find the DLL" - this will be as we attempt to
> load Python's DLL - but this isn't the same as the original error, which
> is "DLL init routine failed".  To repro the initial error, I suspect you
> will want to put the full assembly next to test.exe - that will allow
> python.dll to load - then test.c should call PyExec_EvalString("import
> socket\n") - it is at *that* point the error we care about is likely to
> be thrown.

The test program isn't having a problem loading python26.dll - it gets
to an interpreter prompt and it can execute simple Python statements. 
It doesn't throw ImportError until the user types in "import socket". 
Further, I can see in Process Explorer that python26.dll is loaded in
the running testpy.exe process.  I apologize if my initial description
wasn't clear on that point.

I do see the error codes are different (between testpy.c and
mod_python), but both are triggered by trying to load _socket.pyd.

Nonetheless:  if I copy the CRT assembly into the same folder as
testpy.exe, I get a popup dialog when I try to import socket, saying
"Runtime Error!" and "R6034; An application has made an attempt to load
the C library incorrectly.".  When I click OK in that dialog, I get this
error in the console running testpy.exe:

ImportError: DLL load failed: A dynamic link library (DLL)
initialization routine failed.

(If the assembly is not in the folder, there is no popup dialog at all.)
So it does indeed change the error code received.

Also, I see now that I made a mistake in reporting the error code from
the Apache log.  The actual behavior is this:

* Ordinary, the ImportError is:
ImportError: DLL load failed: The specified module could not be found.

* However, if I put the CRT assembly in the same folder as _socket.pyd:
ImportError: DLL load failed: A dynamic link library (DLL)
initialization routine failed.
and I received the same popup dialog as above.

Putting the CRT assembly in the Apache bin folder or Apache modules
folder still gives the first error (module could not be found).

I apologize for the confusion; when I first experienced this problem I
tried to fix it by experimenting with putting the manifest in various
folders and I wasn't paying close enough attention to what error was
given when.

To summarize:
testpy.exe with CRT assembly in testpy.exe folder: init routine failed
and popup.
testpy.exe with CRT assembly in _socket.pyd folder: init routine failed
and popup.
testpy.exe otherwise: module could not be found

Apache with CRT assembly in _socket.pyd folder: init routine failed and
popup.
Apache otherwise:  module could not be found

___
Python tracker 

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

[issue4805] Make python code compilable with a C++ compiler

[Alexander Belopolsky]

New submission from Alexander Belopolsky :

I am posting this patch mainly to support python-dev discussion on this 
topic.  In the past (see r45330) it was possible to compile python core 
and standard library modules using a C++ compiler.

According to Martin v. Löwis (issue4665), "It's not a requirement that 
the Python source code is compilable as C++. Only the header files 
should be thus compilable." However, I can see certain benefits from 
such requirement:

1. It is hard to verify that header files are compilable if source code 
is not.  With compilable source code, CC=g++ ./configure; make will 
supply an adequate test that does not require anything beyond a standard 
distribution.

2. Arguably, C++ compliant code is more consistent and less error prone.   
For example, "new" is a really bad choice for a variable name regardless 
of being a C++ keyword, especially when used instead of prevailing "res" 
for a result of a function producing a PyObject. Even clearly redundant 
explicit casts of malloc return values arguably improve readability by 
reminding the type of the object that is being allocated.

3. Compiling with C++ may reveal actual coding errors that otherwise go 
unnoticed.  For example, use of undefined PyLong_BASE_TWODIGITS_TYPE in 
Objects/longobject.c.

4. Stricter type checking may promote use of specific types instead of 
void* which in turn may help optimizing compilers.

5. Once achieved, C++ compilability is not that hard to maintain, but 
restoring it with patches like this one is hard because it requires 
review of changes to many unrelated files.

--
files: c++-patch.diff
keywords: patch
messages: 78756
nosy: belopolsky
severity: normal
status: open
title: Make python code compilable with a C++ compiler
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file12527/c++-patch.diff

___
Python tracker 

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

[issue4566] 2.6.1 breaks many applications that embed Python on Windows

[Christian Heimes]

Christian Heimes  added the comment:

> Mark Hammond  added the comment:
> 
> I've no time to dig deeper now as I suspect testing will require removal
> of the vc9 assembly from the GAC and testing with a local one, but some
> comments:

Isn't the GAC just for .NET assemblies while the SxS cache is for non
.NET assemblies? Microsoft's naming schema is confusing as usually. ;)

Christian

___
Python tracker 

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

[issue4272] set timestamp in gzip stream

[Jacques Frechet]

Jacques Frechet  added the comment:

I am uploading a new patch, identical to the previous patch except that
it does not contain the ill-advised third test case
(test_literal_output).  The patch still applies cleanly and the tests
still pass.

Added file: http://bugs.python.org/file12528/gzip-mtime-revised-py3k.patch

___
Python tracker 

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

[issue4272] set timestamp in gzip stream

[Jacques Frechet]

Changes by Jacques Frechet :


Added file: http://bugs.python.org/file12529/gzip-mtime-revised-2.x.patch

___
Python tracker 

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

[issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support

[Senthil]

Senthil  added the comment:

> I am a little confused by this though. It looks like
> FileHandler.file_open() checks if there is a hostname in the URL, and
> if so, uses FTPHandler instead. So why does FileHandler.open_local_file
> check the hostname value?

You are right. Even I had observed this, but did not dispute it. Let
me try to look into the history to see why it so. Perhaps it needs to
change.

> For your other points, gethostbyname() in libc can only handle IPv4
> addresses. The IETF defined the getaddrinfo() interface as an IP
> version neutral replacement. I would recommend using getaddrinfo().
> Yes, FTPHandler creates an urllib.FTPWrapper object. That object calls
> into ftplib, which is already IPv6-capable. So, I don't think we need
> to do hostname resolution in FTPHandler.

Thanks for the info. I shall look into both in revision of the path.
1) using getaddrinfo() for IP version neutral call.
2) passing the hostname directly to ftplib. ( I am not sure of
consequences, need to investigate).

___
Python tracker 

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

[issue4791] retrlines('LIST') and dir hang at end of listing in ftplib (python3.0)

[Christopher Mahan]

Christopher Mahan  added the comment:

I modified the program by adding line: ftp.set_debuglevel(2)
START LISTING
import ftplib

ftp = ftplib.FTP('ftp.edgecastcdn.net', user='myuserid',
passwd='mypassword')
ftp.set_debuglevel(2)
ftp.cwd('chrismahan-675')
ftp.dir()
#ftp.retrlines('LIST')
ftp.close()
END LISTING ---

Running from idle 1.2.4 with python 2.5.4 gives this output:

*cmd* 'CWD chrismahan-675'
*put* 'CWD chrismahan-675\r\n'
*get* '250 CWD command successful\r\n'
*resp* '250 CWD command successful'
*cmd* 'TYPE A'
*put* 'TYPE A\r\n'
*get* '200 Type set to A\r\n'
*resp* '200 Type set to A'
*cmd* 'PASV'
*put* 'PASV\r\n'
*get* '227 Entering Passive Mode (72,21,82,190,234,6).\r\n'
*resp* '227 Entering Passive Mode (72,21,82,190,234,6).'
*cmd* 'LIST'
*put* 'LIST\r\n'
*get* '150 Opening ASCII mode data connection for file list\r\n'
*resp* '150 Opening ASCII mode data connection for file list'
-rwxrwxrwx   1 nobody   nogroup   3905538 Dec 29 09:51 Bronski Beat -
Why.mp3
-rwxrwxrwx   1 nobody   nogroup873966 Dec 28 13:53 test9.avi
-rwxrwxrwx   1 nobody   nogroup   2512653 Dec 29 08:28 test9_lg.wmv
-rwxrwxrwx   1 nobody   nogroup  6549 Dec 29 08:28 test9_lg.wmv.jpg
-rwxrwxrwx   1 nobody   nogroup   1788466 Dec 29 03:04 test9_med.flv
-rwxrwxrwx   1 nobody   nogroup  6394 Dec 29 03:04 test9_med.flv.jpg
-rwxrwxrwx   1 nobody   nogroup   1263041 Dec 28 13:53 test9_sm.flv
-rwxrwxrwx   1 nobody   nogroup  6465 Dec 28 13:53 test9_sm.flv.jpg
*get* '226 Transfer complete\r\n'
*resp* '226 Transfer complete'


Then running with idle 3.0 with python 3.0 gives the following result.

*cmd* 'CWD chrismahan-675'
*put* 'CWD chrismahan-675\r\n'
*get* '250 CWD command successful\n'
*resp* '250 CWD command successful'
*cmd* 'TYPE A'
*put* 'TYPE A\r\n'
*get* '200 Type set to A\n'
*resp* '200 Type set to A'
*cmd* 'PASV'
*put* 'PASV\r\n'
*get* '227 Entering Passive Mode (72,21,82,190,148,178).\n'
*resp* '227 Entering Passive Mode (72,21,82,190,148,178).'
*cmd* 'LIST'
*put* 'LIST\r\n'
*get* '150 Opening ASCII mode data connection for file list\n'
*resp* '150 Opening ASCII mode data connection for file list'
-rwxrwxrwx   1 nobody   nogroup   3905538 Dec 29 09:51 Bronski Beat -
Why.mp3
-rwxrwxrwx   1 nobody   nogroup873966 Dec 28 13:53 test9.avi
-rwxrwxrwx   1 nobody   nogroup   2512653 Dec 29 08:28 test9_lg.wmv
-rwxrwxrwx   1 nobody   nogroup  6549 Dec 29 08:28 test9_lg.wmv.jpg
-rwxrwxrwx   1 nobody   nogroup   1788466 Dec 29 03:04 test9_med.flv
-rwxrwxrwx   1 nobody   nogroup  6394 Dec 29 03:04 test9_med.flv.jpg
-rwxrwxrwx   1 nobody   nogroup   1263041 Dec 28 13:53 test9_sm.flv
-rwxrwxrwx   1 nobody   nogroup  6465 Dec 28 13:53 test9_sm.flv.jpg

Note that the last two lines are missing.


>From a command prompt:
C:\>c:\python30\python.exe c:\python_scripts\python3\candee_processor.py
*cmd* 'CWD chrismahan-675'
*put* 'CWD chrismahan-675\r\n'
*get* '250 CWD command successful\n'
*resp* '250 CWD command successful'
*cmd* 'TYPE A'
*put* 'TYPE A\r\n'
*get* '200 Type set to A\n'
*resp* '200 Type set to A'
*cmd* 'PASV'
*put* 'PASV\r\n'
*get* '227 Entering Passive Mode (72,21,82,190,219,8).\n'
*resp* '227 Entering Passive Mode (72,21,82,190,219,8).'
*cmd* 'LIST'
*put* 'LIST\r\n'
*get* '150 Opening ASCII mode data connection for file list\n'
*resp* '150 Opening ASCII mode data connection for file list'
-rwxrwxrwx   1 nobody   nogroup   3905538 Dec 29 09:51 Bronski Beat -
Why.mp3
-rwxrwxrwx   1 nobody   nogroup873966 Dec 28 13:53 test9.avi
-rwxrwxrwx   1 nobody   nogroup   2512653 Dec 29 08:28 test9_lg.wmv
-rwxrwxrwx   1 nobody   nogroup  6549 Dec 29 08:28 test9_lg.wmv.jpg
-rwxrwxrwx   1 nobody   nogroup   1788466 Dec 29 03:04 test9_med.flv
-rwxrwxrwx   1 nobody   nogroup  6394 Dec 29 03:04 test9_med.flv.jpg
-rwxrwxrwx   1 nobody   nogroup   1263041 Dec 28 13:53 test9_sm.flv
-rwxrwxrwx   1 nobody   nogroup  6465 Dec 28 13:53 test9_sm.flv.jpg

same command prompt but with python 2.5:

C:\>c:\python25\python.exe c:\python_scripts\python3\candee_processor.py
*cmd* 'CWD chrismahan-675'
*put* 'CWD chrismahan-675\r\n'
*get* '250 CWD command successful\r\n'
*resp* '250 CWD command successful'
*cmd* 'TYPE A'
*put* 'TYPE A\r\n'
*get* '200 Type set to A\r\n'
*resp* '200 Type set to A'
*cmd* 'PASV'
*put* 'PASV\r\n'
*get* '227 Entering Passive Mode (72,21,82,190,147,65).\r\n'
*resp* '227 Entering Passive Mode (72,21,82,190,147,65).'
*cmd* 'LIST'
*put* 'LIST\r\n'
*get* '150 Opening ASCII mode data connection for file list\r\n'
*resp* '150 Opening ASCII mode data connection for file list'
-rwxrwxrwx   1 nobody   nogroup   3905538 Dec 29 09:51 Bronski Beat -
Why.mp3
-rwxrwxrwx   1 nobody   nogroup873966 Dec 28 13:53 test9.avi
-rwxrwxrwx   1 nobody   nogroup   2512653 Dec 29 08:28 test9_lg.wmv
-rwxrwxrwx   1 nobody   nogroup  6549 Dec 29 08:28 test9_lg.wmv.jpg
-rwxrwxrwx   1 nobody   nogroup   1788466 Dec 29 03:04 test9_med.flv
-rwxrwxrwx   1 nobody   nogroup  6394 Dec

[issue4791] retrlines('LIST') and dir hang at end of listing in ftplib (python3.0)

[Christopher Mahan]

Christopher Mahan  added the comment:

I went into the source for Libs/ftplib.py  and I noted that line 423 is: 

if self.debugging > 2: print('*retr*', repr(line))

so I changed the debuglevel to 3, as such:  ftp.set_debuglevel(3)
and I got these last 4 lines:

-rwxrwxrwx   1 nobody   nogroup  6465 Dec 28 13:53 test9_sm.flv.jpg
*retr* ''
*get* '226 Transfer complete\r\n'
*resp* '226 Transfer complete'

First line, the last line of the listing.
second line, the debug, showing the last  line read
third and fourth lines: the program actually completed and didn't hang!

still digging

___
Python tracker 

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

[issue4566] 2.6.1 breaks many applications that embed Python on Windows

[Craig Holmquist]

Craig Holmquist  added the comment:

I took a look at this with the debugger, as Mark recommended.  The CRT's
DLLMain is called _CRTDLL_INIT, that in turn calls __CRTDLL_INIT. 
__CRTDLL_INIT calls another function, _check_manifest.

_check_manifest calls an SxS function called FindActCtxSectionString. 
It's looking for a string called "msvcr90.dll" in the
ACTIVATION_CONTEXT_SECTION_DLL_REDIRECTION section of the process's
activation context (activation contexts are data structures used by
SxS).  That call fails (_check_manifest doesn't call GetLastError or
anything, it just returns FALSE right there).  There's a comment there
that says:

/* no activation context used to load CRT DLL, means no manifest present
in the process */

What's bizarre is that python26.dll successfully loaded msvcr90.dll (the
global one from WinSxS), so it must have passed _check_manifest.  It
seems like the activation context consists of the DLL's manifest
(_socket.pyd's in this case) and the exe's manifest, but no other ones,
regardless of what other libraries have been loaded.  The documentation
doesn't seem to explain the interaction between manifests in different
modules.  It's also annoying that this restriction (the _check_manifest
call) is completely artificial.

I don't know if any of this information is useful (I'm only
superficially familiar with activation contexts and the functions to
manipulate them).  The code is all in crtlib.c (in the CRT source) if
someone else wants to take a look.

___
Python tracker 

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

[issue4791] retrlines('LIST') and dir hang at end of listing in ftplib (python3.0)

[Christopher Mahan]

Christopher Mahan  added the comment:

I added the following two lines and I was able to run the code.


Before: 
line = fp.readline()
if self.debugging > 2: print('*retr*', repr(line))
if not line:
break
if line[-2:] == CRLF:
line = line[:-2]
elif line[-1:] == '\n':
line = line[:-1]
callback(line)

After: 
line = fp.readline()
if self.debugging > 2: print('*retr*', repr(line))
if not line:
break
if line == '':
break
if line[-2:] == CRLF:
line = line[:-2]
elif line[-1:] == '\n':
line = line[:-1]
callback(line)

As a patch:

426,427d425
< if line == '':
< break

What else do I need to do?

___
Python tracker 

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

[issue4805] Make python code compilable with a C++ compiler

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

A related question discussed on python-dev is whether extern "C" {} 
wrappers should ever be used in .c files.  I argue that the answer is "no" 
even if C++ compilability is desired.

The new patch eliminates several uses of extern "C" {} in .c files while 
preserving C++ compilability.  This is achieved by including proper header 
files instead of declaring external functions in .c files and in some 
cases adding declarations of functions that are used outside of the files 
they are defined in in the appropriate header files.

Added file: http://bugs.python.org/file12530/c++-patch-1.diff

___
Python tracker 

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