[issue7792] Errors registering non-classes with ABCs

[Chris Withers]

Chris Withers  added the comment:

...and for the second feature, Andrew may wish to look at zope.component, which 
provides for this already.

--
nosy: +cjw296

___
Python tracker 

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

[issue7793] regrtest fails with "RuntimeError: maximum recursion depth exceeded" in some cases

[Chris Withers]

Chris Withers  added the comment:

Can you try and list what the cases are which cause this failure to occur?

--
nosy: +cjw296

___
Python tracker 

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

[issue5673] Add timeout option to subprocess.Popen

[Senthil Kumaran]

Changes by Senthil Kumaran :


--
nosy: +orsenthil

___
Python tracker 

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

[issue7793] regrtest fails with "RuntimeError: maximum recursion depth exceeded" in some cases

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

The module is probably reloaded, which causes code like:
_ord = ord
def ord(c):
... _ord(c) ...
to form a recursion loop.
Attached patch removes the need for a special ord().

All this should be simply removed in py3k branch: ord() and chr() do the right 
thing even on narrow unicode builds.

--
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file16022/test_multibytecodec.patch

___
Python tracker 

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

[issue7753] newgil backport

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Ross Cohen wrote:
> 
> Ross Cohen  added the comment:
> 
> On Fri, 22 Jan 2010 09:32:36 +
> Marc-Andre Lemburg  wrote:
> 
>>  * Please add the fallback solutions from the time module in case 
>> gettimeofday() is not available. You cannot assume that "all modern POSIX 
>> systems" implement that API - it was introduced in POSIX 2001 and Python 2.x 
>> still supports OSes that were released prior to that year.
> 
> POSIX as a standard tends to follow, not lead. The gettimeofday() call
> dates back over 20 years in BSD. time.time() falls back on ftime() and
> then time(). ftime() was added to the POSIX spec at the same time as
> gettimeofday() and is now deprecated. time() probably doesn't have
> enough resolution.
> 
> I'd have to be pointed to a specific platform which doesn't support
> gettimeofday() but which is supported by python. Otherwise, I'd be
> coding blind.

The point here is that we have traditionally been careful not
to break Python for platforms that don't support a certain API,
hence the different fallback solutions for getting the current
time.

gettimeofday() is indeed available on most OSes, but not all. VxWorks
is an example where it is not available and Python happily uses
alternatives.

http://www.gsalcazar.altervista.org/tools/how-to-port-python-to-vxworks/?PHPSESSID=u5do9v0lh2gqdqilmikv7nmsk1

There are also cases where gettimeofday() is buggy
(e.g. on Solaris: http://www.unix.com/sun-solaris/59187-bugs-clock.html or
Cygwin: 
http://old.nabble.com/About-The---GetMicroSecondTime-on-Windows---Post-td13721510.html)
or returns errors every now and then (I have observed that in mxDateTime
occasionally - it may be related to NTP doing its works).

For those situations is necessary to be able to enable a
fallback solution using other APIs.

I've also done some extra research yesterday and found that e.g.
Ruby is using gettimeofday() for thread scheduling as well. They
have observed issues with gettimeofday() causing problems due
to wallclock time not being a monotonic (e.g. due to NTP running
on the machine and the clock sometimes going backwards due to
corrections or DST changes).

http://groups.google.com/group/ruby-talk-google/browse_thread/thread/f8a616113e2eea8f

OTOH, using process timers is also not regarded as being ideal,
since on SMP systems, each CPU will have its own timer and they
are not necessarily in sync.

Other implementations tend to use the new clock_gettime() APIs
where available and then use the CLOCK_MONOTONIC timer, e.g.

http://stackoverflow.com/questions/88/is-gettimeofday-guaranteed-to-be-of-microsecond-resolution
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=272

Here's some example code which tries to cover even more platforms
than Python 2.x:

http://www.koders.com/c/fid5A75B2B62D4024A2431D060ADD5D378DB7A1D2BD.aspx

Another aspect to consider is update frequency of these APIs.
gettimeofday()'s resolution depends on various factors and
appears to vary between 1us and 100ms (on systems running using
a 100Hz clock).

http://answers.google.com/answers/threadview/id/203397.html
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=272
https://computing.llnl.gov/tutorials/performance_tools/#gettimeofday

clock_gettime() has similar resolution, but tends to be updated
more often:

http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1264587819627+28353475&threadId=1230881

And finally, using wallclock time for these things is expensive
as I've already mentioned:

http://groups.google.com/group/comp.os.linux.development.apps/browse_frm/thread/dc29071f2417f75f/c46264dba0863463?lnk=st&rnum=1#c46264dba0863463
http://www.developerweb.net/forum/archive/index.php/t-4368.html
http://h21007.www2.hp.com/portal/download/files/unprot/hpux/HowToTellTheTime.pdf
(as HTML:
http://209.85.129.132/search?q=cache%3AI1ihHYBMJvgJ%3Ah21007.www2.hp.com%2Fportal%2Fdownload%2Ffiles%2Funprot%2Fhpux%2FHowToTellTheTime.pdf+gettimeofday()+support+across+platforms&hl=en&gl=de)

It appears to be better to use clock_gettime(CLOCK_MONOTONIC)
where available and only use gettimeofday() as fallback solution
together with times(), ftime() and time().

--

___
Python tracker 

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

[issue7753] newgil backport

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Ross Cohen wrote:
>> By the way, the new GIL only works with POSIX and Windows NT threading APIs. 
>> Perhaps it can't be backported at all to 2.x, given that 2.x supports more 
>> threading APIs than py3k does?
> 
> Looking at the Python/thread_*.h files, it looks like py3k still
> supports 9 different threading models. If that's accurate, it means
> py3k trunk is broken on platforms which use cthread, lwp, os2, pth,
> sgi, solaris and wince threading models. The 2.x series adds atheos and
> beos to that list.
> 
> I think the right way to fix this is to extend the thread_*.h files to
> have a proper abstraction for conditions which can be used by the
> newgil work. Then the maintainers for more obscure platforms can fix
> those instead of it all turning into a big mess in ceval_gil.h.

I find it rather strange that Python 3.x now only supports
NT and POSIX threads in ceval while it still supports the
whole set of other thread implementations for the _thread
module.

Has this been discussed on python-dev ?

Why can't the code necessary to get the new GIL working be
added to Sjoerd's portable thread library ?

As it stands, I think this is a bummer for both Python 2.7 and 3.2.

--

___
Python tracker 

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

[Stefan Krah]

Stefan Krah  added the comment:

Marc-Andre,

on 64-bit Ubuntu, this method ...

BASECFLAGS=-m32 LDFLAGS=-m32 ./configure

... results in a gcc segfault:


gcc -pthread -m32 -Xlinker -export-dynamic -o python \
Modules/python.o \
libpython3.2.a -lpthread -ldl  -lutil   -lm  
Segmentation fault
make: *** [sharedmods] Error 139



Antoine's patch and command line work.

--
nosy: +skrah

___
Python tracker 

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

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Stefan Krah wrote:
> 
> Stefan Krah  added the comment:
> 
> Marc-Andre,
> 
> on 64-bit Ubuntu, this method ...
> 
> BASECFLAGS=-m32 LDFLAGS=-m32 ./configure
> 
> ... results in a gcc segfault:
> 
> 
> gcc -pthread -m32 -Xlinker -export-dynamic -o python \
> Modules/python.o \
> libpython3.2.a -lpthread -ldl  -lutil   -lm  
> Segmentation fault
> make: *** [sharedmods] Error 139
> 
> 
> 
> Antoine's patch and command line work.

Just to get an idea of why the above fails, could you provide the
line from the build with Antoine's patch applied ?!

I starting to think that we should apply Antoine's patch for 2.7/3.2
and leave the CFLAGS cleanup to some other release.

--

___
Python tracker 

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

[issue1225769] Proposal to implement comment rows in csv module

[Mario Fasold]

Mario Fasold  added the comment:

Comment lines are a *very* common case in scientific and statistical data. +1 
for the change.

--
nosy: +Mario.Fasold

___
Python tracker 

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

[Stefan Krah]

Stefan Krah  added the comment:

The builds are almost identical, so I attach a diff of the build output.
For both builds, I used a fresh Python-3.1.1 directory. This looks
suspicious:

-checking whether va_list is an array... yes
+checking whether va_list is an array... no


For completeness' sake: "-fno-strict-aliasing -m32" were reversed in the
BASECFLAGS case, so I edited the BASECFLAGS output for the purposes of
creating a diff.

--
Added file: http://bugs.python.org/file16023/basecflags-vs-patch-3.1.1.builddiff

___
Python tracker 

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

[Stefan Krah]

Changes by Stefan Krah :


Removed file: 
http://bugs.python.org/file16023/basecflags-vs-patch-3.1.1-builddiff.txt

___
Python tracker 

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

[Stefan Krah]

Changes by Stefan Krah :


Added file: 
http://bugs.python.org/file16024/basecflags-vs-patch-3.1.1-builddiff.txt

___
Python tracker 

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

[issue7753] newgil backport

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Le mercredi 27 janvier 2010 à 10:37 +, Marc-Andre Lemburg a écrit :
> 
> I find it rather strange that Python 3.x now only supports
> NT and POSIX threads in ceval while it still supports the
> whole set of other thread implementations for the _thread
> module.
> 
> Has this been discussed on python-dev ?

Yes, it was. See
http://mail.python.org/pipermail/python-dev/2009-October/093276.html
All these thread_*.h files are still there, but most of them are
deprecated (see the #error's in thread.c). It's the consensus that came
out on the mailing-list.

The one exception is OS/2, which is "supported" as long as Andrew
McIntyre (or someone else, of course) takes care about it. It was
decided that OS/2 compatibility wasn't important enough to bar adding
new features or making improvements.

> Why can't the code necessary to get the new GIL working be
> added to Sjoerd's portable thread library ?

The condition variable "emulation" used by the new GIL under Windows is
not valid as a general condition variable mechanism; this is mentioned
in ceval_gil.h, and a link is given to a much more complicated (but
valid) condition variable emulation. Therefore, I think it could be
detrimental to expose it publicly.

--

___
Python tracker 

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

[issue7753] newgil backport

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Le mercredi 27 janvier 2010 à 10:33 +, Marc-Andre Lemburg a écrit :
> 
> It appears to be better to use clock_gettime(CLOCK_MONOTONIC)
> where available and only use gettimeofday() as fallback solution
> together with times(), ftime() and time().

Thanks for the research! I will take a look at this.

--

___
Python tracker 

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

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Stefan Krah wrote:
> 
> Stefan Krah  added the comment:
> 
> The builds are almost identical, so I attach a diff of the build output.
> For both builds, I used a fresh Python-3.1.1 directory. This looks
> suspicious:
> 
> -checking whether va_list is an array... yes
> +checking whether va_list is an array... no
> 
> 
> For completeness' sake: "-fno-strict-aliasing -m32" were reversed in the
> BASECFLAGS case, so I edited the BASECFLAGS output for the purposes of
> creating a diff.

Thanks.

Looking at the diff I cannot see any difference between the
two builds in terms of gcc options applied during the compile
and link step.

As you noticed, this leaves the va_list difference which also
causes the warnings in the 32-bit build.

I guess this points to the real cause of the problem: configure
doesn't know anything about BASECFLAGS, but does use CFLAGS for
checking various compiler features, so Antoines command line
options using CFLAGS work, while the ones I posted don't.

--

___
Python tracker 

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

[issue7794] Document zipfile and directory execution in What's New for 2.6/3.1

[Nick Coghlan]

New submission from Nick Coghlan :

As discussed recently on python-dev, issue 1739468 deserves a mention in the 
What's New for the relevant Python releases.

--
assignee: ncoghlan
components: Documentation
keywords: easy
messages: 98420
nosy: akuchling, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Document zipfile and directory execution in What's New for 2.6/3.1
type: behavior
versions: Python 2.6, Python 3.1

___
Python tracker 

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

[issue1225769] Proposal to implement comment rows in csv module

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Comment lines in csv data may be common in some areas, but they are not part of 
any standard, and they are not the only possible extension to csv files (for 
example: ignore empty lines, or a terminal \ for line continuation...)

Currently all members of Dialect deal with the format of the records, not with 
the extraction of records from the file. (lineterminator is used only when 
writing).

The "CommentedFile" filter above is a good recipe for all cases, and is easy to 
use. I recommend closing this issue.

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue1225769] Proposal to implement comment rows in csv module

[Éric Araujo]

Éric Araujo  added the comment:

Hello

Shouldn't the comment char definition belong in a dialect class? The reader 
would still have to be modified to skip these lines, but having this char in 
the dialect would not require a change to csv.reader signature.

Kind regards

--
nosy: +Merwok

___
Python tracker 

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

[issue7753] newgil backport

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou  added the comment:
> 
> Le mercredi 27 janvier 2010 à 10:37 +, Marc-Andre Lemburg a écrit :
>>
>> I find it rather strange that Python 3.x now only supports
>> NT and POSIX threads in ceval while it still supports the
>> whole set of other thread implementations for the _thread
>> module.
>>
>> Has this been discussed on python-dev ?
> 
> Yes, it was. See
> http://mail.python.org/pipermail/python-dev/2009-October/093276.html
> All these thread_*.h files are still there, but most of them are
> deprecated (see the #error's in thread.c). It's the consensus that came
> out on the mailing-list.
> 
> The one exception is OS/2, which is "supported" as long as Andrew
> McIntyre (or someone else, of course) takes care about it. It was
> decided that OS/2 compatibility wasn't important enough to bar adding
> new features or making improvements.

The arguments given in that thread sound a bit strange to me:
just because there were no changes to a few files, doesn't really
say anything about whether they contain working code or not.

In any case, the new GIL implementation as it stands makes
supporting any of those additional threading implementations
a moot case.

You could just as well remove them right now: if the GIL doesn't
work on OS/2, then having support for it in the _thread module
isn't really worth much, is it ?

Regardless, instead of now having two places where threading is
implemented, we should just have one: the portable thread library and
extend this as necessary.

>> Why can't the code necessary to get the new GIL working be
>> added to Sjoerd's portable thread library ?
> 
> The condition variable "emulation" used by the new GIL under Windows is
> not valid as a general condition variable mechanism; this is mentioned
> in ceval_gil.h, and a link is given to a much more complicated (but
> valid) condition variable emulation. Therefore, I think it could be
> detrimental to expose it publicly.

By moving all the thread support code to the thread library,
you don't really expose anything (the lib is only used internally
by Python), you just reorganize the code in a more natural and
easier to maintain way.

If you think that the win32 emulation shouldn't be
used for non-GIL purposes, then just add a comment to
those APIs.

With just NT and POSIX thread support, I think backporting the
new GIL implementation to 2.7 is not possible - we'd have to go
through a standard PEP 11 deprecation process and there are not
enough 2.x releases left for that. It could only be backported
as optional feature, to be enabled by a configure option.

--

___
Python tracker 

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

[issue5498] Can SGMLParser properly handle tags?

[Éric Araujo]

Éric Araujo  added the comment:

Hello

XML of the form  are an SGML hack, or more precisely the combination of 
two features of SGML. The forward slash closes the tag, and the following angle 
bracket is character data, not part of the tag.

The W3C validator  uses a real SGML parser for HTML doctypes, and fails on 
XML-like /> constructs: 
http://validator.w3.org/check?uri=data%3Atext%2Fhtml%2C%3C!DOCTYPE+html+PUBLIC+%22-%2F%2FW3C%2F%2FDTD+HTML+4.01%2F%2FEN%22+%22http%3A%2F%2Fwww.w3.org%2FTR%2Fhtml4%2Fstrict.dtd%22%3E+%3Chtml%3E+%3Chead%3E+++%3Ctitle%3ETest%3C%2Ftitle%3E+++%3Cmeta+name%3Dtest+content%3Done%2F%3E+++%3Cmeta+name%3Dbug+content%3Dtwo%3E+%3C%2Fhead%3E+%3Cbody%3E+++%3Cp%3ETest%3C%2Fp%3E+%3C%2Fbody%3E+%3C%2Fhtml%3E&charset=%28detect+automatically%29&doctype=Inline&group=1&verbose=1

The complete explanation can be read at 
http://www.cs.tut.fi/~jkorpela/html/empty.html

In conclusion, sgmllib is right. Use an XML parser for XML or an HTML5 parser 
for HTML.

Kind regards

--
nosy: +Merwok

___
Python tracker 

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

[issue5498] Can SGMLParser properly handle tags?

[Éric Araujo]

Éric Araujo  added the comment:

Damn, the URI got fubared :/ Anyway, I just wanted to give an example of the 
verbose error message, but the second link will contain enough explanation.

Regards

--

___
Python tracker 

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

[issue1225769] Proposal to implement comment rows in csv module

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

> Shouldn't the comment char definition belong in a dialect class?
The proposed patch does this correctly; then csv.reader automatically accepts 
the dialect parameters to override the selected dialect.

I'm still -1 on the feature - not standard enough, and easy to implement 
outside the csv module.

--

___
Python tracker 

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

[issue7795] BaseManager of multiprocessing module throws an exception if socket.setdefaulttimeout is set

[Jonas Weismüller]

New submission from Jonas Weismüller :

If socket.setdefaulttimeout is set to any value (except None), the BaseManager 
raises an exception and the execution of the remote object fails:
Traceback (most recent call last):
  File "client.py", line 16, in 
m = Manager()
  File "client.py", line 12, in __init__
self.connect()
  File "/usr/lib/python2.6/multiprocessing/managers.py", line 474, in connect
conn = Client(self._address, authkey=self._authkey)
  File "/usr/lib/python2.6/multiprocessing/connection.py", line 140, in Client
answer_challenge(c, authkey)
  File "/usr/lib/python2.6/multiprocessing/connection.py", line 371, in 
answer_challenge
message = connection.recv_bytes(256) # reject large message

See the attached client.py (uploading soon) and server.py file to reproduce the 
error.

Python version used:
Python 2.6 (r26:66714, Jun  8 2009, 16:07:26)
[GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2

Same behaviour with python version:
Python 2.6 (r26:66714, Nov  3 2009, 17:33:38)
[GCC 4.4.1 20090725 (Red Hat 4.4.1-2)] on linux2

The operating system is Fedora 11.

--
components: Library (Lib)
files: server.py
messages: 98427
nosy: MrRagga
severity: normal
status: open
title: BaseManager of multiprocessing module throws an exception if 
socket.setdefaulttimeout is set
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file16025/server.py

___
Python tracker 

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

[issue7795] BaseManager of multiprocessing module throws an exception if socket.setdefaulttimeout is set

[Jonas Weismüller]

Jonas Weismüller  added the comment:

uploading missing client file, changing the socket.setdefaulttimeout shows the 
issue.

--
Added file: http://bugs.python.org/file16026/client.py

___
Python tracker 

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

[issue7753] newgil backport

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> The arguments given in that thread sound a bit strange to me:
> just because there were no changes to a few files, doesn't really
> say anything about whether they contain working code or not.

That was a heuristic. Files which do not get any maintenance for years
while other similar files do are quite suspicious.
Given that nobody stepped up to contradict this hypothesis of mine, I
assume it was right after all ;)

More seriously, all the APIs in question (and most of their supporting
systems: IRIX etc.) seem practically dead. I don't want to rehash that
discussion here, but you can post on python-dev if you want.

> You could just as well remove them right now: if the GIL doesn't
> work on OS/2, then having support for it in the _thread module
> isn't really worth much, is it ?

Andrew told me he believed it possible to port the new GIL to OS/2. So
perhaps he'll do that before 3.2 is out.

> With just NT and POSIX thread support, I think backporting the
> new GIL implementation to 2.7 is not possible - we'd have to go
> through a standard PEP 11 deprecation process and there are not
> enough 2.x releases left for that. It could only be backported
> as optional feature, to be enabled by a configure option.

Right. That's what I think too.

--

___
Python tracker 

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

[issue7784] patch for making list/insert at the top of the list avoid memmoves

[showell]

showell  added the comment:

I will attempt to fix insert(0, pop) in the next patch I submit (using pointer 
vs. orphans count).

Just so we are clear on the performance that I'm promising, I expect benchmarks 
to prove out these facts:

  1) New-list will always perform comparably to old-list, particularly for 
access.
  2) New-list will outperform old-list for pre-pop.
  3) New-list will perform comparably to deque for pre-pop.
  4) Although not a super common use case, prepends that follow prepops should 
reclaim space and perform better than old list and comparably to deque.
  5) For prepends that exceed prepops, I expect deque to greatly outperform new 
lists, just as it did old lists.

As I explained on python-dev, the new patch should give lists the same 
performance profile as a pencil/paper todo list.  Prepop works in O(1) with 
occasional compacting.  Prepend generally works in O(N) unless you can reclaim 
space from prior prepops.

To measure memory wastage, the two worst case scenarios are a bunch of tiny 
lists or a list from you which you prepop just under 50% of the elements 
(although that 50% can be tuned later if that's the only showstopper).  You can 
certainly construct a benchmark that brings those negative aspects to light, 
but I think it would be more convincing to find an actual real-world program 
that performs worse or exhausts memory under the limitation.

In general, it would be nice to find a Python program that makes extensive use 
of lists to prove out that the new list implementation at least does not 
degrade performance.  To the extent that test suite all passes, we at least 
have some empirical evidence that "correctness" has not been jeopardized, but 
the more we can hammer on this, the better, of course.  Does anybody have a 
suggestion for a real-world list benchmark program?

--

___
Python tracker 

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

[issue7784] patch for making list/insert at the top of the list avoid memmoves

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

For macro benchmarking, I suggest using the Unladen Swallow benchmark suite.

--

___
Python tracker 

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

[issue7753] newgil backport

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou  added the comment:
> 
>> The arguments given in that thread sound a bit strange to me:
>> just because there were no changes to a few files, doesn't really
>> say anything about whether they contain working code or not.
> 
> That was a heuristic. Files which do not get any maintenance for years
> while other similar files do are quite suspicious.
> Given that nobody stepped up to contradict this hypothesis of mine, I
> assume it was right after all ;)

We'll only be able to tell for sure when it's too late: at release
time. We simply don't have any active developers working on more
exotic platforms, but that doesn't mean that Python isn't used
on those platforms.

> More seriously, all the APIs in question (and most of their supporting
> systems: IRIX etc.) seem practically dead. I don't want to rehash that
> discussion here, but you can post on python-dev if you want.

No need... I'm tired of trying to get Python devs on track with
respect to the PEP 11 process, deprecations, etc.

>> You could just as well remove them right now: if the GIL doesn't
>> work on OS/2, then having support for it in the _thread module
>> isn't really worth much, is it ?
> 
> Andrew told me he believed it possible to port the new GIL to OS/2. So
> perhaps he'll do that before 3.2 is out.
>
>> With just NT and POSIX thread support, I think backporting the
>> new GIL implementation to 2.7 is not possible - we'd have to go
>> through a standard PEP 11 deprecation process and there are not
>> enough 2.x releases left for that. It could only be backported
>> as optional feature, to be enabled by a configure option.
> 
> Right. That's what I think too.

I'll close the issue then.

--

___
Python tracker 

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

[issue7753] newgil backport

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Closing the issue since we can't backport to Python 2.7 due to the missing 
thread library support.

The patch may still be useful for experiments by users, though, so thanks to 
Ross and Neil for creating it.

--
resolution:  -> rejected
status: open -> closed

___
Python tracker 

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

[issue7795] BaseManager of multiprocessing module throws an exception if socket.setdefaulttimeout is set

[Brian Curtin]

Brian Curtin  added the comment:

Duplicate of #6056.

--
nosy: +brian.curtin
priority:  -> normal
resolution:  -> duplicate
status: open -> closed
type: crash -> behavior

___
Python tracker 

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

[Stefan Krah]

Stefan Krah  added the comment:

(1) I can get around the configure problem by patching configure.in,
meaning that va_list is detected correctly now. Perhaps BASECFLAGS
should be used by default for the compile tests?

(2) Now I run into the problem that distutils somehow ignores the
LDFLAGS:

 
gcc -pthread -shared 
build/temp.linux-x86_64-3.2/home/stefan/tmp/svn/py3k/Modules/_struct.o 
-L/usr/local/lib -o build/lib.linux-x86_64-3.2/_struct.so
collect2: ld terminated with signal 11 [Segmentation fault]



So it might be possible to fix the situation by changing configure.in
and distutils. On the other hand, the patches from Bob and Antoine are
simpler.

--
Added file: http://bugs.python.org/file16027/basecflags-configure.in.patch

___
Python tracker 

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

[issue6715] xz compressor support

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
dependencies:  -please support lzma compression as an extension and in  the 
tarfile module
priority:  -> high

___
Python tracker 

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

[issue5689] please support lzma compression as an extension and in the tarfile module

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
dependencies: +xz compressor support

___
Python tracker 

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

[issue1225769] Proposal to implement comment rows in csv module

[Skip Montanaro]

Skip Montanaro  added the comment:

Amaury> Comment lines in csv data may be common in some areas, but they
Amaury> are not part of any standard, and they are not the only possible
Amaury> extension to csv files (for example: ignore empty lines, or a
Amaury> terminal \ for line continuation...)

Or different peoples' notion of how to comment strings.  Precidely because
there is no standard way to comment out content in CSV files people are free
to dream up anything they want, including,
but not limited to:

* C- or C++-style comments
* MoinMoin-style comments, where "##" introduces a comment but a lone
  "#" introduces a meta command to the parser

Trying to accommodate the myriad varieties of way s people might decide to
comment out content would put an undue burden on the csv module's parser.

Skip

--

___
Python tracker 

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

[issue7796] No way to find out if an object is an instance of a namedtuple

[Peter Waller]

New submission from Peter Waller :

Apologies if there is a way of doing this, but I haven't been able to find 
anything.

I need to be able to do the following:

my_tuple = namedtuple("my_tuple", "a b c")
obj = my_tuple(1,2,3)

if isinstance(obj, namedtuple):
.. do stuff ..

The best I could come up with for the moment is:

if isinstance(obj, tuple) and type(obj) is not tuple:
.. do stuff ..

--
messages: 98437
nosy: pwaller
severity: normal
status: open
title: No way to find out if an object is an instance of a namedtuple
versions: Python 2.6

___
Python tracker 

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

[issue1225769] Proposal to implement comment rows in csv module

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Agreed with Skip, Raymond and Amaury.
Since the csv module returns you an iterator, it's easy enough to wrap it in 
another iterator.

--
nosy: +pitrou

___
Python tracker 

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

[issue7796] No way to find out if an object is an instance of a namedtuple

[Antoine Pitrou]

Antoine Pitrou  added the comment:

In this case, what is wrong with:

if isinstance(obj, my_tuple): ...

or do you want to catch all namedtuples? And if so, why?

(I suppose it would be easy to make all namedtuples inherit from a common base 
class, though)

--
assignee:  -> rhettinger
nosy: +pitrou, rhettinger
priority:  -> normal
stage:  -> needs patch
type:  -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.6

___
Python tracker 

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

[issue7796] No way to find out if an object is an instance of a namedtuple

[Éric Araujo]

Éric Araujo  added the comment:

Hello

namedtuple is a factory function, not a class (as hinted by the naming in lower 
case, see PEP 8), so there are no instances of namedtuple.

You can workaround that with issubclass, or checking for special namedtuples 
attributes (_asdict, _replace, but this is fragile), or just not use class 
cheking, often unneeded in Python code.

Kind regards

--
nosy: +Merwok

___
Python tracker 

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

[issue7796] No way to find out if an object is an instance of a namedtuple

[Peter Waller]

Peter Waller  added the comment:

Hi Antoine and Eric, 

Thanks for your responses.

I need to be able to catch all named tuples, I don't know in advance what 
instance of a namedtuple it might be, but I want my function to only accept 
named tuples. Is this unreasonable?

(I am actually writing a C interface which does conversion from namedtuples to 
a form of "RecordSpecification" to do with databases. The namedtuple is 
arbitrarily created by the user.)

--

___
Python tracker 

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

[issue7796] No way to find out if an object is an instance of a namedtuple

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I need to be able to catch all named tuples, I don't know in advance
> what instance of a namedtuple it might be, but I want my function to
> only accept named tuples. Is this unreasonable?

I don't know. Why exactly don't you want to accept something else?
Perhaps the user has their own namedtuple-like class. Or perhaps they're
fine with plain tuples.

--

___
Python tracker 

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

[issue7796] No way to find out if an object is an instance of a namedtuple

[Peter Waller]

Peter Waller  added the comment:

In this case, I need to have names for each object. It is also desirable to use 
the namedtuple because of their lightweight nature.

If they were to subclass the namedtuple I would be happy to accept that, but I 
really do want them to pass some form of namedtuple to me, to have some sort of 
consistency. The named tuple gives an obvious simple interface for determining 
which fields are available and the order they are in.

--

___
Python tracker 

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

[issue7796] No way to find out if an object is an instance of a namedtuple

[betatim]

Changes by betatim :


--
nosy: +thead

___
Python tracker 

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

[issue7796] No way to find out if an object is an instance of a namedtuple

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

It seems a perfect case for "duck typing" style of programming:
All namedtuple classes:
- inherit from tuple
- have a "_fields" class attribute
These two properties could be the "duck test" for namedtuples, regardless of 
the actual implementation.

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Stefan Krah wrote:
> 
> Stefan Krah  added the comment:
> 
> (1) I can get around the configure problem by patching configure.in,
> meaning that va_list is detected correctly now. Perhaps BASECFLAGS
> should be used by default for the compile tests?
> 
> (2) Now I run into the problem that distutils somehow ignores the
> LDFLAGS:
> 
>  
> gcc -pthread -shared 
> build/temp.linux-x86_64-3.2/home/stefan/tmp/svn/py3k/Modules/_struct.o 
> -L/usr/local/lib -o build/lib.linux-x86_64-3.2/_struct.so
> collect2: ld terminated with signal 11 [Segmentation fault]
> 
> 
> 
> So it might be possible to fix the situation by changing configure.in
> and distutils. On the other hand, the patches from Bob and Antoine are
> simpler.

Right, let's go with Antoine's patch and fix the real Makefile
variable problem in some other release - this will require some
major changes to the Makefile and also some changes to distutils.

--

___
Python tracker 

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

[Marc-Andre Lemburg]

Changes by Marc-Andre Lemburg :


--
assignee:  -> pitrou

___
Python tracker 

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

[issue7793] regrtest fails with "RuntimeError: maximum recursion depth exceeded" in some cases

[Florent Xicluna]

Florent Xicluna  added the comment:

Thank you for the patch and the analysis.
It fixes the recursion.

--
stage: test needed -> patch review

___
Python tracker 

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

[issue1225769] Proposal to implement comment rows in csv module

[Skip Montanaro]

Skip Montanaro  added the comment:

Antoine> Since the csv module returns you an iterator, it's easy enough
Antoine> to wrap it in another iterator.

I prefer to do this sort of stuff as a pre-processing step, so I generally
wrap the file object input and use that iterator as the input "file" for the
csv reader.  I'm sure it's largely a matter of taste and what you need to
do.  Certainly wrapping the csv reader's output would be useful to provide
sensible missing values.

Skip

--

___
Python tracker 

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

[issue7610] Cannot use both read and readline method in same ZipExtFile object

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
assignee:  -> pitrou
resolution:  -> accepted
versions: +Python 2.7

___
Python tracker 

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

[issue7765] 'unittest' documentation misprints

[Ezio Melotti]

Ezio Melotti  added the comment:

Fixed in r77796 (trunk) and r77797 (py3k), thanks for the patches!

--
assignee: georg.brandl -> ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue7610] Cannot use both read and readline method in same ZipExtFile object

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The patch has been committed in r77798 (trunk) and r77800 (py3k). Thank you!
I won't commit it to 2.6 and 3.1 because it's too involved to qualify as a bug 
fix, though.

--
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue6939] shadows around the io truncate() semantics

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thank you. The patch was committed mostly unchanged in r77802 (a few cosmetic 
fixes). Now trunk and py3k must absolutely be patched in order to conform to 
the new behaviour. Can you produce a patch for trunk?

--
priority:  -> release blocker
stage:  -> needs patch
versions:  -Python 2.6

___
Python tracker 

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

[issue6939] shadows around the io truncate() semantics

[Antoine Pitrou]

Changes by Antoine Pitrou :


Removed file: http://bugs.python.org/file15931/patch26_largefile_tested.patch

___
Python tracker 

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

[issue7030] Update version{added, changed} entries in py3k unittest docs

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti
priority:  -> normal
stage:  -> needs patch

___
Python tracker 

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

[issue6939] shadows around the io truncate() semantics

[Pascal Chambon]

Pascal Chambon  added the comment:

Thanks a lot B-)
I'll make a patch for trunk from now to this W.E.

--

___
Python tracker 

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

[issue5362] Add configure option to disable Py3k warnings

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review

___
Python tracker 

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

[issue7666] test_lib2to3 fails if path contains space

[Florent Xicluna]

Florent Xicluna  added the comment:

The fix on r77419 do not work.

The patch in attachment behaves better.

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

___
Python tracker 

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

[issue1599329] urllib(2) should allow automatic decoding by charset

[Lino Mastrodomenico]

Changes by Lino Mastrodomenico :


--
nosy: +mastrodomenico

___
Python tracker 

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

[issue4733] Add a "decode to declared encoding" version of urlopen to urllib

[Lino Mastrodomenico]

Changes by Lino Mastrodomenico :


--
nosy: +mastrodomenico

___
Python tracker 

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

[issue7796] No way to find out if an object is an instance of a namedtuple

[Peter Waller]

Peter Waller  added the comment:

Hi Amaury,

Thanks. I had heard of but never bothered to read about duck-typing before now; 
though I have used it passively before. I think it does make sense in this 
case. I can't imagine any case where checking for the _fields attribute would 
fail and isinstance(x, namedtuple) would not.

Besides which, for my current project I am forced to implement such a 
"workaround" anyway, so it doesn't affect me as such.

The only reason that remains why I would want it is that I often use 
isinstance(x, Y) to deal with different Ys, and that was the thing I 
intuitively wanted to use in this case as a python programmer for quite a few 
years now. This is probably a pretty weak reason, so I am happy to close this 
issue if the consensus points to duck typing.

--

___
Python tracker 

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

[issue3367] Uninitialized value read in parsetok.c

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Excellent!

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

[issue7610] Cannot use both read and readline method in same ZipExtFile object

[Ezio Melotti]

Ezio Melotti  added the comment:

Nir, could you also provide a test for the part that "handles unconsumed data" 
(line 601 in zipfile.py)?

In r77809 (and r77810) I made a change to avoid using zlib when it's not 
necessary (zlib is not always available), and I was going to commit a typo that 
luckily I noticed in the diff. The tests however didn't notice anything because 
that part is untested.

--
nosy: +ezio.melotti
stage: committed/rejected -> test needed
status: closed -> open

___
Python tracker 

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

[issue7791] Python 2.6 standard library "sees also" something not in the standard library

[Ezio Melotti]

Ezio Melotti  added the comment:

I removed it in r77814.

--
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue7325] tempfile.mkdtemp() does not return absolute pathname when dir is specified

[Thomas Holmes]

Thomas Holmes  added the comment:

I made a new patch off of the 2.7 trunk version.  I think I have handled some 
of the issues more cleanly.

Please see Py(27)7325.diff

I addressed the issue of using a relative path in the tempdir to achieve the 
'guaranteed' ability to write rather than assuming the location of the python 
executable was writable.

--
Added file: http://bugs.python.org/file16028/Py(27)7325.diff

___
Python tracker 

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

[issue7797] base64 module docs should indicate that encode methods return bytes, not strings

[Justin Lebar]

New submission from Justin Lebar :

It's not at all clear from the documentation that base64.base64encode() and its 
kin return bytes, rather than strings.  Since this matters now, the docs should 
be clear on this point.

http://docs.python.org/3.1/library/base64.html

--
assignee: georg.brandl
components: Documentation
messages: 98458
nosy: Justin.Lebar, georg.brandl
severity: normal
status: open
title: base64 module docs should indicate that encode methods return bytes,  
not strings
type: feature request
versions: Python 3.1

___
Python tracker 

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

[issue7610] Cannot use both read and readline method in same ZipExtFile object

[Nir Aides]

Nir Aides  added the comment:

The related scenario is a system without zlib. How do you suggest simulating 
this in test?

--

___
Python tracker 

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

[issue7610] Cannot use both read and readline method in same ZipExtFile object

[Ezio Melotti]

Ezio Melotti  added the comment:

The test should just check that the part that handles unconsumed data works 
when zlib is available. AFAIU if zlib is not available this part (i.e. the 
content of the if) can be skipped so it doesn't need to be tested.

(When zlib is not available 'zlib' is set to None, see the try/except at the 
beginning of zipfile.py)

--

___
Python tracker 

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

[issue7610] Cannot use both read and readline method in same ZipExtFile object

[Nir Aides]

Nir Aides  added the comment:

Unconsumed data is compressed data. If the part which handles unconsumed data 
does not work when zlib is available, then the existing tests would fail. In 
any case the unconsumed buffer is an implementation detail of zipfile.

I see a point in adding a test to make sure zipfile behaves as expected when 
zlib is not available, but how?

Also, on which systems is zlib missing? I don't see this mentioned in the zlib 
docs.

--

___
Python tracker 

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

[issue7610] Cannot use both read and readline method in same ZipExtFile object

[Ezio Melotti]

Ezio Melotti  added the comment:

> If the part which handles unconsumed data does not work when zlib is 
> available, then the existing tests would fail.

If the existing tests end up testing that part of code too then it's probably 
fine. I tried to add a print inside the 'if' (at line 605) but it didn't print 
anything. However here some tests are skipped, so maybe that part of code is 
tested in some of these skipped tests.

> I see a point in adding a test to make sure zipfile behaves as expected when 
> zlib is not available, but how?

Several tests are already skipped in test_zipfile.py when zlib is not available 
(all the ones with the skipUnless decorator)

> Also, on which systems is zlib missing? I don't see this mentioned in the 
> zlib docs.

Even if it's available and usually already installed in most of the systems, in 
some -- like mine (Linux) -- is not installed.

If you can confirm that that part of code is already tested in some of the 
tests that here are skipped, I will close the issue.

--

___
Python tracker 

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