Eli Bendersky added the comment:
> Can you explain what use case it tries to cover?
What I'm trying to say is that although I think I understand its effect (if the
same sub-interpreter re-imports _elementtree bypassing the Python module cache,
this is an additional level of caching),
Eli Bendersky added the comment:
On Thu, Aug 8, 2013 at 7:00 AM, Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
> > This code in the beginning in PyInit__elementtree:
> >
> > m = PyState_FindModule(&elementtreemodule);
> >
Eli Bendersky added the comment:
On Thu, Aug 8, 2013 at 7:14 AM, Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
> > Would you mind removing it from the patch, due to the case described
> > above?
> > ISTM that in real scenarios the sys.modules cache kic
Eli Bendersky added the comment:
> It's easy to say that as a core developer with commit rights who > can
> simply hide changes in a low frequented bug tracker without
> notifying those who have to know about these changes. It's pure > luck
> I noticed this cha
Eli Bendersky added the comment:
On Fri, Aug 9, 2013 at 8:44 AM, Stefan Behnel wrote:
>
> Stefan Behnel added the comment:
>
> > ask to be added to the experts list for ET
>
> Already done, see the corresponding python-dev thread.
Eli Bendersky added the comment:
On Fri, Aug 9, 2013 at 12:34 PM, Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
> > Can we agree on discarding the current implementation for now and then
> > rewriting it based on a tree builder instead of a parser wr
Changes by Eli Bendersky :
--
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Eli Bendersky added the comment:
Antoine, I committed your patch (with a bit of comments added), *leaving the
module caching in*. This is because removing it breaks the tests,
unfortunately. The _elementtree tests are so crooked that they manage to create
a situation in which the module under
Eli Bendersky added the comment:
Less than two days passed since this issue was opened. No waiting for feedback?
No patch? No code review?
Maybe there's another solution? Personally I find dir() often more useful than
help(). Maybe help() can be adapted to behave nicely for classes
Eli Bendersky added the comment:
On Sat, Aug 10, 2013 at 10:38 AM, Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
> > Antoine, I committed your patch (with a bit of comments added),
> > *leaving the module caching in*.
>
> Thanks!
>
> > A long
Eli Bendersky added the comment:
Found some problems in the interaction of PEP 3121 and import_fresh_module:
http://mail.python.org/pipermail/python-dev/2013-August/127862.html
I'd still like to see the in-PyInit__elementtree caching deleted eventually,
without harming test coverage. So
Eli Bendersky added the comment:
BTW, Antoine, w.r.t documentation - I agree that the whole PyState_* sequence
needs better documentation and examples, but in the meantime I'm attaching a
simple patch for c-api/module.rst. It clarifies that PyState_AddModule doesn't
really have to
Changes by Eli Bendersky :
Added file: http://bugs.python.org/file31226/pystate-findmodule-clarify.1.patch
___
Python tracker
<http://bugs.python.org/issue15651>
___
___
Eli Bendersky added the comment:
Ethan, as Ned said (and I think you got this answer in the list before), the
real feature cutoff is Beta 1. So we have time until the end of November. Note
that even new PEPs (like the statistics one) can go in before that. Even after
beta, things that appear
Eli Bendersky added the comment:
I was planning to look more closely at the namespace support in ET at some
point, but haven't found the time yet.
[changing the title to be more helpful]
--
title: ElementTree gets awkward to use if there is an xmlns -> ElementTree --
provide
Eli Bendersky added the comment:
> (although, admittedly, sometimes it's those who designed the XML format
who didn't understand >namespaces ...).
I fully concur. The design of XML, in general, is not the best
demonstration of aesthetics in programming. But namespaces always
Eli Bendersky added the comment:
Chris, I was reading through regrtest.py for other reasons and stumbled upon
the pointer to this issue. Would you like to update your patch? I will review
it.
--
nosy: +eli.bendersky
___
Python tracker
<h
Eli Bendersky added the comment:
Ethan, please revert your commit first. I liked the previous dir. The current
one is useless.
I think you may be right about help, but I didn't dig deep enough to be sure.
--
___
Python tracker
Eli Bendersky added the comment:
The patched code looks better than the original one in several respects, but I
think it raises some questions.
I agree with Victor that the type-checking API is unnatural, but I also think
there may be a deeper issue hiding behind. You felt compelled to add
Eli Bendersky added the comment:
> Previously, the only way to add a dialect was through register_dialect
that does
> > type checking to make sure it gets a legit dialect object. Now, the
> _dialects dict is
> > directly accessible to Python code and it can add arbitrary obj
Eli Bendersky added the comment:
On Mon, Aug 12, 2013 at 12:41 PM, Serhiy Storchaka
wrote:
>
> Serhiy Storchaka added the comment:
>
> Here is a preliminary patch which get rids of
> _convert_namespace_to_getopt() and directly uses a Namespace object.
> Unfortunately it br
Eli Bendersky added the comment:
On Mon, Aug 12, 2013 at 1:33 PM, Eli Bendersky wrote:
>
> Eli Bendersky added the comment:
>
> On Mon, Aug 12, 2013 at 12:41 PM, Serhiy Storchaka
> wrote:
>
> >
> > Serhiy Storchaka added the comment:
> >
> > Her
New submission from Eli Bendersky:
As part of original plan and since issue #18264 has been resolved, it's time to
dust off some old patches I have for the socket.* module. The socket.AF_* and
socket.SOCK_* constants are good candidates for IntEnum conversion.
I'm attaching an ini
Eli Bendersky added the comment:
Attaching updated patch answering Ethan's review. Also added a tiny sanity test
that makes sure that AF_INET is indeed an enum. A more comprehensive test
probably won't hurt for the final patch.
--
Added file: http://bugs.python.org/file31
Eli Bendersky added the comment:
> I'm not really thrilled by the current implementation. The way it is done
> leads to duplication among socket constants.
Can you clarify which duplication you mean specifically? In the code review
tool, Serhiy proposed that instead of listing all th
Eli Bendersky added the comment:
> What about SOCK_STREAM, SOCK_DGRAM, and SOCK_RAW?
>
This is a proof of concept. As I mentioned in the original message starting
this issue - the SOCK_* constants will get the same treatment as AF_*
constants, once we decide what the right treatm
Eli Bendersky added the comment:
Attaching a new patch that uses Serhiy's suggestion to avoid the duplication,
and uses Antoine's suggestion to keep socket.family working even if the family
is an unknown numeric constant.
Note that the latter is challenging to test - I need famil
Eli Bendersky added the comment:
On Wed, Aug 14, 2013 at 6:24 AM, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
> I'm surprised that test_repr is not failed. '%i' %
> socket.AddressFamily.AF_INET returns 'AddressFamily.AF_INET' inste
Eli Bendersky added the comment:
In Objects/unicodeobject.c when it gets into mainformatlong, an IntEnum is
recognized as an integer (passes PyLong_Check) and goes into formatlong. There,
in the cases of 'd', 'i', 'u' it has:
case 'u':
Eli Bendersky added the comment:
Christian, this is an interesting idea - but I suggest we review it once we
actually get to convert "many modules". For the time being the manual listing
is gone in the recent patch, and for a number of constant families in the same
module (i.e. S
Eli Bendersky added the comment:
> I thing the AddressFamily enum class and the family property should be
> documented.
>
I'm leaving the documentation to the end when we decide on the
implementation strategy. Once that happens I'll post a patch wit
Eli Bendersky added the comment:
Ethan, str.format uses __format__. We don't seem to provide a custom one.
--
___
Python tracker
<http://bugs.python.org/is
Eli Bendersky added the comment:
On Wed, Aug 14, 2013 at 6:55 AM, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
> `.format()` is surprised too.
>
> >>> '{:}'.format(AF.IPv4)
> 'AF.IPv4'
> >>> '{:10}'.fo
Changes by Eli Bendersky :
--
title: % formatting incomplete for Enum -> String formatting (% and str.format)
issues with Enum
___
Python tracker
<http://bugs.python.org/issu
Eli Bendersky added the comment:
On Wed, Aug 14, 2013 at 11:48 AM, Ethan Furman wrote:
>
> Ethan Furman added the comment:
>
> > Eric V. Smith added the comment:
> >
> > For the format version, what gets called is:
> >
> > int_subclass.__format__(&#x
Eli Bendersky added the comment:
On Wed, Aug 14, 2013 at 11:56 AM, Eric V. Smith wrote:
>
> Eric V. Smith added the comment:
>
> For format, I think the question is "should an IntEnum format like an int,
> with the wacky exception of a specifier of '', or should
Eli Bendersky added the comment:
On Wed, Aug 14, 2013 at 12:07 PM, Ethan Furman wrote:
>
> Ethan Furman added the comment:
>
> > Eric V. Smith added the comment:
> >
> > I assumed we'd want it to look like the str() version of itself, always.
> But it's
Eli Bendersky added the comment:
>
> Okay, I see your points. I can certainly agree with going with the str
> representation when no numeric code is specified. But, if a numeric code
> is specified (x, b, d, etc.) then the numeric value should be used.
>
> Agreed?
>
Yes
Eli Bendersky added the comment:
On Wed, Aug 14, 2013 at 2:38 PM, Eric V. Smith wrote:
>
> Eric V. Smith added the comment:
>
> > So what you're saying is that '{:}' is empty, but '{:10}' is not?
>
> Yes, exactly. The part before the colon says w
Eli Bendersky added the comment:
The whole point of IntEnum and replacing stdlib constants with it was friendly
str & repr out of the box. This means that "just printing out" an enum member
should have a nice string representation. And "just printing out" means:
pri
Eli Bendersky added the comment:
On Thu, Aug 15, 2013 at 3:20 PM, Eric V. Smith wrote:
>
> Eric V. Smith added the comment:
>
> On 8/15/2013 5:46 PM, Eli Bendersky wrote:
> > The whole point of IntEnum and replacing stdlib constants with it was
> friendly str & repr o
Eli Bendersky added the comment:
I guess there are merits to keeping it all in the same place.
--
___
Python tracker
<http://bugs.python.org/issue18738>
___
___
Eli Bendersky added the comment:
Great catch, Charles-François, thanks. It's actually an interesting example in
favor of the approach - it's very nice to see descriptive family names in the
data returned by getaddrinfo, instead of obtuse numeric values.
The attached patch fix
Eli Bendersky added the comment:
Looks nice:
>>> for t in socket.getaddrinfo('www.google.com', 'http'):
... t
...
(, 1, 6, '', ('74.125.239.112', 80))
(, 2, 17, '', ('74.125.239.112', 80))
(, 1, 6,
Eli Bendersky added the comment:
Looks pretty good, Serhiy. I left some comments in Rietveld.
--
___
Python tracker
<http://bugs.python.org/issue16799>
___
___
Eli Bendersky added the comment:
Charles-François: unfortunately, the alternative seems to be even more tedious
and error prone. Internally, socketmodule.c really uses ints all over the
place. Changing that to use IntEnum objects from Python would be very tedious
and touch a lot more code
Eli Bendersky added the comment:
On Wed, Aug 21, 2013 at 6:40 AM, Eric V. Smith wrote:
>
> Eric V. Smith added the comment:
>
> I agree splitting this makes sense, so as to not delay the %-formatting
> fix. While similar in principle, the fixes are unrelated. We may as well
&g
Eli Bendersky added the comment:
Serhiy, if you feel this is related to #18780 maybe they can be merged into a
single issue (since the comment on #18780 says the fix here will work there
too)?
--
___
Python tracker
<http://bugs.python.
Eli Bendersky added the comment:
I like the idea of having .events() in a special target passed to a XMLParser,
which already has feed() and close(). I read through Stefan's proposal and
there are a couple of issues I wanted to raise:
1. Why have the "event builder" wrap a tree
Eli Bendersky added the comment:
Looking at this more, the Parser/Builder abstraction in ET leaks badly,
especially when it comes to incremental parsing. This manifests in (at least)
two ways:
1. The parser accepted by iterparse has to use the ET-provided TreeBuilder,
because the C
Eli Bendersky added the comment:
Thanks for the effort, Stefan, but I still think IncrementalParser is worth
keeping. It provides functionality that doesn't currently exist in ET, and IMHO
this functionality is both important and useful.
Renaming its methods to feed & close kill
Eli Bendersky added the comment:
> Stefan Behnel added the comment:
>
> > I still think IncrementalParser is worth keeping.
>
> If you want to keep it at all cost, I think we should at least hide it
> behind a function (as with iterparse()). If it's implemented as a
Eli Bendersky added the comment:
Stefan, I don't mind looking at a working patch; however, it's not clear to me
how you intend to solve the iterparse-accepting-a-custom-XMLParser problem. As
for faking the new API, I don't know if that's a good idea because we're no
Eli Bendersky added the comment:
> > As for faking the new API, I don't know if that's a good idea because
> we're not yet sure what that new API is.
>
> If that's your concern, then I suggest not adding the feature at all, as
> long as we don&#x
Eli Bendersky added the comment:
I actually have another idea. Since we all agree that passing a custom "parser"
to iterparse is dubious, IncrementalParser does not have to do that at all.
This will make it a much more future-proof API. So its signature can be
Eli Bendersky added the comment:
Serhiy, patch 5 addresses your latest review. Thanks. As for _family_converter,
let's see how common this really becomes. Based on one use-case I wouldn't add
it to Enum itself. But if we see it gets repeated in many places, we can.
--
Added
Eli Bendersky added the comment:
I had a chat with Nick about this, and a variation of the proposal in
http://bugs.python.org/msg196133 seems acceptable to us both. To summarize,
here's what goes into 3.4.
* The class will be named EventParser.
Rationale: The Incremental in IncrementalP
Eli Bendersky added the comment:
On Sun, Aug 25, 2013 at 10:40 PM, Stefan Behnel wrote:
>
> Stefan Behnel added the comment:
>
> Hmm, did you look at my last comment at all? It solves both the technical
> issues and the API issues very nicely and avoids any problems of pot
Eli Bendersky added the comment:
>
> (I still wonder why I'm the one writing all the patches here when Eli is
> the one who actually wants this feature ...)
>
Well, obviously because you're the only real programmer around here and the
rest of us are just a bunch of hand-w
Eli Bendersky added the comment:
Aaron - could you describe your use case of passing a custom parser into
iterparse? We're currently considering deprecating the feature of passing a
parser into iterparse in a future release (this is being discussed in issue
Eli Bendersky added the comment:
On Mon, Aug 26, 2013 at 7:11 PM, Aaron Oakley wrote:
>
> Aaron Oakley added the comment:
>
> >From memory, the use case at the time was using a custom TreeBuilder
> sub-class fed into a builtin XMLParser object. The code would construct a
&g
Eli Bendersky added the comment:
On Mon, Aug 26, 2013 at 12:35 PM, Stefan Behnel wrote:
>
> Stefan Behnel added the comment:
>
> Here is a proof-of-concept patch that integrates the functionality of the
> IncrementalParser into the XMLParser. I ended up reusing most of Antoines
&
Eli Bendersky added the comment:
I'm sorry if I sound offensive, but most of what I read as counter
> arguments in this ticket so far was either incomplete or (sometimes) even
> plain wrong. Some seemed pretty close to FUD, but maybe that's just me (and
> I'm guilty here
Eli Bendersky added the comment:
W.r.t. the summary in http://bugs.python.org/msg196177, after some further chat
with Nick, a name that sounds good for us for the class is XMLPullParser. It
has both XML and Parser in it, so the intention is clear. On the other hand,
Pull works well for
Eli Bendersky added the comment:
This patch implements the renaming and updates the documentation.
--
Added file: http://bugs.python.org/file31497/issue17741.api-renames.1.patch
___
Python tracker
<http://bugs.python.org/issue17
Eli Bendersky added the comment:
lgtm
--
___
Python tracker
<http://bugs.python.org/issue18760>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eli Bendersky added the comment:
lgtm
--
___
Python tracker
<http://bugs.python.org/issue18780>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eli Bendersky added the comment:
This issue has become too large and discusses a few different things; hence I'm
inclined to close it as fixed and open a new one as a placeholder for
discussing the new design of the internals.
I'll do this in a couple of days if there are no
Eli Bendersky added the comment:
[Thanks, Guido]
Attaching patch with SOCK_* constants converted as well. The module globals are
currently walked twice, once to extract AF_* and once SOCK_*. This is not a
real performance problem, but should we fold it into a single loop that
collects two
Eli Bendersky added the comment:
The idea looks reasonable. Posted a code review.
--
___
Python tracker
<http://bugs.python.org/issue18738>
___
___
Python-bug
Eli Bendersky added the comment:
On Sat, Aug 31, 2013 at 3:18 PM, Ethan Furman wrote:
>
> Ethan Furman added the comment:
>
> Eli Bendersky added the comment:
> >
> > Another issue is _intenum_converter. Ethan - do you think it belongs in
> the enum module as a help
Eli Bendersky added the comment:
lgtm
--
___
Python tracker
<http://bugs.python.org/issue18738>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eli Bendersky added the comment:
What Serhiy said.
--
resolution: -> wont fix
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Eli Bendersky added the comment:
lgtm
--
___
Python tracker
<http://bugs.python.org/issue18745>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eli Bendersky added the comment:
Can this be transformed into a new issue that succinctly summarizes what the
new requested feature is, and why it's useful?
--
___
Python tracker
<http://bugs.python.org/is
Eli Bendersky added the comment:
Do we have enough evidence to open a new bug vs. help() ?
--
___
Python tracker
<http://bugs.python.org/issue18693>
___
___
Pytho
New submission from Eli Bendersky:
As issue #17741 shows in detail, there's a number of implementation problems in
the current ET that make a fully non-blocking parser more difficult to
implement than it should be.
The main problem is that XMLParser._setevents relies on int
Eli Bendersky added the comment:
I'm closing this issue as fixed because the feature was implemented. As
discussed, opened a new issue (#18902) to discuss re-designing some parts of
the current code that would allow a nicer implementation of this feature.
Anyone interested in the su
Eli Bendersky added the comment:
On Sun, Sep 1, 2013 at 5:29 PM, Ethan Furman wrote:
>
> Ethan Furman added the comment:
>
> I've done some more investigation today but I can't tell if the issue is
> solely in help or if it's some wierd
> interaction between he
New submission from Eli Bendersky:
There were numerous discussions and issues in the past about the cross-test
dependencies that sometimes exist because some tests need to muck with import
caches (both on the Python and C level). Some examples:
http://mail.python.org/pipermail/python-dev/2013
Eli Bendersky added the comment:
As Serhiy points out, this is a duplicate of #5166
--
superseder: -> ElementTree and minidom don't prevent creation of not
well-formed XML
___
Python tracker
<http://bugs.python.org
Changes by Eli Bendersky :
--
resolution: -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Eli Bendersky :
--
nosy: +eli.bendersky
___
Python tracker
<http://bugs.python.org/issue5166>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eli Bendersky added the comment:
A question that comes up is how should a module signal to regrtest that it
needs to be run in a subprocess?
The most natural approach is to have a special attribute set in the module's
global dict (for example: __REGRTEST_SUBPROCESS__ = True); however, th
Eli Bendersky added the comment:
> An easier hack is likely just a new "always run in subprocess" container
> with submodule names in regrtest.py. It's not elegant, but it will work.
>
True, that's also an option. I had it in mind in the beginning, but it's
too
Changes by Eli Bendersky :
--
Removed message: http://bugs.python.org/msg196813
___
Python tracker
<http://bugs.python.org/issue18906>
___
___
Python-bugs-list m
Eli Bendersky added the comment:
> An easier hack is likely just a new "always run in subprocess" container
> with submodule names in regrtest.py. It's not elegant, but it will work.
>
True, that's also an option. I had it in mind in the beginning, but it's
too
Changes by Eli Bendersky :
--
nosy: +eli.bendersky, ethan.furman
___
Python tracker
<http://bugs.python.org/issue18908>
___
___
Python-bugs-list mailing list
Unsub
Changes by Eli Bendersky :
--
stage: -> patch review
versions: +Python 3.4
___
Python tracker
<http://bugs.python.org/issue18908>
___
___
Python-bugs-list mai
Eli Bendersky added the comment:
The fix looks good to me, in general. Could you create a test that goes along?
My only (minor) doubt is whether this should be generalized, in two dimensions:
1. PermissionError is mapped from both EACCES and EPERM. So to make the 2.7
patch equivalent with 3.x
Eli Bendersky added the comment:
LGTM, thanks
--
nosy: +eli.bendersky
___
Python tracker
<http://bugs.python.org/issue18912>
___
___
Python-bugs-list mailin
Eli Bendersky added the comment:
On Tue, Sep 3, 2013 at 2:32 AM, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
> > The most natural approach is to have a special attribute set in the
> module's global dict (for example: __REGRTEST_SUBPROCESS__ = True
Eli Bendersky added the comment:
Re (1) let's leave it as it is, now. I don't think it really matters.
I left some comments in Rietveld.
--
___
Python tracker
<http://bugs.python.o
Eli Bendersky added the comment:
Why guess... did you try it in the code?
Trying has another goal - it would be nice to have a short code sample here
demonstrating what's happening. The paragraph you're quoting seems obscure to
me, with or without the fix.
--
nosy: +eli
Eli Bendersky added the comment:
Yes, it seems like an oversight to me. Printing --version to stdout is more
customary (Python itself does it, and most other tools do too).
A question comes up about backwards compatibility. I would definitely not
change it in 2.x - it's just not worth i
Eli Bendersky added the comment:
I'm still interested in seeing benchmarks that show where this actually
improves things and by how much. Also, whether any regressions occur and how
serious they are.
--
nosy: +eli.bendersky
___
Python tr
Eli Bendersky added the comment:
On Wed, Sep 4, 2013 at 6:26 AM, Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
> Only on 3.4.
> Python prints the version on stdout since 3.4 -- before it used stderr:
> 3.3$ ./python -V 2> /dev/null
> 3.3$ ./python -V &g
Eli Bendersky added the comment:
The Python executable change is from #18338
--
___
Python tracker
<http://bugs.python.org/issue18920>
___
___
Python-bugs-list m
Eli Bendersky added the comment:
Patch attached
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31587/issue18920.1.patch
___
Python tracker
<http://bugs.python.org/issu
Eli Bendersky added the comment:
Great, Ethan.
I'd say the inspect fix has to be reviewed and committed separately. Maybe
#16938 is the right place to post the patch for it. Once that's in, we can
review/commit the enum parts.
--
601 - 700 of 1229 matches
Mail list logo
