Eli Bendersky added the comment:
Looks pretty good, Serhiy. I left some comments in Rietveld.
--
___
Python tracker rep...@bugs.python.org
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:
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:
print(member)
%s % member
{}.format
Eli Bendersky added the comment:
On Thu, Aug 15, 2013 at 3:20 PM, Eric V. Smith rep...@bugs.python.orgwrote:
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 out of the box
Eli Bendersky added the comment:
I guess there are merits to keeping it all in the same place.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
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 the constants
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 treatment
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 families the OS
Eli Bendersky added the comment:
On Wed, Aug 14, 2013 at 6:24 AM, Serhiy Storchaka rep...@bugs.python.orgwrote:
Serhiy Storchaka added the comment:
I'm surprised that test_repr is not failed. '%i' %
socket.AddressFamily.AF_INET returns 'AddressFamily.AF_INET' instead of '2'
as I expected
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':
/* Special-case boolean: we want 0/1
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. SOCK_
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 with .rst
changes, etc
Eli Bendersky added the comment:
Ethan, str.format uses __format__. We don't seem to provide a custom one.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
Eli Bendersky added the comment:
On Wed, Aug 14, 2013 at 6:55 AM, Serhiy Storchaka rep...@bugs.python.orgwrote:
Serhiy Storchaka added the comment:
`.format()` is surprised too.
'{:}'.format(AF.IPv4)
'AF.IPv4'
'{:10}'.format(AF.IPv4)
' 1'
Oh, this looks like a bug
Changes by Eli Bendersky eli...@gmail.com:
--
title: % formatting incomplete for Enum - String formatting (% and str.format)
issues with Enum
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
Eli Bendersky added the comment:
On Wed, Aug 14, 2013 at 11:48 AM, Ethan Furman rep...@bugs.python.orgwrote:
Ethan Furman added the comment:
Eric V. Smith added the comment:
For the format version, what gets called is:
int_subclass.__format__('d'), which is int.__format__
Eli Bendersky added the comment:
On Wed, Aug 14, 2013 at 11:56 AM, Eric V. Smith rep...@bugs.python.orgwrote:
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 it always format
Eli Bendersky added the comment:
On Wed, Aug 14, 2013 at 12:07 PM, Ethan Furman rep...@bugs.python.orgwrote:
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 debatable.
An IntEnum's str
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. I suggest to wait a day
Eli Bendersky added the comment:
On Wed, Aug 14, 2013 at 2:38 PM, Eric V. Smith rep...@bugs.python.orgwrote:
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 which argument to .format()
to use
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 rep
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 objects to
it (both
Eli Bendersky added the comment:
On Mon, Aug 12, 2013 at 12:41 PM, Serhiy Storchaka
rep...@bugs.python.orgwrote:
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 breaks
Eli Bendersky added the comment:
On Mon, Aug 12, 2013 at 1:33 PM, Eli Bendersky rep...@bugs.python.orgwrote:
Eli Bendersky added the comment:
On Mon, Aug 12, 2013 at 12:41 PM, Serhiy Storchaka
rep...@bugs.python.orgwrote:
Serhiy Storchaka added the comment:
Here is a preliminary
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 initial patch
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/file31264/socket
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 a way
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 seem to
me to be one
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 rep
Changes by Eli Bendersky eli...@gmail.com:
--
resolution: - invalid
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18268
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 rep...@bugs.python.orgwrote:
Antoine Pitrou added the comment:
Antoine, I committed your patch (with a bit of comments added),
*leaving the module caching in*.
Thanks!
A longer term solution to all
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 be called
Changes by Eli Bendersky eli...@gmail.com:
Added file: http://bugs.python.org/file31226/pystate-findmodule-clarify.1.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15651
Eli Bendersky added the comment:
rantIt'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./rant It's pure luck
I noticed this change during the alpha release
Eli Bendersky added the comment:
On Fri, Aug 9, 2013 at 8:44 AM, Stefan Behnel rep...@bugs.python.orgwrote:
Stefan Behnel added the comment:
ask to be added to the experts list for ET
Already done, see the corresponding python-dev thread.
Done. 747970502b23
Eli Bendersky added the comment:
On Fri, Aug 9, 2013 at 12:34 PM, Antoine Pitrou rep...@bugs.python.orgwrote:
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 wrapper?
Only
Eli Bendersky added the comment:
Nick, you're right - m_size=0 is a valid value. How about the attached patch?
--
Added file: http://bugs.python.org/file31199/issue18668.msize-fix.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Eli Bendersky added the comment:
Thanks Antoine. I think I understand the patch better now. Just a couple small
questions and otherwise LGTM
This code in the beginning in PyInit__elementtree:
m = PyState_FindModule(elementtreemodule);
if (m) {
Py_INCREF(m);
return m
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), I'm
Eli Bendersky added the comment:
On Thu, Aug 8, 2013 at 7:00 AM, Antoine Pitrou rep...@bugs.python.orgwrote:
Antoine Pitrou added the comment:
This code in the beginning in PyInit__elementtree:
m = PyState_FindModule(elementtreemodule);
if (m) {
Py_INCREF(m
Eli Bendersky added the comment:
On Thu, Aug 8, 2013 at 7:14 AM, Antoine Pitrou rep...@bugs.python.orgwrote:
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 kicks in anyway
Eli Bendersky added the comment:
Thanks for the review!
--
resolution: fixed -
stage: committed/rejected - needs patch
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18668
Changes by Eli Bendersky eli...@gmail.com:
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18668
Eli Bendersky added the comment:
Antoine, some questions about the patch:
First, I think it omits expat_capi from the state. Is that intentional?
Second, I'm not sure if this approach is fully aligned with PEP 3121. A global,
shared state is still used. Instead of actually having a different
Eli Bendersky added the comment:
On Wed, Aug 7, 2013 at 6:28 AM, Antoine Pitrou rep...@bugs.python.orgwrote:
Antoine Pitrou added the comment:
First, I think it omits expat_capi from the state. Is that
intentional?
What would it do in the state? There's nothing to release.
That's
Eli Bendersky added the comment:
LGTM now. Make sure to run the test(s) in refleak mode and let's wait for a
couple of days before committing, in case someone else has comments.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
New submission from Eli Bendersky:
docs.python.org/dev/c-api/module.html Currently doesn't say much about m_size,
except that setting it to -1 means no memory needed.
m_size == -1 has a much more important use that is not documented: it signals
the import machinery that the module should
Changes by Eli Bendersky eli...@gmail.com:
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18668
___
___
Python-bugs-list mailing
Eli Bendersky added the comment:
Here's a documentation patch generated for 3.3
--
keywords: +patch
Added file: http://bugs.python.org/file31174/issue18668.doc.1.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18668
Eli Bendersky added the comment:
IMHO it's very much dependent on the change. When making C code changes, I
usually run the relevant tests with refleaks, and then run the whole test
suite; all of this --with-pydebug. Personally I've not encountered cases where
non-debug builds failed where
Eli Bendersky added the comment:
Bless you Antoine, I've been just planning to do this myself to tackle the
re-importing troubles I was having in tests the other day :-)
I'll take a look at this soon, promise!
--
___
Python tracker rep
Eli Bendersky added the comment:
I also think that exchanging the explicit type checks by __index__ merits more
thought and is outside the scope of this local fix. The proposed patch does not
add any new type checks, but acts within the bounds of code for which the type
is already established
Eli Bendersky added the comment:
Thanks, Serhiy.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13612
Eli Bendersky added the comment:
Would it not be better to temporarily-fix the test rather than the code?
--
nosy: +eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18647
Eli Bendersky added the comment:
Wonderfully terse, as usual. Can you be so kind to elaborate just a tiny bit
more? Is the amount of doctests this affects so large that it's better to
change the implementation? What are the plans for this temporary stage - is
there an intention to fix
Eli Bendersky added the comment:
Yes, AFAIU PyNumber_Long is the equivalent of Python-level int(obj). With other
constructors of PyLong you are limited by long long (while Python integers may
be arbitrarily large).
Ethan - If you're still short on time I can pretty up this patch and put
Eli Bendersky added the comment:
-1 on making more internals public.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18635
___
___
Python-bugs
Eli Bendersky added the comment:
Posted a Rietveld code review
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18264
___
___
Python-bugs-list
Changes by Eli Bendersky eli...@gmail.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3591
Eli Bendersky added the comment:
Brian - gentle ping
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13368
___
___
Python-bugs-list mailing list
Eli Bendersky added the comment:
I've noticed this is a duplicate of issue #14465. Closing it - let's continue
the discussion there, when the time comes.
--
resolution: - duplicate
stage: needs patch - committed/rejected
status: open - closed
superseder: - xml.etree.ElementTree: add
Eli Bendersky added the comment:
A patch exists in the duplicate #17372
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14465
___
___
Python-bugs
Eli Bendersky added the comment:
Could you please refresh the patch for Python 3.3 and 3.4 (_elementtree went
through many changes in 3.3)?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7990
Eli Bendersky added the comment:
Fixed. Thanks!
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17011
Changes by Eli Bendersky eli...@gmail.com:
--
nosy: -eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17359
___
___
Python-bugs-list
Eli Bendersky added the comment:
I'm not sure what the issue here is, exactly. Python 2.7 is known for implicit
conversions between ascii and unicode, and this appears to be an artifact of
your data. Note that Python 2.7 only gets fixes for serious bugs at this point.
Can you reproduce
Eli Bendersky added the comment:
I'm (somewhat) back looking at this. Should the first step be
sys.get_calling_module_name()? I can provide a patch. Re its name, perhaps the
long name isn't that bad given that this is a rather obscure API. But
suggestions for something shorter/better
Changes by Eli Bendersky eli...@gmail.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17902
Eli Bendersky added the comment:
I've been reading the discussion again to figure out what we need to move
forward; it appears that a simple approach of using str(int(obj)) in json
encoding when isinstance(obj, int) was acceptable for many of the participants,
and it helps solve the most
Eli Bendersky added the comment:
[please note that the patch is POC/hacky at best - it's likely to leak memory
and be careless and incomplete in other ways. I'm just trying to demonstrate
the approach]
--
___
Python tracker rep...@bugs.python.org
Eli Bendersky added the comment:
Can you clarify why it would be useful? Note that we're talking about private
non-documented members here.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18635
Eli Bendersky added the comment:
Ben, would you like to provide an updated patch?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12645
Eli Bendersky added the comment:
Quite a bit of encoding-related tests were added recently (by Serhiy, IIRC).
Unless there are objections or more specific test suggestions, I will close
this issue in a few days.
--
___
Python tracker rep
Eli Bendersky added the comment:
Serhiy, do you want to backport the buffer overflow fix to 2.7?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13612
Eli Bendersky added the comment:
Thanks for the report (Eric) and the patch (Alex). There are currently some
open bugs we need to handle first, so this is somewhat lower priority. I hope
to get to it before the 3.4 release.
--
___
Python tracker
Eli Bendersky added the comment:
That sounds like a good idea, Stefan.
--
nosy: +eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18594
Changes by Eli Bendersky eli...@gmail.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18593
Eli Bendersky added the comment:
LGTM, thanks.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18480
___
___
Python-bugs-list mailing list
Eli Bendersky added the comment:
_save_and_remove module can also raise ImportError
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12645
Eli Bendersky added the comment:
A single patch for both the ReST doc and docstring would be helpful. Except
formatting, their contents can be the same.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12645
Eli Bendersky added the comment:
Sent some review comments. I'll be on a short vacation this weekend, so please
wait at least until next week so I can review the changes. Also, Nick should
definitely review this too :)
--
___
Python tracker rep
Eli Bendersky added the comment:
On Fri, Jun 21, 2013 at 6:59 PM, Barry A. Warsaw rep...@bugs.python.orgwrote:
Barry A. Warsaw added the comment:
On Jun 22, 2013, at 01:08 AM, Nick Coghlan wrote:
Can I vote for something like __builtin__ as the protocol, rather than
something entirely
Eli Bendersky added the comment:
Nicely done summary, Ethan.
I think it would be worthwhile to add the reasoning of why from 1 and not from
0 into the documentation and maybe the PEP too. I think the falsiness answer
is reasonable, and since it's a common FAQ it's good to state it explicitly
Eli Bendersky added the comment:
The fact str(x) returns the fully qualified name for IntEnum worries me a
bit, but if there's a real backwards compatibility problem there (rather than
a theoretical one), hopefully we'll see it once we start converting socket
and errno.
What
Eli Bendersky added the comment:
Ethan, did you forget to hg add ?
On Fri, Jun 14, 2013 at 12:44 AM, Nick Coghlan rep...@bugs.python.orgwrote:
Nick Coghlan added the comment:
That commit looks just a touch incomplete...
--
resolution: fixed -
stage: committed/rejected - commit
Eli Bendersky added the comment:
LGTM.
I suggest you wait for a couple of days to see if others have any critical
comments and then commit.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17947
Changes by Eli Bendersky eli...@gmail.com:
--
nosy: -eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17375
___
___
Python-bugs-list
Changes by Eli Bendersky eli...@gmail.com:
--
nosy: -eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1772673
___
___
Python-bugs-list
Eli Bendersky added the comment:
Nick prudently moved the unique discussion to its own issue - 18042. Let's get
the initial implementation docs committed first (without unique in the
implementation, although it's fine to have it as an example in the docs for
now), close this issue
Eli Bendersky added the comment:
I sent a fresh review - nothing major; it's very near commit readiness now.
Additional changes can be done after the initial commit. We have time until 3.4
beta (November 2013) to tweak stuff (and the documentation whenever
Changes by Eli Bendersky eli...@gmail.com:
--
nosy: -eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17987
___
___
Python-bugs-list
Eli Bendersky added the comment:
Ah, no time, no time... :-/
I may get back to this in the future. Bumping to more relevant versions for now.
--
versions: +Python 3.3, Python 3.4 -Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
http
Eli Bendersky added the comment:
I tweaked the code a bit (no functionality changes, mostly cleanups and a bit
of refactoring). Figured it will be easier to just send an updated patch than
another review. The diff from patch 06 can be seen via the Rietveld interface.
Also, after reading
Eli Bendersky added the comment:
Thanks Ethan :)
From my point of view this is LGTM, as long as:
* There's ReST documentation
* You remove the code to support extensions and customizations not mandated by
PEP 435. As I mentioned before, this seems to be a YAGNI that complicates the
code
Eli Bendersky added the comment:
I'm not sure which promises you're referring to Nick, and to whom they were
made; the only formal promise we made is PEP 435 - and it doesn't mention this
extensibility.
I won't argue beyond this comment, since I know I'm part of the minority
opinion here
201 - 300 of 1226 matches
Mail list logo
