Neil Muller added the comment:
Updated combined patch for python trunk added (indentation issues
hopefully also fixed).
--
Added file: http://bugs.python.org/file14199/posixmodule_comb.patch
___
Python tracker
<http://bugs.python.org/issue2
Neil Muller added the comment:
Similar patch for the python 3 branch.
--
Added file: http://bugs.python.org/file14200/posixmodule_comb_py3k.patch
___
Python tracker
<http://bugs.python.org/issue2
Neil Muller added the comment:
Patch which includes the given fix and adds a test case to cover this
(test case from Russell Cloran)
--
keywords: +patch
nosy: +Neil Muller
Added file: http://bugs.python.org/file14211/issue-2746.diff
___
Python
Changes by Neil Muller :
--
nosy: +effbot
___
Python tracker
<http://bugs.python.org/issue2746>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Neil Muller :
ElementTree and cElementTree give slightly different results for
repr(Element):
>>> import xml.etree.ElementTree as ET
>>> import xml.etree.cElementTree as cET
>>> repr(ET.ElementTree('tag'))
''
>>> re
Neil Muller added the comment:
Previous patch was missing two lines in the test case. Correct fix uploaded
--
Added file: http://bugs.python.org/file14213/issue-2746.diff
___
Python tracker
<http://bugs.python.org/issue2
New submission from Neil Muller :
In some cases, ElementInclude will not include the tail from the current
node.
Test case and patch against trunk attached (from Simon Cross).
--
components: Library (Lib)
files: ElementInclude.diff
keywords: patch
messages: 89037
nosy: Neil Muller
New submission from Neil Muller :
The test coverage for ElementTree and cElementTree could be improved.
The attached file adds several more tests for ElementTree (including a
number from the ElementTree 1.2.7 pre-release).
This excludes the tests suggested in:
http://bugs.python.org/issue6230
Neil Muller added the comment:
This adds the same tests for cElementTree, disabling them in a few cases
were the behaviour differs.
(Tests include work from Russell Cloran, Jeremy Thurgood, Simon Cross,
Adrianna Pinksa and Graham Poulter)
--
Added file: http://bugs.python.org
Neil Muller added the comment:
Same issue affects python 3k - the patch applies there cleanly as well.
--
___
Python tracker
<http://bugs.python.org/issue6
Neil Muller added the comment:
Same issue affects python 3k. Modified patch (print statement needed
changing) added
--
Added file: http://bugs.python.org/file14220/ElementInclude_py3k.diff
___
Python tracker
<http://bugs.python.org/issue6
Neil Muller added the comment:
Issue also effects p3k. Adapted patch attached.
--
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14221/issue-2746_py3k.diff
___
Python tracker
<http://bugs.python.
Changes by Neil Muller :
Removed file: http://bugs.python.org/file14211/issue-2746.diff
___
Python tracker
<http://bugs.python.org/issue2746>
___
___
Python-bugs-list m
Changes by Neil Muller :
Removed file: http://bugs.python.org/file14213/issue-2746.diff
___
Python tracker
<http://bugs.python.org/issue2746>
___
___
Python-bugs-list m
Neil Muller added the comment:
Previous upload of issue_2746 was corrupt. Fixed version uploaded.
--
Added file: http://bugs.python.org/file14222/issue-2746.diff
___
Python tracker
<http://bugs.python.org/issue2
New submission from Neil Muller :
In py3k, ElementTree no longer correctly converts characters to entities
when they can't be represented in the requested output encoding.
Python 2:
>>> import xml.etree.ElementTree as ET
>>> e = ET.XML("t\xe3t")
>>>
Neil Muller added the comment:
Simple possible patch uploaded
This doesn't give the expected answer for the test above, but does work
when starting from an XML file in utf-8 encoding. I still need to
determine why this happens.
--
keywords: +patch
Added file: http://bugs.pytho
New submission from Neil Muller :
cElementTree will raise a SyntaxError on XML parsing errors, while
ElementTree will raise ExpatError. This makes changing between the two
a bit more problematic than it could be. See for example
https://lists.canonical.com/archives/bazaar/2006q3/017491.html
New submission from Neil Muller :
Consider:
>>> from StringIO import StringIO
>>> source = StringIO('http://éffbot.org/ns";>text')
>>> import xml.etree.ElementTree as ET
>>> events = ("start-ns",)
>>> context = ET.iterp
Neil Muller added the comment:
some additional notes on the tests disabled for cElementTree:
a) cElementTree still reports the last error (bug noted at
http://effbot.python-hosting.com/ticket/30 , although not filed in the
python bug tracker AFAICS).
b) cElementTree uses Syntax error in
Neil Muller added the comment:
> This doesn't give the expected answer for the test above
Which is obviously due to not comparing apples with apples, as I should
be using a byte-string in the py3k example.
>>> import xml.etree.ElementTree as ET
>>> e = ET.XML(b&
Neil Muller added the comment:
Updated patch - adds a test for this.
--
Added file: http://bugs.python.org/file14316/issue6233_py3k_with_test.diff
___
Python tracker
<http://bugs.python.org/issue6
New submission from Neil Crouch :
Unable to convert int to str in idle but from the cmd python prompt it work
sfine.
--
components: IDLE
files: IDLE_err.txt
messages: 106887
nosy: Stranger381
priority: normal
severity: normal
status: open
title: IDLE - str(integer) - TypeError:
New submission from Neil Schemenauer :
It looks like there is a bunch of legacy relative import cruft kicking around
in Python 3. The first thing I noticed is that __import__.__doc__ claims that
level=-1 is the default (i.e. use the Python 2 behavior). A little testing
shows that the docs
Changes by Neil Schemenauer :
--
assignee: -> brett.cannon
nosy: +brett.cannon -nas
___
Python tracker
<http://bugs.python.org/issue9109>
___
___
Python-
Neil Schemenauer added the comment:
I believe the latest problem reported has been fixed by SVN rev 80649.
--
assignee: -> nascheme
nosy: -nas
stage: -> committed/rejected
___
Python tracker
<http://bugs.python.org/
Neil Muller added the comment:
The bug is still present in py3k trunk, the py3k patch still applies, and, as
the bug has celebrated it's first birthday, all evidence suggests no-one else
cares.
--
status: open -> languishing
versions: +Py
Neil Muller added the comment:
Updated version of the patch against current py3k svn (r83022) attached.
This is a combined patch, including the previous xml.sax.saxutil changes
(including the 'short_empty_elements' keyword) and the new tests.
--
nosy: +Neil Muller
Added
New submission from Neil Schemenauer:
test_pydoc is failing for me for 3.6rc1. I build in a sub-directory, e.g.
Python-3.6.0rc1/build-opt. The root of the issue is that pydoc getdocloc() is
broken. It cannot build 'basedir' as it does and assume that is the location
of standa
New submission from Neil Schemenauer:
The getdocloc() method in pydoc.py is supposed to return the doc location for
modules. It uses a 'basedir' parameter that is supposed to point to the
location of the standard library modules.
That logic is broken for a number of different sc
Neil Schemenauer added the comment:
Attached is a first pass at the idea of just keeping a list of standard modules
that have docs. I generated the list with:
$ (cd Doc/library; ls *.rst | sed 's/.rst//')
Probably that should be incorporated into the Doc/Makefile somehow.
Perhaps
Neil Schemenauer added the comment:
This looks to be a good idea and a good time to merge it now the bytecode has
changed to 16-bit. The increase in complexity to compile.c is not bad and
reducing the complexity of the eval loop is worth it, IMHO.
--
nosy: +nascheme
New submission from Neil Schemenauer:
When implementing server software that inherits a socket via a file descriptor,
it is useful to be able to query the descriptor and find out what kind of
socket has been passed. This can be done with getsockopt() and getsockname().
Python does not
Neil Schemenauer added the comment:
Add documentation for new functions.
--
Added file: http://bugs.python.org/file43524/fromfd2.txt
___
Python tracker
<http://bugs.python.org/issue27
Changes by Neil Schemenauer :
Removed file: http://bugs.python.org/file43523/fromfd2.txt
___
Python tracker
<http://bugs.python.org/issue27377>
___
___
Python-bugs-list m
Neil Schemenauer added the comment:
Thank you for the excellent review Martin. I'm attaching a new patch which I
think addresses your points. I created it from hg, maybe that works nicer.
I've added constants for SO_DOMAIN, SO_PROTOCOL, SO_PASSCRED, SO_PEERSEC, and
SO_PASS
Neil Schemenauer added the comment:
I've created a patch to add fromfd2(). I think it addresses the original
concern of this issue. My patch also adds the constants suggested by Issue
#26907.
--
nosy: +nascheme
___
Python tracker
Neil Schemenauer added the comment:
Sorry, forgot to link the patch: Issue #27377.
--
___
Python tracker
<http://bugs.python.org/issue18391>
___
___
Python-bug
Neil Schemenauer added the comment:
Issue #27377 adds these constants.
--
nosy: +nascheme
___
Python tracker
<http://bugs.python.org/issue26907>
___
___
Python-bug
Neil Schemenauer added the comment:
I've revised the patch based on the second round of comments from Martin. I've
removed the ifdef test for CO_TYPE and assumed it is always available. That
means fdtype() should be available on all platforms.
I did not change the test as suggest
Neil Schemenauer added the comment:
Adding yet another revised patch. I think this is ready to commit, if someone
would like to do it. The documentation for constants can be added as a
separate commit, if Martin wants. I think the generic SO_* style documentation
is okay.
Changes in this
Neil Schemenauer added the comment:
I just tested on Windows. fdtype() fails with:
OSError: [WinError 10022] An invalid argument was supplied
The getsockname() call fails with WSAGetLastError() == 10022. getsockname() is
used to find the address family. Perhaps there is some other way to
Neil Schemenauer added the comment:
Updated patch, v5. Disable fdtype() function on Windows. Fix documentation
nits as suggested by review of v4.
--
Added file: http://bugs.python.org/file43722/fromfd2_v5.txt
___
Python tracker
<h
Neil Schemenauer added the comment:
Tested on FreeBSD 10.3. getsockname() on a IPPROTO_SCTP protocol socket
returns errno = FileNoFoundError. We could just comment out that test I guess.
My theory is that on FreeBSD, getsockname() on an SCTP socket fails if it is
not bound. Indeed, adding
Neil Girdhar added the comment:
@gvanrossum is there any reason that subclasshook is implemented by overriding
instead of cooperation? E.g.,:
class Sized(metaclass=ABCMeta):
@classmethod
def __subclasshook__(cls, C):
return (super().__subclasshook__(C) and
Neil Girdhar added the comment:
Great patch. Shouldn't Sequence be a "Reversible, Collection"?
--
___
Python tracker
<http://bugs.python.org/issue27598>
___
_
Neil Girdhar added the comment:
(added the documentation changes)
--
Added file: http://bugs.python.org/file44146/doc_changes.diff
___
Python tracker
<http://bugs.python.org/issue27
New submission from Neil Girdhar:
Both Mapping and Set provide __eq__ and __ne__. Why not have Sequence do the
same?
--
messages: 273114
nosy: neil.g
priority: normal
severity: normal
status: open
title: Add __eq__ and __ne__ to collections.abc.Sequence
Changes by Neil Girdhar :
--
components: +Library (Lib)
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issue27802>
___
___
Python-bugs-list m
Changes by Neil Girdhar :
--
keywords: +patch
Added file: http://bugs.python.org/file44151/abc_eq.diff
___
Python tracker
<http://bugs.python.org/issue27
Neil Girdhar added the comment:
Given issue http://bugs.python.org/issue27802, it might be worth considering
that all Collections implement __eq__ and __ne__, so maybe these should be
abstract methods on Collection?
--
___
Python tracker
<h
Changes by Neil Girdhar :
--
title: Add SizedIterable to collections.abc and typing -> Add Collection to
collections.abc and typing
___
Python tracker
<http://bugs.python.org/issu
Neil Girdhar added the comment:
That's a really good point. Perhaps bring it up on ideas so that it can be
discussed by more people? I don't know what the answer is.
--
___
Python tracker
<http://bugs.python.o
Neil Girdhar added the comment:
(there's already an open thread.)
--
___
Python tracker
<http://bugs.python.org/issue27802>
___
___
Python-bugs-list m
Neil Girdhar added the comment:
(never mind about the comparison operators :) Turns out that would break
backwards compatibility.)
--
___
Python tracker
<http://bugs.python.org/issue27
New submission from Neil Hodgson:
On Windows, non-equal comparisons (<, <=, >, >=) between strings with common
prefixes are slower in Python 3.3 than 3.2. This is for both 32-bit and 64-bit
builds. Performance on Linux has not decreased for the same code. The attached
p
Neil Hodgson added the comment:
The common cases are likely to be 1:1, 2:2, and 1:2. There is already a
specialisation for 1:1. wmemcmp is widely available but is based on wchar_t so
is for different widths on Windows and Unix. On Windows it would handle the 2:2
case
Neil Hodgson added the comment:
For 32-bits whether wchar_t is signed shouldn't matter as Unicode is only
21-bits so no character will be seen as negative. On Windows, wchar_t is
unsigned.
C11 has char16_t and char32_t which are both unsigned but it doesn't include
comparison
Neil Hodgson added the comment:
For 32-bit Windows, the code generated for unicode_compare is quite slow.
There are either 1 or 2 kind checks in each call to PyUnicode_READ and 2
calls to PyUnicode_READ inside the loop. A compiler may decide to move the kind
checks out of the loop and
Neil Hodgson added the comment:
Looking at the assembler output from gcc 4.7 on Linux shows that it specialises
the loop 9 times - once for each pair of kinds. This is why there was far less
slow-down on Linux.
Explicitly writing out the 9 loops is inelegant and would make accurate
Neil Hodgson added the comment:
The patch fixes the performance regression on Windows. The 1:1 case is better
than either 3.2.4 or 3.3.1 downloads from python.org. Other cases are close to
3.2.4, losing at most around 2%. Measurements from 32-bit builds:
## Download 3.2.4
3.2.4 (default, Apr
Neil Hodgson added the comment:
A quick rewrite showed the single level case slightly faster (1%) on average
but its less readable/maintainable. Perhaps taking a systematic approach to
naming would allow Py_UCS1 to be deduced from PyUnicode_1BYTE_KIND and so avoid
repeating the information in
Neil Hodgson added the comment:
Including the wmemcmp patch did not improve the times on MSC v.1600 32 bit - if
anything, the performance was a little slower for the test I used:
a=['C:/Users/Neil/Documents/λ','C:/Users/Neil/Documents/η']156
specialised:
[0.9125948707773204
Neil Hodgson added the comment:
Windows is the only widely used OS that has a 16-bit wchar_t. I can't recall
what OS/2 did but Python doesn't support OS/2 any more.
--
___
Python tracker
<http://bugs.python.o
Neil Girdhar added the comment:
Updated the patch for 3.5.
Currently, building fails with
TypeError: init_builtin() takes exactly 1 argument (0 given)
This is probably due to an argument counting bug, but I am not sure how to
debug it.
--
nosy: +neil.g
Added file: http
Neil Girdhar added the comment:
Hi Chris. It might be hard to notice, but you're seeing the same build failure.
Looking at the patch-to-patch differences, I didn't see anything out of the
ordinary. My patch file includes more surrounding lines, dates, and is against
a different
Changes by Neil Girdhar :
Added file: http://bugs.python.org/file37788/starunpack4.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
Changes by Neil Girdhar :
Removed file: http://bugs.python.org/file37787/starunpack4.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
Neil Girdhar added the comment:
Yup, that's it. So two problems down:
It has yet to be updated to the most recent Python version
It features a now redundant replacement for "yield from" which should be removed
I'm working on:
It also loses support for calling function wi
Neil Girdhar added the comment:
Yes, thank you! That explained it. I am almost done fixing this patch.
Here's my progress so far if you want to try it out. Just one test left to fix.
--
Added file: http://bugs.python.org/file37790/starunpack5
Neil Girdhar added the comment:
All tests pass for me! Would anyone be kind enough to do a code review?
--
Added file: http://bugs.python.org/file37791/starunpack6.diff
___
Python tracker
<http://bugs.python.org/issue2
Changes by Neil Girdhar :
Added file: http://bugs.python.org/file37792/starunpack6.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
Neil Girdhar added the comment:
Thanks. It's probably compile.c under "/* Same dance again for keyword
arguments */". nseen remains zero and probably shouldn't. I need to learn
more about the opcodes.
--
___
P
Neil Girdhar added the comment:
Post it? It's just "hg diff > a.diff"
--
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Pytho
Neil Girdhar added the comment:
I think there will still be a problem ceval with the way the dicts are combined
unfortunately, but that should be easy to fix.
--
___
Python tracker
<http://bugs.python.org/issue2
Neil Girdhar added the comment:
Thanks!
I've incorporated your changes to deal with the [*[0] for i in [0]] problem,
although I don't understand them yet.
The problem with using STORE_MAP is you create a new dict for each keyword
argument in that situation. I optimized that a
Neil Girdhar added the comment:
Why is that correct? The PEP mentions overriding. Right now each dict
overrides values from the last silently, which I think makes sense. The
keyword arguments you pass in override keys from previous dicts (also good I
think). The problem is that you can
Neil Girdhar added the comment:
That makes sense.
If you wanted to override, you could always write:
f(**{**a, **b, 'x': 5})
rather than
f(**a, **b, x=5)
Should I go ahead and fix it so that overriding is always wrong? E.g.,
f(**{'x': 3}, **{'x
Neil Girdhar added the comment:
Could you try this and tell me how many BUILD_MAPs you're doing?
dis.dis("def f(w, x, y, z, r): pass\nf(w=1, **{'x': 2}, y=3, z=4, r=5)")
Mine does 2.
--
___
Python tracker
<http
Neil Girdhar added the comment:
If there is a speed issue, the real answer I think is to add an opcode as
suggested in the source code that coalesces keyword arguments into dicts rather
than "the weird dance" as the previous authors described it, or turning each
argument into an
Neil Girdhar added the comment:
Ah, nice! I didn't realize what STORE_MAP did. I thought it created a map
each time. We'll just do it your way.
--
___
Python tracker
<http://bugs.python.
Neil Girdhar added the comment:
Detecting overrides and raising TypeError. E.g.,
>>> def f(x, y):
... print(x, y)
...
>>> f(x=5, **{'x': 3}, y=2)
Traceback (most recent call last):
...
TypeError: f() got multiple va
Neil Girdhar added the comment:
Added many tests, six of which fail. Started work on grammar to fix new tests.
--
Added file: http://bugs.python.org/file37805/starunpack11.diff
___
Python tracker
<http://bugs.python.org/issue2
Neil Girdhar added the comment:
Very nice! So what's left besides errors?
* Fixing the grammar, ast, and compilation for the list, dict, and set
comprehension element unpackings
> Now the primary problem is giving good errors; I don't know how to make them
> look like th
Neil Girdhar added the comment:
Oh, I see. For BUILD_MAP_UNPACK we don't want to raise on duplicate dict
comprehension element unpackings, right? Maybe we should add a different
opcode, or else a flag to the opcodes, or else use the top bit of the length
parameter? What do you
Neil Girdhar added the comment:
I am a huge fan of giving good errors. Looks good to me. Will we need to make
sure that the call helper function we worked on produces additional
BUILD_MAP_UNPACK opcodes every 256 dictionaries just in case
Neil Girdhar added the comment:
Another option to consider is to just use a bit on the BUILD_MAP_UNPACK and
then have a stack marking opcode at the function call (not sure what to call
it, but say FUNCTION_CALL_MARK)
The advantage would be you don't store or calculate relative stack posi
Neil Girdhar added the comment:
I see your point: if there are 255 dictionaries, there's no room for neither
preceding keyword arguments nor positional arguments. Okay, then I like your
solution.
--
___
Python tracker
<http://bugs.py
Neil Girdhar added the comment:
Also maybe not in this changelist, but we should consider replacing STORE_MAP
and BUILD_MAP with a single opcode BUILD_MAP(n) that produces a dict out of the
top n items on the stack just like BUILD_LIST(n) does. What do you think
Neil Girdhar added the comment:
You're right.
--
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list mailing list
Unsubscr
Neil Girdhar added the comment:
BUILD_MAP(n)
--
Added file: http://bugs.python.org/file37817/starunpack14.diff
___
Python tracker
<http://bugs.python.org/issue2
Changes by Neil Girdhar :
Added file: http://bugs.python.org/file37821/starunpack14.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
Changes by Neil Girdhar :
Removed file: http://bugs.python.org/file37817/starunpack14.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
Neil Girdhar added the comment:
By the way, Joshua if you wanted to edit the text of the PEP, it might be nice
to point out that this replaces itertools.chain.from_iterable. I know you
mention one use of itertools.chain, but I think this nicely replaces all uses
of both:
itertools.chain(a, b
Neil Girdhar added the comment:
In that case, another option would be to use that to send the "number of maps"
to CALL_FUNCTION and let it do the BUILD_MAP_UNPACK stuff itself. Would that
simplify your ideas regarding error handling?
--
Neil Girdhar added the comment:
Sorry, I don't know enough about how you were planning on using the stack
pointer difference to produce good errors. I thought that if you waited for
the CALL_FUNCTION to be happening before reporting errors about duplicate
parameters it might simplify
Neil Girdhar added the comment:
Okay, I didn't realize it was so simple to raise the error from somewhere else.
Regarding "duplicate the (large) dictionary merging function" — of course we
would just factor it out into a function.
--
___
Neil Girdhar added the comment:
That's true. But wouldn't the offset always be one (or three or whatever)
since if we do BUILD_MAP_UNPACK in a function call it's always right before
CALL_FUNCTION?
--
___
Python tracker
<http
Neil Girdhar added the comment:
What do you mean by the stack will "have the function"? At the point that
you're doing BUILD_MAP_UNPACK, CALL_FUNCTION hasn't been executed…
--
___
Python tracker
<http://bu
Neil Girdhar added the comment:
when does that get pushed on the stack?
--
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list mailin
501 - 600 of 674 matches
Mail list logo
