Eric V. Smith added the comment:
I like GH-9151 better because it changes only the namedtuple case, not other
classes that are derived from list or tuple.
But, I might copy some of the tests from 9151 before I'm done with this.
--
___
P
Eric V. Smith added the comment:
The question here is: what should asdict() return if the dataclass contains a
namedtuple? What the code is trying to do (but currently failing!) is to return
another namedtuple, but with the values returned by recursively calling in to
asdict() (or rather
Eric V. Smith added the comment:
I've been thinking about this, but I don't have a suggestion on how to improve
the API. Maybe some sort of visitor pattern? I'm open to concrete ideas.
--
___
Python tracker
<https://bugs.pyt
Eric V. Smith added the comment:
Because this issue describes two different problems, I'm going to close it.
The part of it that involves errors during the evaluation of a syntactically
valid expression was at least partially fixed in #30465. I will probably
re-work how this fi
Eric V. Smith added the comment:
Thanks, Raymond. I agree that this request is too specialized to add to
dataclasses. Any proposal here or that I've been able to think of complicate
the API for the much more common use case of not needing asdict()
specialization.
To the original post
New submission from Eric V. Smith :
There are 6 PyParser_SimpleParse* functions in pythonrun.c. 5 of them are
documented in c-api/veryhigh.rst and appear in pythonrun.h. But
PyParser_SimpleParseStringFilename is not documented and is not in any .h file.
I propose we delete
Change by Eric V. Smith :
--
keywords: +patch
pull_requests: +8691
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34653>
___
___
Py
Eric V. Smith added the comment:
I'm not going to backport this to 3.7, just in case.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: -Python 3.7
___
Python tracker
<https://bugs.pyth
Eric V. Smith added the comment:
New changeset 9b9d97dd139a799d28ff8bc90d118b1cac190b03 by Eric V. Smith in
branch 'master':
bpo-34363: dataclasses.asdict() and .astuple() now handle fields which are
namedtuples. (GH-9151)
https://github.com/python/cpyt
Eric V. Smith added the comment:
New changeset 78aa3d8f5204bc856d7b2eb67288cf90c6a30660 by Eric V. Smith (Miss
Islington (bot)) in branch '3.7':
bpo-34363: dataclasses.asdict() and .astuple() now handle fields which are
namedtuples. (GH-9151) (GH-9304)
https://github.com/pyth
Eric V. Smith added the comment:
Agreed with @geoffreyspear: "means" is okay, the rest of the changes look good.
--
nosy: +eric.smith
___
Python tracker
<https://bugs.python.o
Eric V. Smith added the comment:
I'm doing some fairly major surgery on line and column numbers for fixing
f-string errors. I'll see if I can include this case, too.
--
nosy: +eric.smith
___
Python tracker
<https://bugs.python.o
Change by Eric V. Smith :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Eric V. Smith added the comment:
I think Benjamin's diagnosis is correct. In which case, my f-string error
reporting changes (see #34364) won't intersect with a fix to this issue.
--
___
Python tracker
<https://bugs.python.o
Change by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<https://bugs.python.org/issue34690>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
I think this is along the lines of a recent discussion on the c-api mailing
list about passing a context value (your handle) to every C call. See this
message for some discussion:
https://mail.python.org/mm3/archives/list/capi-...@python.org/message
Change by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<https://bugs.python.org/issue34751>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
I agree with Raymond and Tim here: while it's inevitably true that there are
many possible hash collisions, we'd need to see where the current algorithm
caused real problems in real code. Pointing out a few examples where there was
a collision
Eric V. Smith added the comment:
I'm not one to judge the effectiveness of a new hash algorithm. But my personal
concern here is making something else worse: an unintended consequence. IMO the
bar for changing this would be very high, and at the least it would need to be
addressing a
Eric V. Smith added the comment:
[Adding to nosy people who were on the original email]
Copying (part of) my response from the email thread:
These work:
print(get_type_hints(Bar.__init__, globals()))
print(get_type_hints(Bar.__init__, Bar.__module__))
But I agree that maybe doing something
Eric V. Smith added the comment:
I worked on this at the core sprint, and I have a patch almost ready.
--
___
Python tracker
<https://bugs.python.org/issue34
Eric V. Smith added the comment:
Ned: I'm marking this as a release blocker because I'd like to get it in 3.7.1.
If I can't do that in the next 5 hours or so, I'll remove the release blocker
tag.
--
assignee: -> eric.smith
nosy: +ned.deily
priority: no
Eric V. Smith added the comment:
It's more elaborate than I'd like, but I think it's the right way to solve it:
I'm passing in the starting line and column number to the parser machinery.
--
___
Python tracker
<https://bug
Eric V. Smith added the comment:
Unfortunately, I'm not going to be able to give this the attention it deserves
before the 3.7.1 cutoff. The changes are sufficiently tricky that I want to
make sure I think through the issue in the appropriate detail.
Ned: I've made it not a relea
Change by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<https://bugs.python.org/issue34838>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
Perhaps we could improve that error message. If Ronald hand't pointed out the
actual problem, it would have taken me a while to figure it out, too.
Maybe "bad character range +-* at position 2: starting character is after
ending character"
Change by Eric V. Smith :
--
assignee: -> eric.smith
___
Python tracker
<https://bugs.python.org/issue33947>
___
___
Python-bugs-list mailing list
Unsubscrib
Eric V. Smith added the comment:
As much as I agree that allow_abbrev=False would be a much better default, at
this point we can't change it. Doing so would break who knows how many existing
scripts when they upgraded Python versions.
--
nosy: +eric.smith
resolution: -> n
Eric V. Smith added the comment:
I think this is a bug that should be fixed. This is similar to how f-strings
used to work: the generated byte code would call format(something-or-other),
and if you'd defined a name "format" in your code it would fail.
Now admittedly "fo
Eric V. Smith added the comment:
You can in fact pass a dict to bytes(), as long as the keys are ints in the
correct range:
>>> bytes({0:10, 1:20})
b'\x00\x01'
I'm not claiming it's very useful, but it does conform to the docs. I'm not
sure the error mes
New submission from Eric V. Smith :
What do you propose the repr would look like?
--
components: +Interpreter Core -Library (Lib)
nosy: +eric.smith
___
Python tracker
<https://bugs.python.org/issue34
Eric V. Smith added the comment:
I can't think of another place where we issue a warning for anything similar.
I'm opposed to any changes here: it's clearly documented behavior.
It's like being surprised .ini files convert to strings: it's just how that
forma
Change by Eric V. Smith :
--
resolution: -> not a bug
___
Python tracker
<https://bugs.python.org/issue34972>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Eric V. Smith :
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<https://bugs.python.org/issue34
Eric V. Smith added the comment:
Agreed with Steven. In addition, please make sure you runnable example only
uses imports from python's standard library.
--
nosy: +eric.smith
___
Python tracker
<https://bugs.python.org/is
Eric V. Smith added the comment:
I agree with Xiang Zhang: I don't think we should show any content. Especially
since basically every file will be truncated, and more often than not the
interesting content isn't at the start or end o
Eric V. Smith added the comment:
New changeset b9182aa7dad8991fc8768ae494b45b5f7c316aca by Eric V. Smith (Miss
Islington (bot)) in branch '3.7':
bpo-33947: dataclasses no longer can raise RecursionError in repr (GF9916)
(#9970)
https://github.com/python/cpyt
Change by Eric V. Smith :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Eric V. Smith added the comment:
I think it would be a good idea to make this more consistent. We should run
through a multi-release deprecation cycle, since it might break existing,
working code. And we could only start that in 3.8.
--
nosy: +eric.smith
versions: +Python 3.8
Eric V. Smith added the comment:
Hmm, if there's a test for this, then that does complicate the decision. Is
this behavior documented anywhere? If so, then we shouldn't change it.
If we do decide to go forward with a change, it should be in the master branch,
which will
Eric V. Smith added the comment:
After a little more thinking: maybe we should just document this behavior, make
it official, and not change it.
--
___
Python tracker
<https://bugs.python.org/issue35
Eric V. Smith added the comment:
Could you give some examples of problems caused by inconsistent usage of
sentinels?
I do often wish modules exposed their sentinel values, since it makes writing
wrappers easier. It's one of the reasons I ended up exposing
dataclasses.MI
Eric V. Smith added the comment:
I don't see any problems that need solving.
My only interest in this is that I tend to think sentinels that are used for
missing parameters should be exposed, and this isn't always an obvious
consideration when designing an API.
For example, say
Change by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<https://bugs.python.org/issue35143>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
I think we can remove these in 3.8. My understanding of the policy (which I
cannot find: the search terms are too generic) is that if a module defines
__all__, and the symbol we want to remove isn't in it, then we can remove the
symbol in the next fe
Eric V. Smith added the comment:
Let me restate that: I think we can remove these in 3.8 if they're not in the
module's __all__. I haven't checked that, although it would surprise me if any
of them were in __all__.
--
___
Python
Eric V. Smith added the comment:
Please create a small program that reproduces the problem. You should strip out
everything that isn't needed. There's no way we can guess the problem without
seeing the code.
--
nosy: +eric.smith
Change by Eric V. Smith :
--
assignee: -> eric.smith
___
Python tracker
<https://bugs.python.org/issue35212>
___
___
Python-bugs-list mailing list
Unsubscrib
Eric V. Smith added the comment:
As far as which path components are returned, I think this is working as
designed. The documentation for os.path.join says:
"""
If a component is an absolute path, all previous components are thrown away and
joining continues from the absolute
Change by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<https://bugs.python.org/issue35224>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
Agreed that this is a misunderstanding and not a bug.
iuliananet: you're modifying the same list each time you're calling
problem2_2(). You might look for help on the python-tutors mailing list:
https://mail.python.org/mailman/listinfo/tutor
-
Eric V. Smith added the comment:
Yes, this is as expected.
As I said, since this isn't a bug in Python, this is not the appropriate place
to discuss your problem. I suggest python-tutors list, but there are many other
places to learn about python global and local vari
Eric V. Smith added the comment:
You're going to have to provide some information, we can't guess at what's
going on. At the very least:
What OS? What shell? Which exact version of Python? How was it installed? Where
is the file pyvenv.cfg that shows the problem? What
Eric V. Smith added the comment:
I think it's just an oversight.
--
assignee: barry -> brett.cannon
___
Python tracker
<http://bugs.python.org/issue18058>
___
Eric V. Smith added the comment:
No reason I can think of, other than it never occurred to me to do it.
--
___
Python tracker
<http://bugs.python.org/issue18
Eric V. Smith added the comment:
I don't think anyone would (or should!) write code that cares, so I think your
proposed change is a good one.
--
___
Python tracker
<http://bugs.python.org/is
Eric V. Smith added the comment:
See also issue18107, in particular
http://mail.python.org/pipermail/pypy-dev/2013-May/011433.html.
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue3
Eric V. Smith added the comment:
It's by design. Search for "mutable default arguments", for example
http://docs.python-guide.org/en/latest/writing/gotchas.html#mutable-default-arguments
--
nosy: +eric.smith
resolution: -> invalid
stage: -> committed/rejected
s
New submission from Eric V. Smith:
See:
http://mail.python.org/pipermail/python-dev/2013-June/127068.html
The find command:
find $(srcdir) '(' -name '*.fdc' -o -name '*~' \
-o -name '[@,#]*' -o -name '*.old'
Eric V. Smith added the comment:
My plan is to just fix this issue, right now, by changing the find command to
be:
find $(srcdir)/[a-zA-Z]* ...
That fixes this bug and keeps the current functionality.
If someone wants to open another issue about changing what distclean does, I
think
Eric V. Smith added the comment:
I'm not sure what you're saying. Given the function definition, the way you're
calling it is incorrect, and the error messages explain why.
Are you saying that these ways to call repeatfunc() are documented somewhere
that needs fixing? I couldn
Changes by Eric V. Smith :
--
status: open -> pending
___
Python tracker
<http://bugs.python.org/issue18313>
___
___
Python-bugs-list mailing list
Unsubscri
Eric V. Smith added the comment:
I see. You can't call repeatfunc() and specify times with a named argument
because of *args. Interesting. I'll let Raymond weigh in.
--
status: pending -> open
___
Python tracker
<http://bugs.pytho
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue18340>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
Could you provide an entire example, showing the class num and how you assign
__div__?
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue18
Eric V. Smith added the comment:
Your patch looks like the output of "hg help", or similar.
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.o
Eric V. Smith added the comment:
For some reason the blank link in the Coverity report confused me. Yes,
swapping the lines looks right.
--
___
Python tracker
<http://bugs.python.org/issue18
Eric V. Smith added the comment:
bool instances are immutable, so all "value.toggle()" could do is the same as
"not value". That is, return a new bool with the "toggled" value.
--
nosy: +eric.smith
resolution: -&g
Eric V. Smith added the comment:
Since it would be the same as "not value", I can't imagine this would be added
to the language.
--
___
Python tracker
<http://bugs.pyt
Eric V. Smith added the comment:
If that's your concern, you can use operator.not_.
>>> import operator
>>> filter(operator.not_, [False, True, False, False, True])
[False, False, False]
--
___
Python tracker
<http://
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue18738>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
> What is '{:}' supposed to mean?
>
It should be the same as '{}'. That is, an empty format string.
--
___
Python tracker
<http
Eric V. Smith added the comment:
I think:
>>> '{:}'.format(AF.IPv4)
'AF.IPv4'
is correct, assuming str(AF.IPv4) is 'AF.IPv4'. I'm not sure what:
>>> '{:10}'.format(AF.IPv4)
should produce. There's a special case for an em
Eric V. Smith added the comment:
>>
>> I think that specifying __format__() would be best, except then you need to
>> decide what sort of format specification language you want to support, and
>> deal with all of the implementation details. Or, maybe just have
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 like a
str?"
I assumed we'd want it to look like the str() version of itself, always
Eric V. Smith added the comment:
I think IntEnum should act like a str for format() purposes. After all, having
a useful string representation is a prime reason it exists. If you want it to
act like a str() sometimes, and an int() at others, you're going to have to
parse the format spec
Eric V. Smith added the comment:
If IntEnum.__format__ is going to parse the format string, it's a little
fragile. For example, say we modify int.__format__ to understand a "Z"
presentation type. Who's going to remember to update IntEnum.__format__?
For reference, the exis
Eric V. Smith added the comment:
I don't think it's possible for int (PyLong) to handle a decision to format
itself as a string. Personally, I'd like this:
>>> format(3, 's')
Traceback (most recent call last):
File "", line 1, in
ValueError: Unk
Changes by Eric V. Smith :
--
assignee: -> ethan.furman
___
Python tracker
<http://bugs.python.org/issue18738>
___
___
Python-bugs-list mailing list
Unsubscri
Eric V. Smith added the comment:
The value of int is always used, except when the format string is empty. PEP
3101 explicitly requires this behavior. "For all built-in types, an empty
format specification will produce the equivalent of str(value)." The "built-in
type"
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. The empty string there means "use the next one". The part after the colon
Eric V. Smith added the comment:
It's not whether a field width is specified that makes it "empty" or not, it's
where there's anything in the format specifier at all. I'm trying to simplify
the conversation by using format() instead of str.format(), but I
Eric V. Smith added the comment:
>> In order to avoid that logic, and cause more format specifiers to result in
>> str-like behavior, we'll need to implement an __format__ somewhere (IntEnum,
>> I guess) that makes the "int or str" decision.
>
> If thi
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. This means that "just printing out" an
> enum member should have a nice string re
Eric V. Smith added the comment:
On 8/15/2013 7:09 PM, Ethan Furman wrote:
>
> Ethan Furman added the comment:
>
>> Eric V. Smith added the comment:
>>
>> I think the answers should be:
>>
>> - Formats as int if the length of the format spec is >= 1
Eric V. Smith added the comment:
On 8/15/2013 8:20 PM, Ethan Furman wrote:
> The characters I list are the justification chars and the digits that would
> be used to specify the field width. If
> those are the only characters given then treat the MixedEnum member as the
> member
Eric V. Smith added the comment:
Objects/unicodeobject.c has this, at line 14316:
if (PyMapping_Check(args) && !PyTuple_Check(args) && !PyUnicode_Check(args))
ctx.dict = args;
else
ctx.dict = NULL;
and later at line 14348:
if (ctx.argidx < ctx.
Changes by Eric V. Smith :
--
title: '' % [1] doens't fail -> '' % [1] doesn't fail
___
Python tracker
<http://bugs.python.org/issue18750>
___
_
Eric V. Smith added the comment:
On 8/16/2013 12:24 AM, Ethan Furman wrote:
>
> Ethan Furman added the comment:
>
>> Eric V. Smith added the comment:
>>
>> But a datetime format string can end in "0", for example.
>>
>>>>> form
Eric V. Smith added the comment:
The code looks basically the same in 2.7, and there PyMapping_Check looks for
__getitem__, so maybe issue 5945 is just incorrect in its analysis.
In any event, I'm not sure this is worth fixing. There are lots of little
corner cases that could be b
Eric V. Smith added the comment:
Oh, I don't feel my time has been wasted. Where else can I have a discussion of
__format__?
With this patch, given this:
class UpperString(str):
def __format__(self, fmt):
return str.__format__(self, fmt).upper()
class UpperEnum(UpperString,
Eric V. Smith added the comment:
On 8/20/2013 9:26 PM, Ethan Furman wrote:
> Sounds like the way forward is to specify in the docs how the default
> Enum __format__ behaves (basically honors width and justification
> settings to yield the name, anything else passes through to
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 keep this
issue the __format__ part, since it's been most discussed
Eric V. Smith added the comment:
I haven't had time to review this yet, but at least several of these, if true,
are definitely bugs that should be backported. "254.192.128.0" as a netmask?
Descending octets as the condition? Yikes.
--
nosy: +eric.smith
stage:
Eric V. Smith added the comment:
Looks good to me, too. Thanks for considering all of the feedback!
--
___
Python tracker
<http://bugs.python.org/issue18
Eric V. Smith added the comment:
It would be nice to combine the behaviors that defaultdict and the
case-insensitive comparisons.
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue18
Eric V. Smith added the comment:
Just today I was using a defaultdict where the keys are stock symbols. They're
case insensitive (at least for this particular application).
In this case I just str.upper everything, but it would be a nice feature to
case-preserve the keys that I pre-pop
Eric V. Smith added the comment:
True enough!
I was trying to distinguish keys that I populate with initial values (mostly
stock indexes) versus those where I just read values from a user-supplied file.
When I populate the index values, I'd like to preserve the case I initially
used. W
Eric V. Smith added the comment:
In what way is it different?
Does it cause a problem, or is it compatible but different?
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue14
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue14642>
___
___
Python-bugs-list mailing list
Unsubscribe:
2001 - 2100 of 2699 matches
Mail list logo
