[issue5088] optparse: inconsistent default value for append actions

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Note, the :attr:`~Option.dest` variable is a list which includes default
values if any are defined.  Options on the command-line are appended to
this list.  Accordingly, the list may contain both the default value and
the value passed on the command-line.

--
nosy: +rhettinger

___
Python tracker 

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

[issue10594] Typo in PyList_New doc.

[Raymond Hettinger]

Raymond Hettinger  added the comment:

This is fine.  Go ahead and backport if you feel so inclined.

--
assignee: d...@python -> eli.bendersky
nosy: +rhettinger
priority: normal -> low
resolution:  -> accepted
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

[issue10592] pprint module doesn't work well with OrderedDicts

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I'll discuss with Benjamin.  This could be construed as a simple bug fix.  The 
code is already in Py3.1.

Line 155:
- items = _sorted(object.items())
+ items = (list if issubclass(typ, OrderedDict) else _sorted)(object.items())

--
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson, rhettinger
stage: committed/rejected -> 

___
Python tracker 

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

[issue10592] pprint module doesn't work well with OrderedDicts

[Elias Zamaria]

Elias Zamaria  added the comment:

I forgot to mention, someone came up with this suggestion 
(http://stackoverflow.com/questions/4301069/any-way-to-properly-pretty-print-ordered-dictionaries-in-python/4303996#4303996).
 It is not the best, but the output is better than how it is now. Can it be 
somehow integrated into the PrettyPrinter.format method?

--
resolution: duplicate -> 
status: closed -> open

___
Python tracker 

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

[issue10594] Typo in PyList_New doc.

[INADA Naoki]

INADA Naoki  added the comment:

OK, please.

On Wed, Dec 1, 2010 at 12:46 PM, Eli Bendersky  wrote:
>
> Eli Bendersky  added the comment:
>
> Thanks for the report,
>
> Attaching a patch for Doc/c-api/list.rst in Python 3.2
> If this is OK, I can backport the patch to other versions as well.
>
> --
> keywords: +patch
> nosy: +eli.bendersky
> Added file: http://bugs.python.org/file19889/issue10594.py32.1.patch
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue5088] optparse: inconsistent default value for append actions

[Eli Bendersky]

Eli Bendersky  added the comment:

Éric, also re your previous message, I personally would prefer seeing "contrary 
to what one can think" removed altogether. IMHO it's too chatty for an official 
document and doesn't really add new information over the sentence it follows.

--

___
Python tracker 

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

[issue5088] optparse: inconsistent default value for append actions

[Eli Bendersky]

Eli Bendersky  added the comment:

I fuzzily recall there was somewhere a decision to use the American spelling of 
some words, like s/behaviour/behavior/ appearing in this patch. Is this right, 
or was it decided that it doesn't matter?

--
nosy: +eli.bendersky
status: pending -> open

___
Python tracker 

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

[issue10594] Typo in PyList_New doc.

[Eli Bendersky]

Eli Bendersky  added the comment:

Thanks for the report,

Attaching a patch for Doc/c-api/list.rst in Python 3.2
If this is OK, I can backport the patch to other versions as well.

--
keywords: +patch
nosy: +eli.bendersky
Added file: http://bugs.python.org/file19889/issue10594.py32.1.patch

___
Python tracker 

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

[issue10593] LRU Cache with maxsize=None

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Applied in r86911.

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

[issue10594] Typo in PyList_New doc.

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti

___
Python tracker 

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

[issue10594] Typo in PyList_New doc.

[INADA Naoki]

INADA Naoki  added the comment:

http://docs.python.org/c-api/list.html#PyList_GetItem
> Return the object at position pos in the list pointed to by p
s/pos/index/

--

___
Python tracker 

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

[issue10594] Typo in PyList_New doc.

[INADA Naoki]

INADA Naoki  added the comment:

http://docs.python.org/c-api/list.html#PyList_GetItem
> Return the object at position pos in the list pointed to by p
s/p/list/

--

___
Python tracker 

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

[issue10594] Typo in PyList_New doc.

[INADA Naoki]

New submission from INADA Naoki :

http://docs.python.org/c-api/list.html#PyList_New
> Note: If length is greater than zero, ...

s/length/len/

--
assignee: d...@python
components: Documentation
messages: 122974
nosy: d...@python, naoki
priority: normal
severity: normal
status: open
title: Typo in PyList_New doc.
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue3243] Support iterable bodies in httplib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> just to confirm: we WANT array.array("I", [1,2,3]) to have a content-
> length of 12, right?

Yes, since it will emit 12 bytes in the body (you could actually have a test 
for it).

--

___
Python tracker 

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

[issue6594] json C serializer performance tied to structure depth on some systems

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Raymond, I'll follow up in private with Shawn. All the recent performance 
improvements done on JSON (in 3.2) mean the issue can be closed IMO.

--
resolution:  -> out of date
status: open -> closed

___
Python tracker 

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

[issue10273] Clean-up Unittest API

[Ezio Melotti]

Ezio Melotti  added the comment:

s/regexp/regex/ done in r86910.

--
resolution:  -> fixed
stage:  -> 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

[issue3243] Support iterable bodies in httplib

[Xuanji Li]

Xuanji Li  added the comment:

So, reading all your comments, I gather that my proposed patch for client.py 
which is

  try:
  self.sock.sendall(data)
  except TypeError:
  if isinstance(data, collections.Iterable):
  for d in t:
  self.sock.sendall(d)
  else:
  raise TypeError("data should be a bytes-like object or an iterable, 
got %r" % type(it))

is ok, because it avoids using hasattr to test for Iterable and avoids 
isinstance() to check for specific types (str, bytes...) but instead uses 
exceptions (as pitrou suggested)?

if that is ok with everyone, I just need to work more on request.py to remove 
the hasattr; I'll probably use the memoryview solution suggested by pitrou.

just to confirm: we WANT array.array("I", [1,2,3]) to have a content-length of 
12, right?

--

___
Python tracker 

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

[issue10593] LRU Cache with maxsize=None

[Nick Coghlan]

Nick Coghlan  added the comment:

Nice!

You may still need to use the lock even for the simple unbounded case though - 
incrementing hits and misses isn't atomic, so the statistics may be miscounted 
if you get a hit or miss in different threads at the same time.

Alternatively, we could just document the hit/miss statistics as approximate 
figures for tuning purposes rather than guaranteeing 100% accuracy in all 
situations.

--

___
Python tracker 

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

[issue7434] general pprint rewrite

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Attaching a rough concept of how to make the existing pprint module extendible 
without doing a total rewrite.  The actual handler is currently bogus (no 
thought out), so focus on the @guard decorator and the technique for scanning 
for handlers.

--
Added file: http://bugs.python.org/file19888/rdh_pprint.py

___
Python tracker 

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

[issue10593] LRU Cache with maxsize=None

[Raymond Hettinger]

Changes by Raymond Hettinger :


Removed file: http://bugs.python.org/file19886/cache.diff

___
Python tracker 

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

[issue10593] LRU Cache with maxsize=None

[Raymond Hettinger]

Changes by Raymond Hettinger :


Added file: http://bugs.python.org/file19887/cache2.diff

___
Python tracker 

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

[issue10593] LRU Cache with maxsize=None

[Raymond Hettinger]

New submission from Raymond Hettinger :

Nick, I may have found a straight-forward way to incorporate your idea for the 
cache to support maxsize=None.  Let me know what you think.

--
assignee: ncoghlan
components: Library (Lib)
files: cache.diff
keywords: patch
messages: 122967
nosy: ncoghlan, rhettinger
priority: low
severity: normal
status: open
title: LRU Cache with maxsize=None
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19886/cache.diff

___
Python tracker 

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

[issue10535] Enable warnings by default in unittest

[Ezio Melotti]

Ezio Melotti  added the comment:

Committed in r86908. I'll leave this open because there still a few things 
(proposed in the previous message) that can be changed/improved.

--

___
Python tracker 

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

[issue10592] pprint module doesn't work well with OrderedDicts

[Éric Araujo]

Éric Araujo  added the comment:

I’m afraid there is no way, but a robust solution will be designed.  See #7434.

--
nosy: +eric.araujo
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> general pprint rewrite

___
Python tracker 

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

[issue1649329] Extract file-finding and language-handling code from gettext.find

[Éric Araujo]

Éric Araujo  added the comment:

Congratulations.  Take the time you’ll need, if this doesn’t go into 3.2 it’ll 
just be in 3.3.

--

___
Python tracker 

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

[issue10592] pprint module doesn't work well with OrderedDicts

[Elias Zamaria]

New submission from Elias Zamaria :

If I try to pretty-print an ordered dictionary, it doesn't show nicely. Instead 
of having each key-value pair on its own line, the whole thing shows up on one 
long line, which wraps many times and is hard to read.

I can provide an example if you want.

Is there a way to make it print nicely, like the old unordered dictionaries?

--
components: Library (Lib)
messages: 122963
nosy: mikez302
priority: normal
severity: normal
status: open
title: pprint module doesn't work well with OrderedDicts
type: behavior
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

[issue8743] set() operators don't work with collections.Set instances

[Raymond Hettinger]

Raymond Hettinger  added the comment:

No need to rush this for the beta.  It's a bug fix and can go in at any time.  
The important thing is that we don't break the C code.  The __ror__ magic 
method would still need to do the right thing and the C code needs to defend 
against the interpreter swapping self and other.

--

___
Python tracker 

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

[issue8743] set() operators don't work with collections.Set instances

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

Yes, I can take a stab at it.

--

___
Python tracker 

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

[issue10591] test_os failure in refleak runs

[Brian Curtin]

Brian Curtin  added the comment:

Fixed in r86906. Split the shared setUp/tearDown into individual methods for 
each part.

--
resolution:  -> fixed
stage:  -> 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

[issue8743] set() operators don't work with collections.Set instances

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Daniel, do you have time to work on this one?

If so, go ahead an make setobject.c accept any instance of collections.Set and 
make the corresponding change to the ABCs:

def __or__(self, other):
if not isinstance(other, Set):
return NotImplemented
chain = (e for s in (self, other) for e in s)
return self._from_iterable(chain)

The code in the attached prelim.patch has working C code isinstance(x, 
collections.Set), but the rest of the patch that applies is has not been 
tested.  It needs to be applied very carefully and thoughtfully because:
* internally, the self and other can get swapped on a binary call
* we can't make *any* assumptions about "other" (that duplicates have actually 
been eliminated or the the elements are even hashable).

The most reliable thing to do for the case where PyAnySet(obj) is False but 
isinstance(obj, collections.Set) is true is to call the named method such as 
s.union(other) instead of continuing with s.__or__ which was designed only with 
real sets in mind.

--
assignee: rhettinger -> stutzbach

___
Python tracker 

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

[issue6594] json C serializer performance tied to structure depth on some systems

[Shawn]

Shawn  added the comment:

I specifically mentioned *SPARC* as the performance problem area, but the reply 
about "0.5s to dump" fails to mention on what platform they tested

My problem is not "undiagnosable".  I'll be happy to provide you with even more 
data files.  But I believe that there is a problem here on some architectures 
for reasons other than those of simple differences in single-threaded 
performance that could be accounted to processor architecture.

As an example of something that makes a noticeable difference on SPARC systems 
I've checked:

178 # could accelerate with writelines in some versions of Python, at
179 # a debuggability cost
180 for chunk in iterable:
181 fp.write(chunk)

Changing that to use writelines() is a significant win.  You go from over a 
million calls to write (for small bits as simple as a single character such as 
'{') to one single call to writelines() with an iterable.

The recursive call structure of the json code also adds significant overhead on 
some architectures.

What's "undiagnosable" here is the response to the issue I reported -- it 
provides no information about the platform that was tested or how the testing 
was done.

My testing was done by reading the attached file using json, and then timing 
the results of writing it back out (to /tmp mind you, which is memory-backed on 
my OS platform, so no disk I/O was involved, I've also checked writing to a 
cStringIO object).

--

___
Python tracker 

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

[issue8425] a -= b should be fast if a is a small set and b is a large set

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Any new logic should make maximum use of existing tools:

def __isub__(self, other)
if len(other) > len(self)*8:
other = self & other
. . .
# rest of isub unchanged

--
stage: patch review -> needs patch

___
Python tracker 

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

[issue6594] json C serializer performance tied to structure depth on some systems

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Antoine, what do you want to do with the one?  Without a good test case the 
OP's original issue is undiagnosable.

--
assignee: rhettinger -> pitrou
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

[issue6422] timeit called from within Python should allow autoranging

[Raymond Hettinger]

Raymond Hettinger  added the comment:

This does not conflict with the other proposed changes to timeit and it is 
in-line with Guido's desire that to expose useful parts currently buried in the 
command-line logic.

Amaury, you've shown an interest.  Would you like to apply it?

--
assignee: rhettinger -> amaury.forgeotdarc
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

[issue8425] a -= b should be fast if a is a small set and b is a large set

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Deferring to 3.3.

--
priority: normal -> low
versions: +Python 3.3 -Python 2.7, Python 3.2

___
Python tracker 

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

[issue1649329] Extract file-finding and language-handling code from gettext.find

[Shannon -jj Behrens]

Shannon -jj Behrens  added the comment:

Sorry, I just had a baby on Saturday.  Hence, I'm a bit late getting to this.  
It might take me a couple weeks.

--

___
Python tracker 

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

[issue10478] Ctrl-C locks up the interpreter

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +stutzbach

___
Python tracker 

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

[issue10589] I/O ABC docs should specify which methods have implementations

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Other suggestions for a better name for that column are certainly welcome. :-)
> 
> "Stub Methods"?

Fine with me.

--

___
Python tracker 

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

[issue10589] I/O ABC docs should specify which methods have implementations

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

Other suggestions for a better name for that column are certainly welcome. :-)

"Stub Methods"?

--

___
Python tracker 

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

[issue10464] netrc module not parsing passwords containing #s.

[Ned Deily]

Changes by Ned Deily :


Removed file: http://bugs.python.org/file19666/issue_10231_testcase.diff

___
Python tracker 

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

[issue10464] netrc module not parsing passwords containing #s.

[Ned Deily]

Ned Deily  added the comment:

Patch looks good to me. Supplied test fails before and works after fix applied.

--
nosy: +ned.deily
stage: patch review -> commit review

___
Python tracker 

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

[issue10589] I/O ABC docs should specify which methods have implementations

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> > What does "unsupported" mean? "Abstract" would look more exact.
> 
> It means they raise io.UnsupportedOperation when called (unless the
> subclass overrides them to do something else).  
> 
> They are not marked with @abstractmethod, so "Abstract" would be
> wrong.

Except that "unsupported" is even more wrong, because it makes it look
like that these methods are not supported by the respective ABCs.
Actually, what happens is that the default implementations are stubs. If
those methods weren't "supported" at all they wouldn't be defined in the
first place.

--

___
Python tracker 

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

[issue10589] I/O ABC docs should specify which methods have implementations

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

> What does "unsupported" mean? "Abstract" would look more exact.

It means they raise io.UnsupportedOperation when called (unless the subclass 
overrides them to do something else).  

They are not marked with @abstractmethod, so "Abstract" would be wrong.

It should be a bit more clear in context.  Here's a link to the point in the 
documentation where the table would fit:
http://docs.python.org/dev/py3k/library/io.html#class-hierarchy

The most relevant bit is: "implementations are allowed to raise 
UnsupportedOperation if they do not support a given operation."

> E.g. "readinto" is listed as provided by RawIOBase in the doc text.

The doc text describes the API.  That is, it describes what the readinto method 
should do if a subclass of RawIOBase decides to implement it.  The existing 
text doesn't contain any clues as to which methods contain useful 
implementations versus which will raise io.UnsupportedOperation if not 
overridden.  Hence the need for the table.

--

___
Python tracker 

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

[issue10262] Add --soabi option to `configure`

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Let's test Linux at least, then.

--

___
Python tracker 

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

[issue10262] Add --soabi option to `configure`

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

On Nov 30, 2010, at 10:12 PM, Amaury Forgeot d'Arc wrote:

>The value of get_config_var("SO") is the same as before, something like
>".cpython-32.so" by default on Linux. (see, I just moved the line
>SO=.$SOABI$SO at the bottom of the patch).

Cool, thanks.

>In the C file dynload_shlib.c, I chose the names SO_BASE for the "simple"
>extension (.so) and SO_EXTRA for the "decorated" extension (.cpython-32.so)

Since I used SOABI earlier, what do you think about SOBASE and SOEXTRA for
consistency?

>Is there a way to write unit tests for all this? This would prove that the
>default behavior is the same as before.

It would, but I couldn't think of a way to do that reliably across platform.

--

___
Python tracker 

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

[issue10591] test_os failure in refleak runs

[Antoine Pitrou]

New submission from Antoine Pitrou :

$ ./python -m test.regrtest -R 3:2 test_os
[1/1] test_os
[35351 refs]
[35351 refs]
[35352 refs]
beginning 5 repetitions
12345
[35351 refs]
[35351 refs]
[35352 refs]
test test_os failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_os.py", line 898, in 
test_unicode_name
self._test_link(self.file1, self.file2)
  File "/home/antoine/py3k/__svn__/Lib/test/test_os.py", line 879, in _test_link
os.link(file1, file2)
OSError: [Errno 17] File exists

--
assignee: brian.curtin
components: Tests
messages: 122945
nosy: brian.curtin, pitrou
priority: normal
severity: normal
status: open
title: test_os failure in refleak runs
type: resource usage
versions: Python 3.2

___
Python tracker 

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

[issue10589] I/O ABC docs should specify which methods have implementations

[Georg Brandl]

Georg Brandl  added the comment:

Not sure what "unsupported methods" means.  E.g. "readinto" is listed as 
provided by RawIOBase in the doc text.

--

___
Python tracker 

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

[issue10589] I/O ABC docs should specify which methods have implementations

[Antoine Pitrou]

Antoine Pitrou  added the comment:

What does "unsupported" mean? "Abstract" would look more exact.

--

___
Python tracker 

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

[issue8685] set(range(100000)).difference(set()) is slow

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Modified patch committed in r86905. Thanks!

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

[issue10589] I/O ABC docs should specify which methods have implementations

[Fred L. Drake, Jr.]

Changes by Fred L. Drake, Jr. :


--
nosy: +d...@python, fdrake

___
Python tracker 

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

[issue9915] speeding up sorting with a key

[Raymond Hettinger]

Raymond Hettinger  added the comment:

+1 on the basic idea of moving elements in the keys and values arrays at the 
same time thereby eliminating the fragmented memory overhead of the sortwrapper 
indirection.

I would like the patch to be restricted to just that change.  The other tweaks 
are not convincing (relying on compiler and processor specific optimizations 
that vary across platforms).  Instead, try to minimize the patch, making as few 
changes as possible to manipulation both arrays.  Also, try to follow the C 
style of the other code in the standard library -- the current patch has a 
different flavor to say the least ;-)

Ideally, the code will have the same look and feel as it does now (so that the 
Timsort remains recognizable to Tim ;-).  This code doesn't just need to run 
fast, it needs to serve as a readable model for anyone else trying to implement 
the algorithm.

If you still want the other tweaks, I recommend putting them in a separate 
patch afterwards and consider deferring them to 3.3.  It's a little late in the 
dev cycle to make lots of microscopic changes that may introduce a bug or 
unexpected behavior or perform weirdly on one of the less used platforms.

--

___
Python tracker 

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

[issue10589] I/O ABC docs should specify which methods have implementations

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

+io and doc people

Attached is a simple patch to add a table to the documentation summarizing the 
I/O ABCs.

--
keywords: +patch
nosy: +benjamin.peterson, ezio.melotti, georg.brandl
Added file: http://bugs.python.org/file19885/io-abc.diff

___
Python tracker 

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

[issue10262] Add --soabi option to `configure`

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

The value of get_config_var("SO") is the same as before, something like 
".cpython-32.so" by default on Linux. (see, I just moved the line SO=.$SOABI$SO 
at the bottom of the patch).

In the C file dynload_shlib.c, I chose the names SO_BASE for the "simple" 
extension (.so) and SO_EXTRA for the "decorated" extension (.cpython-32.so)

Is there a way to write unit tests for all this? This would prove that the 
default behavior is the same as before.

--

___
Python tracker 

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

[issue10262] Add --soabi option to `configure`

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

Of course, you don't change configure directly, you change configure.in and let 
autoconf update the configure (but you already know that I'm sure :).

The patch looks fairly reasonable, though I haven't tried it.  One question: 
does $SO have the same value after your patch as before?  That's a variable 
available via sysconfig and it looks like you're removing a block of code that 
sets it.

--

___
Python tracker 

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

[issue8685] set(range(100000)).difference(set()) is slow

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thx.

--
assignee: rhettinger -> pitrou
resolution:  -> accepted

___
Python tracker 

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

[issue8685] set(range(100000)).difference(set()) is slow

[Philip Jenvey]

Changes by Philip Jenvey :


--
nosy: +pjenvey

___
Python tracker 

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

[issue8685] set(range(100000)).difference(set()) is slow

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Raymond, unless you object, I'd like to commit this before beta1.

--

___
Python tracker 

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

[issue8084] pep-0370 on osx duplicates existing functionality

[Glyph Lefkowitz]

Glyph Lefkowitz  added the comment:

Would it be possible to have this reverted for 2.7.2 / 3.2.1, and restore 
~/.local _and_ ~/Library as equally valid locations for python code?

As I tried to explain on the mailing list, this change basically introduces a 
regression, and nothing else.  Sorry I did not comment on the ticket at the 
time.

Previously it was possible to maintain a single "~/.pydistutils.cfg" for 
UNIX-like OSes, which would allow 'python setup.py install', 'pip install' and 
'easy_install' to function without adding a 'sudo' in front of them, or any 
command-line options.  This is important since easy_install doesn't expose a 
'--user'.  Now, there needs to be a specific, separate config file for OS X 
installs.

Also, it was previously possible to pass a sane value for '--prefix', but now 
there is no such value.  This makes it much more difficult to, for example:

  cd my-c-dependency
  ./configure --prefix ~/.local
  cd my-python-project
  python setup.py install --prefix ~/.local

since Python code with C dependencies will sometimes attempt to discover the 
location of include files and the like via the install prefix.

'setup.py install --user' (the only remaining installation mechanism which 
actually works out of the box on a mac) will now place scripts into 
~/Library/Python/x.y/bin, which seems a singularly unhelpful location.  Again, 
if there are C and Python programs which interact, I now need 2 locations on my 
$PATH instead of one.

I don't understand what this change buys anyone.  If you're treating the Mac 
python as a UNIX-like environment, it just spuriously breaks things.  But if 
you're treating it as a Mac-like environment (i.e. not using a terminal), the 
right place to put your Python code is _inside a (framework or application) 
bundle_, not lying around your home directory.

Also, if there is interest in properly honoring Mac filesystem conventions, 
there are APIs for doing that, as documented here: 
.
  Manually enumerating the user domain while ignoring, for example, the network 
domain, seems half-hearted and arbitrary.

--
nosy: +glyph

___
Python tracker 

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

[issue7830] Flatten nested functools.partial

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

The original motivation for the patch was that if partial() objects are 
guaranteed to be flat, it would simplify code that deals with them.  See 
issue4331 for one example.

With a "conservative" patch, however, it will still be possible to create 
nested partials and the code consuming partials should be ready for that.

--
keywords:  -needs review
resolution:  -> rejected
stage: commit 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

[issue10590] Parameter type error for xml.sax.parseString(string, ...)

[Thomas Ryan]

New submission from Thomas Ryan :

In 3.1.3, 3.1.2, maybe earlier...

xml.sax.parseString(string, handler, error_handler=handler.ErrorHandler())

Source code requires bytes, not a string as implied by function name and by the 
documentation.

Exception thrown for strings.

Since the name includes "string" the source should probably be fixed.
Or at least update the documentation.

Someday replace/augment parseString() with parseBytes()?

--
components: XML
messages: 122933
nosy: Thomas.Ryan
priority: normal
severity: normal
status: open
title: Parameter type error for xml.sax.parseString(string, ...)
type: behavior
versions: Python 3.3

___
Python tracker 

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

[issue7830] Flatten nested functools.partial

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Alexander, I don't see anything wrong with patch, nor anything compelling about 
it either.   It's your choice whether or not to apply.

--

___
Python tracker 

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

[issue10587] Document the meaning of str methods

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Tue, Nov 30, 2010 at 1:53 PM, Martin v. Löwis  wrote:
..
> What is the issue that you are reporting? that the status quo should be 
> documented, or that isalpha is wrong?
> These are independent - don't mix them.

This is a documentation issue.  I don't say that str.isalpha() is
necessarily wrong.  (If unicodedata had an isAlphabetic() menthod
defined as Lu + Ll + Lt + Lm + Lo, I would file a bug report for
that.)   Here, I just want to mention that proper str.isalpha()
definition is subject to debate and it being defined as Lu + Ll + Lt +
Lm + Lo may need to be marked as CPython implementation detail.  Note
that the Unicode book (sorry, don't have the page reference) advises
not to rely on catch-all APIs such as isAlphabetic(), but consult the
underlying properties directly.  I tend to agree with that because
some programs may want to treat say Roman numerals as letters and some
as numbers, so whether isAlphabetic() should include Nl category is
better left to the application.

--

___
Python tracker 

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

[issue10589] I/O ABC docs should specify which methods have implementations

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +pitrou

___
Python tracker 

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

[issue10589] I/O ABC docs should specify which methods have implementations

[Daniel Stutzbach]

New submission from Daniel Stutzbach :

The I/O ABC documentation has a blanket disclaimer at the top:

"The abstract base classes also provide default implementations of some 
methods in order to help implementation of concrete stream classes. For 
example, BufferedIOBase provides unoptimized implementations of readinto() and 
readline()."

Which effectively means that to subclass one of them requires digging into 
Lib/_pyio.py to figure out which methods provide useful implementations.

It would be handy to have a table, similar to the one for the collections ABCs 
[1], that spells out which methods are provided.

[1]: 
http://docs.python.org/py3k/library/collections.html#abcs-abstract-base-classes

I hope to have a patch ready sometime within the next week.

--
assignee: stutzbach
components: Documentation
messages: 122930
nosy: stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: I/O ABC docs should specify which methods have implementations
type: feature request
versions: Python 3.2

___
Python tracker 

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

[issue1170] shlex have problems with parsing unicode

[Martin v . Löwis]

Martin v. Löwis  added the comment:

The key requirement to consider for in POSIX compatible mode is, well, POSIX 
compatibility, which is defined in

http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_03

Now, POSIX declares that what  is depends on LC_CTYPE (character class 
blank). I'd argue that if the objective is to behave exactly like the shell, it 
really should be doing that (i.e. work in a locale-aware manner).

--

___
Python tracker 

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

[issue10551] mimetypes read from the registry should not overwrite standard mime mappings

[Kovid Goyal]

Kovid Goyal  added the comment:

I actually had in mind people that (like me) develop primarily on unix and 
assume that mimetypes works the same way on both windows and unix. Of course, 
the changed behavior is also a concern.

At the very least, I would encourage the addition of a warning to the 
documentation of the mimetypes module.

--
status: pending -> open

___
Python tracker 

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

[issue10587] Document the meaning of str methods

[Martin v . Löwis]

Martin v. Löwis  added the comment:

What is the issue that you are reporting? that the status quo should be 
documented, or that isalpha is wrong? These are independent - don't mix them.

--
nosy: +loewis

___
Python tracker 

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

[issue10551] mimetypes read from the registry should not overwrite standard mime mappings

[R. David Murray]

R. David Murray  added the comment:

I would expect that it would not be people new to mimetypes that would have the 
issues, but people like you for whom the behavior on Windows has changed.  And 
this is indeed a concern.

The people involved in making the windows mimetypes enhancement are nosy on 
this ticket, perhaps they will have thoughts on the issue of the (in)validity 
of the windows mime data.

--
status: closed -> pending

___
Python tracker 

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

[issue10551] mimetypes read from the registry should not overwrite standard mime mappings

[Kovid Goyal]

Kovid Goyal  added the comment:

It is, of course, your decision, but IMO, since the mimetypes database in 
windows appears to be always broken, the default behavior of the mimetypes 
module in python 2.7 on windows is broken for most (all?) windows installs. For 
me personally, it doesn't matter anymore, as I have already fixed calibre, but 
it would be surprising/unexpected behavior for someone new to using 
mimetypes.py on windows. Certainly, my expectation (perhaps naively) was that 
guess_type('image.jpg') would always return 'image/jpeg'. 

Users on windows rarely (ever?) modify the registry to change mimetypes. The 
only thing that does change mimetypes is installed software, without the users' 
knowledge/consent. So treating the registry as a reliable store of mime 
information, is not a good idea. 

On unix, the knownfiles are system files. I dont know about OS X, but on linux, 
since most software is installed by package managers, the package managers 
usually have policies that prevent application installs from clobbering system 
files. And of course, running userland applications dont have the necessary 
privileges to modify the files. 

Out of curiosity, what is the upside of reading mimetypes from the registry, 
given that it's information cannot be trusted?

And you're most welcome, for calibre :)

--

___
Python tracker 

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

[issue10551] mimetypes read from the registry should not overwrite standard mime mappings

[R. David Murray]

R. David Murray  added the comment:

Kovid: so essentially what you are saying is that the windows platform is 
broken with respect to MIME types and with respect to its security model.  Why 
am I not surprised? :)

You would have the same problem if software installation altered the 
/etc/mimetypes file on a unix box and created weird entries.  Perhaps unix 
programmers are just better disciplined?

Reading the registry first and having the built in settings override would IMO 
defeat the purpose of reading the values from the registry: those are 
(theoretically!!) the settings the user chose to change.

However, working around it in your program should be simple: just call 
mimetypes.init with an empty file list.  The windows registry is only read if 
the files parameter is None.  This will also give you consistent behavior on 
windows and unix: only the default mime types in the mimetypes module will be 
used.  If, on the other hand, you want to retain the Unix behavior, you can 
pass init mimetypes.knownfiles instead of the empty list.

(By they way, thanks very much for calibre, I have used the CLI tools to great 
benefit, and love the fact that the CLI is the basis of the program.)

--
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

___
Python tracker 

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

[issue9598] untabify.py fails on files that contain non-ascii characters

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Committed revision 86893 that makes untabify.py respect encoding cookie in the 
files it processes.  I don't think there is anything else that needs to be done 
here.

--
resolution:  -> fixed
stage:  -> 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

[issue1706039] Added clearerr() to clear EOF state

[Scott Dial]

Scott Dial  added the comment:

The patch includes unittests; the issue is that the tests pass without the 
changes. That is an entirely different state to be in. The tests should be 
committed unless somebody wants to object to the behavior that they are testing 
(although I believe this behavior is already codified in documentation). If the 
tests start failing on someone's platform, then you have a patch already 
waiting to be applied. Nevertheless, I don't see the harm in the patch as-is, 
because it is a quite innocuous change to Py_UniversalNewlineFgets(), unless 
(again) you want to argue about the correctness of that change despite no test 
failing.

--

___
Python tracker 

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

[issue3243] Support iterable bodies in httplib

[Éric Araujo]

Éric Araujo  added the comment:

> hasattr("lol", '__next__') == False, even though strings are Iterable

FYI, magic methods are looked up on the class, not on the instance.  That’s why 
ABCs are the right thing to use here.  
http://docs.python.org/dev/reference/datamodel#special-method-names

--

___
Python tracker 

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

[issue1706039] Added clearerr() to clear EOF state

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I don't know how to reproduce the issue and without unit tests this patch 
cannot be committed.

--
assignee: belopolsky -> 

___
Python tracker 

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

[issue1170] shlex have problems with parsing unicode

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Adding #10587 because we need to figure out the exact meaning of str.isspace() 
etc. first.  It is possible that for proper operation shlex should consult 
unicodedata directly.

--
dependencies: +Document the meaning of str methods

___
Python tracker 

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

[issue10574] email.header.decode_header fails if the string contains multiple directives

[R. David Murray]

R. David Murray  added the comment:

Note that none of your examples are valid encoded words, so given that email 
currently does strict parsing, the fact that it is not attempting to decode 
those words is technically correct.  

However, I agree that it would be better for it to do a "best guess" decoding 
of the invalid encoded words.

It should be possible to "fix" this case by simply replacing '?==?' with '?= 
=?' before decoding (blanks between encoded words are ignored when decoding, 
per the RFC, which the author of the package producing these invalid headers 
probably didn't realize).

See also #1079 and #8132.

I have to think about whether or not all of these can be considered fixes 
(based on Postel's law) or if tolerant parsing should be considered a feature 
request.  I'll probably combine these into a single issue at some point.

Out of curiosity, which email program is it that is producing these invalid 
headers?

--
assignee:  -> r.david.murray
nosy: +r.david.murray

___
Python tracker 

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

[issue6280] calendar.timegm() belongs in time module, next to time.gmtime()

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I am going to close this as "rejected" unless someone objects.  The benefit is 
too small to make users suffer through the deprecation process.

--
resolution:  -> rejected
status: open -> pending

___
Python tracker 

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

[issue10552] Tools/unicode/gencodec.py error

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Committed in revision 86891.  Keeping open to address Mac issue.

--
assignee:  -> belopolsky
components: +Macintosh
priority: normal -> low
stage: commit review -> needs patch

___
Python tracker 

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

[issue1079] decode_header does not follow RFC 2047

[R. David Murray]

Changes by R. David Murray :


--
assignee:  -> r.david.murray

___
Python tracker 

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

[issue3243] Support iterable bodies in httplib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Answering to myself, sorry. memoryview() does return the right answer of 
whether the object supports the buffer interface, *however* it doesn't mean the 
len() will be right. For example, take an array.array of ints:

>>> memoryview(array.array("I", [1,2,3]))

>>> len(array.array("I", [1,2,3]))
3
>>> len(memoryview(array.array("I", [1,2,3])))
3
>>> len(bytes(array.array("I", [1,2,3])))
12

len() returns 3 but the number of bytes written out by sendall() will really be 
12...

*However*, the right len can be calculated using the memoryview:

>>> m = memoryview(array.array("I", [1,2,3]))
>>> len(m) * m.itemsize
12

(without actually converting to a bytes object, so all this is cheap even for 
very large buffers)

--

___
Python tracker 

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

[issue10576] Add a progress callback to gcmodule

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

> How about a string and a dict?  the string can be "start" and "stop"
> and we can add interesting information to the dict as you suggest.

I like where this is headed.  How about putting the string in the dict, too?

d['phase'] = 'start'

--

___
Python tracker 

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

[issue10576] Add a progress callback to gcmodule

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> You are right, Antoine.
> How about a string and a dict?  the string can be "start" and "stop"
> and we can add interesting information to the dict as you suggest.

Looks good to me.

--

___
Python tracker 

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

[issue3243] Support iterable bodies in httplib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> - Lets have the ValueError raised from the urllib/request.py. Changing
> it to isinstance(data,collections.Iterable) as Antoine suggested is
> okay here too.

Xuanji is right: it's not. We want bytes to be accepted, and it's an
iterable.

--

___
Python tracker 

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

[issue3243] Support iterable bodies in httplib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

One way to check that it's bytes-compatible is to take a memoryview of it:

>>> memoryview(b"abc")

>>> memoryview(bytearray(b"abc"))

>>> memoryview(array.array('b', b"abc"))


>>> memoryview([b"abc"])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: cannot make memory view because object does not have the buffer 
interface
>>> memoryview("abc")
Traceback (most recent call last):
  File "", line 1, in 
TypeError: cannot make memory view because object does not have the buffer 
interface

--

___
Python tracker 

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

[issue3243] Support iterable bodies in httplib

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Xuanji, a wording which does convey the approximate meaning is fine. I think, 
the Exception error messages will help the people based on the Context.

- Lets have the ValueError raised from the urllib/request.py. Changing it to 
isinstance(data,collections.Iterable) as Antoine suggested is okay here too.
- Same change for http.client code checking for an Iterable as specified in 
msg122905

tests are fine. Docs and NEWS should be updated.

Georg: Is it okay, if we push this feature in before Dec 4th, beta1 release?

--
nosy: +georg.brandl

___
Python tracker 

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

[issue3243] Support iterable bodies in httplib

[Xuanji Li]

Xuanji Li  added the comment:

davide: yeah, hasattr("lol", '__next__') == False, even though strings are 
Iterable; so for strings and other such sequences the len(data) line will be 
executed. So technically we shouldn't say "No Content-Length specified for 
iterable body" but we should say "No Content-Length specified for iterable body 
that is not a sequence". 

Basically, this whole patch (both parts of it) will be much better off iif 
there is a clean way to say "a is an iterable but a is not a sequence", because 
even though b'this is a message' is Iterable, we want to treat it differently 
compared to, say, a generator object; we do NOT want to use the Iterator 
features (iter, next) of it, we want to use the sequencey features (by sending 
the whole chunk of it, by calling len)

--

___
Python tracker 

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

[issue9873] urllib.parse: Allow bytes in some APIs that use string literals internally

[Nick Coghlan]

Nick Coghlan  added the comment:

Committed in r86889

The docs changes should soon be live at:
http://docs.python.org/dev/library/urllib.parse.html

If anyone would like to suggest changes to the wording of the docs for post 
beta1, or finds additional corner cases that the new bytes handling can't cope 
with, feel free to create a new issue.

--
resolution:  -> accepted
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

[issue3243] Support iterable bodies in httplib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> > len(data) will raise anyway.
> 
> No, it won't, if the iterable happens to be a sequence.

Well, it seems the patch is confused between iterable and iterator. Only
iterators have a __next__, but they usually don't have a __len__.

The patch should really check for iterables, so it should use:

if isinstance(data, collections.Iterable)
raise ValueError#etc.

--

___
Python tracker 

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

[issue3243] Support iterable bodies in httplib

[Davide Rizzo]

Davide Rizzo  added the comment:

> len(data) will raise anyway.

No, it won't, if the iterable happens to be a sequence.

--
nosy: +davide.rizzo

___
Python tracker 

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

[issue10588] imp.find_module raises unexpected SyntaxError

[Ron Adam]

Changes by Ron Adam :


--
nosy: +ron_adam

___
Python tracker 

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

[issue3243] Support iterable bodies in httplib

[Xuanji Li]

Xuanji Li  added the comment:

I don't fully understand Lib/urllib/request.py either, I just ported it and ran 
the unittests... it seems like what it does is that if you send an iterator 
through as 'data' you can't know the length in advance, and rather than let the 
len(data) raise an exception catlee thought it's better to raise an exception 
to tell the user exactly why the code failed (ie, because the user sent an 
iterator and there's no way to meaningfully find the Content-Length of that).

As for the catching exceptions vs using isinstance: I thought about it for a 
while, I think something like this feels right to me:

  try:
  self.sock.sendall(data)
  except TypeError:

  if isinstance(data, collections.Iterable):
  for d in t:
  self.sock.sendall(d)
  else:
  raise TypeError("data should be a bytes-like object or an iterable, 
got %r" % type(it))


anyway, calling iter(data) is equivalent to calling data.__iter__(), so 
catching the exception is equivalent to hasattr(data, '__iter__'), which is 
roughly the same as isinstance(data, collections.Iterable). so we try the most 
straightforward method (sending everything) then if that fails, data is either 
an iterator or a wrong type.

--

___
Python tracker 

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

[issue3243] Support iterable bodies in httplib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> pitrou: actually that seems a bit suspect now... you need to handle
> 'data' differently depending on its type,

Yes, but you can't know all appropriate types in advance, so it's better
to try and catch the TypeError.

I don't understand your changes in Lib/urllib/request.py. len(data) will
raise anyway.

--

___
Python tracker 

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

[issue10576] Add a progress callback to gcmodule

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

You are right, Antoine.
How about a string and a dict?  the string can be "start" and "stop" and we can 
add interesting information to the dict as you suggest.

--

___
Python tracker 

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

[issue10576] Add a progress callback to gcmodule

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Let's start bikeshedding the calling signature.  I like having a
> single callback, since multiple callables are a nuisance to manage.

IMO the callback should have a second argument as a dict containing
various statistics that we can expand over time. The generation number,
for example, should be present.

As for the phase number, if 0 means start and 1 means end, you can't
decently add another phase anyway (having 2 mean "somewhere between 0
and 1" would be completely confusing).

PS : please don't use C++-style comments in your patch

--

___
Python tracker 

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

[issue10576] Add a progress callback to gcmodule

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Hi, as I stated, the original patch was simply our original implementation.
Here is a new patch.  It is simpler:
1) it exposes a gc.callbacks list where users can register themselves, in the 
spirit of sys.meta_path
2) One can have multiple callbacks
3) Improve error handling
4) The callback is called with a "phase" argument, currently 0 for start, and 1 
for the end.

Let's start bikeshedding the calling signature.  I like having a single 
callback, since multiple callables are a nuisance to manage.

Once we agree, I'll post a patch for the documentation, and unittests.

--
Added file: http://bugs.python.org/file19884/gccallback2.patch

___
Python tracker 

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

[issue10464] netrc module not parsing passwords containing #s.

[Xuanji Li]

Xuanji Li  added the comment:

bumping...can someone review this? The reported bug seems valid enough.

--

___
Python tracker 

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

[issue10537] OS X IDLE 2.7rc1 from 64-bit installer hangs when you paste something.

[Ned Deily]

Ned Deily  added the comment:

More data points: using the 2.7.1 release source tarball, the problem is 
reproducible on 10.6 when dynamically linked to the Apple Tcl/Tk 8.5 and 
executing in either 64-bit or 32-bit mode.  It is not reproducible when using 
ActiveState Tcl/Tk 8.5.9, AS Tcl/Tk 8.4.19, or Apple Tcl/Tk 8.4 (none of which, 
of course, is available in 64-bit mode).

Unfortunately, the obvious workaround for the 64-bit/32-bit variant - building 
with one of the working 32-bit versions - does not result in a working IDLE.app 
or bin/idle since IDLE and its subprocesses are all launched in 64-bit mode 
(where possible) on 10.6.  For testing, it is possible to demonstrate 32-bit 
mode in a 64-/32- build with a properly built _tkinter.so by using the -n 
parameter, which causes IDLE to run with no subprocesses:
   arch -i386 /usr/local/bin/idle2.7 -n

Next step: see if the Issue6075 patches help with the Apple 8.5 Tk and, if not, 
add stuff to force both IDLE.app and bin/idle and their subprocesses to run 
only in 32-bit mode: probably either some more lipo-ing and/or adding 
posix_spawns.

--

___
Python tracker 

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

[issue3243] Support iterable bodies in httplib

[Xuanji Li]

Xuanji Li  added the comment:

pitrou: actually that seems a bit suspect now... you need to handle 'data' 
differently depending on its type, and while you can determine the type by 
finding out when 'data' throws certain exceptions, it doesn't seem like what 
exceptions were meant for.

--

___
Python tracker 

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

[issue9709] test_distutils warning: initfunc exported twice on Windows

[Stefan Krah]

Stefan Krah  added the comment:

Without the patch, you see the warning if test_build_ext is run in
verbose mode. With the patch, the warning disappears.

--

___
Python tracker 

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

[issue10588] imp.find_module raises unexpected SyntaxError

[Emile Anclin]

New submission from Emile Anclin :

Considering following file: 
$ cat pylint/test/input/func_unknown_encoding.py 
# -*- coding: IBO-8859-1 -*-
""" check correct unknown encoding declaration
"""

__revision__ = ''
$

When we try to find that module, imp.find_module raises SyntaxError:

>>> from imp import find_module
>>> find_module('func_unknown_encoding', None)
Traceback (most recent call last):
  File "", line 1, in 
SyntaxError: encoding problem: with BOM

It should be considered as a bug, as stated by  Brett Cannon:

> Considering these semantics changed between Python 2 and 3 w/o a
> discernable benefit (I would consider it a negative as finding a
> module should not be impacted by syntactic correctness; the full act
> of importing should be the only thing that cares about that), I would
> consider it a bug that should be filed.

--
messages: 122896
nosy: emile.anclin
priority: normal
severity: normal
status: open
title: imp.find_module raises unexpected SyntaxError
type: behavior
versions: Python 3.2

___
Python tracker 

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