[issue37296] pdb next vs __next__
Rick added the comment: I have no idea what program this was in, it's lost in the depths of time. I can't retain these things for over a year, too old, maybe in my twenties I would have remembered what code this was in but no longer. Can it. -- ___ Python tracker <https://bugs.python.org/issue37296> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37296] pdb next vs __next__
New submission from Rick : Don't know how to get version from pdb, Makefile says 2.7 Code runs but when debugging I get an error that an iterator has no next() function. It has got a __next__() function, and it runs, just not under pdb. If I create a spurious next() function, pdb runs, and calls the __next__() function. -- messages: 345712 nosy: tsingi priority: normal severity: normal status: open title: pdb next vs __next__ type: behavior ___ Python tracker <https://bugs.python.org/issue37296> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9009] Improve quality of Python/dtoa.c
Rick Regan added the comment:
> if (!(dig = quorem(b,d))) {
> b = multadd(b, 10, 0); /* very unlikely */
> dig = quorem(b,d);
> }
>
> This code is part of the algorithm for strtod. Here b and d are
> Bigints, and b / d is a fraction that gives an approximation to
> the value of the input to strtod; the aim is to produce the
> digits of b / d one-by-one to compare them with the strtod input,
> and (eventually) use the result of that comparison work out whether
> to round up or down.
> If the condition of the 'if' block above is ever satisfied, b is
> multiplied by 10 (that's the multadd(b, 10, 0) call), so the
> fraction b / d is multiplied by 10 (with no corresponding correction
> for the strtod input string), and the wrong comparison is made!
Mark,
I think I know the motivation for this code, although I still don't know how it
could hit. The halfway value H is scaled by a power of ten to put it in the
form "d1.d2d3d4d5...". The power of ten exponent is derived from the input
decimal string S, instead of computing it from H using logarithms.
Now what if H's exponent does not match S's? I'm thinking of cases like S =
10^n and H = 9.... * 10^(n-1). Scaling H by 10^-n would make it
0.9... . That leading 0 needs to be removed, by multiplying by 10, do
put it in the right form.
First of all, I don't know if a case like this is possible. Second of all, the
check would fail either way (1 against 0 vs 1 against 9).
BTW, b / d represents only the significant digits of H, so it shouldn't matter
that there's no corresponding adjustment to the input string.
To summarize: I'm not saying this code is necessary; I'm just saying it makes
you wonder.
--
nosy: +DoctorBinary
___
Python tracker
<http://bugs.python.org/issue9009>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1346874] httplib simply ignores CONTINUE
Rick Harris <[EMAIL PROTECTED]> added the comment: I'm implemented the behavior described by Mike above with a patch to 2.6. The patch will raise an ExpectationFailed before sending the body if the server responds with a 417 (Expectation Failed). This patch should only modify behavior for requests that specify "Expect: 100-continue" in the request's headers. Note: The spec says that the client should send the body if the server does not respond within some reasonable period of time. This is not currently supported. Anyone have any thoughts on how that could be done? -- keywords: +patch nosy: +rharris versions: +Python 2.6 -Python 2.4 Added file: http://bugs.python.org/file11073/issue1346874.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1346874> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2116] weakref copy module interaction
New submission from Rick Harris: The copy module will not properly copy/deepcopy weakrefs, it will bomb out with __new__ not having enough args. This is a problem b/c it makes deepcopying of objects that make use of Weak(Key|Value)Dictionaries difficult. To replicate: import copy, weakref class Test(object): pass t = Test() wr = weakref.ref(t) wr_new = copy.copy(wr) -- components: Library (Lib) files: copy.patch messages: 62413 nosy: rharris severity: normal status: open title: weakref copy module interaction type: crash versions: Python 2.5 Added file: http://bugs.python.org/file9433/copy.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2116> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2116] weakref copy module interaction
Rick Harris <[EMAIL PROTECTED]> added the comment: Sorry about forgetting the -c arg! The patch is intended for python/trunk/Lib/copy.py. It looks like Raymond Hettinger has made a similar-ish change recently to make Ellipsis copyable. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2116> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2651] Strings passed to KeyError do not round trip
New submission from Rick Harris <[EMAIL PROTECTED]>: Here is a bug in Python 2.5 which would be nice to fix for Py3k (since we are already breaking compatibility): Take a string: s = "Hello" Create a KeyError exception with that string: e = KeyError(s) Counterintuitively, casting the exception to a string doesn't return the same string: str(e) != s Instead, when KeyError is cast to a string it affixes single-quotes around the string. I have create a test which shows that the other built-in exceptions (except for 3 Unicode Errors which seem to be unusual in that they don't accept just a string), do indeed round-trip the string unaltered. This actually caused a bug (in an old version of zope.DocumentTemplate). I am including the test case I wrote for now; I will begin looking into a solution shortly and hopefully whip up a patch. -- components: Interpreter Core files: testExceptionStringRoundTrip.py messages: 65586 nosy: rharris severity: normal status: open title: Strings passed to KeyError do not round trip type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file10048/testExceptionStringRoundTrip.py __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2651> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2651] Strings passed to KeyError do not round trip
Rick Harris <[EMAIL PROTECTED]> added the comment: I think it is important to round-trip for at least two reasons: 1) Consistency. Other built-in exceptions behave this way, why should KeyError be any different? Okay, technically 3 UnicodeErrors don't allow just strings to be passed in (perhaps they should :-); but for common exception classes, they all behave the same way. To quote PEP-20: "Special cases aren't special enough to break the rules" 2) Intuitiveness. Decorating the string with quotes is unexpected; it has already caused at least one bug and could cause more. Ensuring intuitive round-trip behavior is an important enough issue that is explicitly discussed in PEP 327 for the decimal type. Why can't intuitiveness be restored to KeyError in Py3K? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2651> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38263] [Windows] multiprocessing: DupHandle.detach() race condition on DuplicateHandle(DUPLICATE_CLOSE_SOURCE)
Leonardo Rick added the comment: Traceback (most recent call last): File "", line 1, in File "C:\Program Files\Python39\lib\multiprocessing\spawn.py", line 116, in spawn_main exitcode = _main(fd, parent_sentinel) File "C:\Program Files\Python39\lib\multiprocessing\spawn.py", line 126, in _main self = reduction.pickle.load(from_parent) File "C:\Program Files\Python39\lib\multiprocessing\connection.py", line 967, in rebuild_pipe_connection handle = dh.detach() File "C:\Program Files\Python39\lib\multiprocessing\reduction.py", line 131, in detach return _winapi.DuplicateHandle( PermissionError: [WinError 5] Acesso negado -- nosy: +leonardo2 versions: +Python 3.9 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue38263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39580] Check for COMMAND_LINE_INSTALL variable in Python_Documentation.pkg
Rick Heil added the comment: In case folks reading this are not aware, installer(8) sets an environmental variable COMMAND_LINE_INSTALL when an installation is triggered on the command line versus when a user double-clicks a package in the GUI to kick off the install. I've filed the linked PR to add a test on the APPDIR open statement to avoid popping up the Finder when the package is installed on the command line. If there's a different method by which I should do this, please point me in the vague direction and I'm happy to update! (note - I just signed the CLA today so it should be registered soonish) -- ___ Python tracker <https://bugs.python.org/issue39580> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39580] Check for COMMAND_LINE_INSTALL variable in Python_Documentation.pkg
Change by Rick Heil : -- keywords: +patch nosy: +rickheil nosy_count: 3.0 -> 4.0 pull_requests: +19551 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20271 ___ Python tracker <https://bugs.python.org/issue39580> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33141] descriptor __set_name__ feature broken for dataclass descriptor fields
New submission from Rick Teachey : Summary: The descriptor `__set_name__` functionality (introduced in Python 3.6) does not seem to be working correctly for `dataclass.Field` objects with a default pointing to a descriptor. I have attached a file demonstrating the trouble. Details: If I set a `dataclass` class object field to a `dataclass.field` with a descriptor object for the `default` argument, the descriptor's `__set_name__` method is not called during initialization. This is unexpected because descriptors themselves seem to work pretty much flawlessly, otherwise. (Bravo on that by the way! Working descriptors isn't mentioned at all in the PEP as a feature but I was very pleased to see them working!!) System details: Python 3.7b02 Windows 10 PyCharm Community Edition btw this is my first ever Python bug report; I hope I did a good job. -- files: broken__set_name__.py messages: 314438 nosy: Ricyteach, eric.smith priority: normal severity: normal status: open title: descriptor __set_name__ feature broken for dataclass descriptor fields type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file47499/broken__set_name__.py ___ Python tracker <https://bugs.python.org/issue33141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33141] descriptor __set_name__ feature broken for dataclass descriptor fields
Rick Teachey added the comment: hmmm... if I check the C.d class attribute it seems to return the descriptor instance object (not a field object) before any C instances have been created. i guess this is just a part of how the dataclass implementation works. i didn't realize there's nothing "special" going on with descriptors here- the descriptors "just work" by virtue of being set to the class attribute at creation time. interesting. maybe because of this descriptors should short-circuit the field creation process entirely? that would be a shame though. having the option of auto-including a descriptor in the class repr turns out to be very useful and i'm already playing around with it in a project. one idea: what if it there were a keyword argument to mark a field as a descriptor, allowing tje descriptor to be set at type creation? this would need to disallow init=True, i think. and setting a field default to a descriptor class would then raise a type error. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler On Mon, Mar 26, 2018 at 6:47 AM, Eric V. Smith wrote: > > Eric V. Smith added the comment: > > I suppose I could, when overwriting the class member, check for > inspect.ismethoddescriptor and call __set_name__ myself. > > -- > components: +Library (Lib) > versions: +Python 3.8 > > ___ > Python tracker > <https://bugs.python.org/issue33141> > ___ > -- ___ Python tracker <https://bugs.python.org/issue33141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33141] descriptor __set_name__ feature broken for dataclass descriptor fields
Rick Teachey added the comment: Sounds like a relatively easy solution then. Hopefully it makes the beta 3 so I can use it immediately- thanks! -- ___ Python tracker <https://bugs.python.org/issue33141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33141] descriptor __set_name__ feature broken for dataclass descriptor fields
Rick Teachey added the comment: I suppose one downside of that solution is __set_name__ will be called for every Field whether or not it is need. Probably can't be helped without major complications. -- ___ Python tracker <https://bugs.python.org/issue33141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33141] descriptor __set_name__ feature broken for dataclass descriptor fields
Rick Teachey added the comment:
Eric, looking at the PR; note that if you do this for the __set_name__ check:
if inspect.ismethoddescriptor(self.default):
...an object like the one below will not get its __set_name__ called, even
though PEP 487 says it should:
class D:
def __set_name__(self, o, n):
self.name = n
class C:
d: int = D()
if __name__ == "__main__":
print(f"C.d.name = {C.d.name}") # __set_name__ was called
assert inspect.ismethoddescriptor(C.d) # Error
--
___
Python tracker
<https://bugs.python.org/issue33141>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33141] descriptor __set_name__ feature broken for dataclass descriptor fields
Rick Teachey added the comment: Yeah and I think lines 2709-2712 of TestDescriptors also needs removed. -- ___ Python tracker <https://bugs.python.org/issue33141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33141] descriptor __set_name__ feature broken for dataclass descriptor fields
Rick Teachey added the comment: Looks great to me. Thanks! -- ___ Python tracker <https://bugs.python.org/issue33141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError
New submission from Rick Teachey : I'm getting the following error at when attempting to create a new `dataclass` with any base class that is supplied a type variable: TypeError: type() doesn't support MRO entry resolution; use types.new_class() In principle, it seems like this shouldn't cause any problems, since this works as expected: @dataclass class MyClass(Generic[MyTypeVar]): pass The problem seems to be the call to `type` in `make_dataclass` for instantiating the class object, since `type` doesn't support type variables. If I replace the `dataclass` line that produces the error with the following code block, it seems to work: try: cls = type(cls_name, bases, namespace) except TypeError: cls = types.new_class(cls_name, bases, namespace) I haven't tested, but it might be possible to just remove the call to `type` altogether. I've attached a file demonstrating the issue. -- components: Library (Lib) files: dataclass_metaclass_issue.py messages: 314703 nosy: Ricyteach, eric.smith priority: normal severity: normal status: open title: dataclass MRO entry resolution for type variable metaclasses: TypeError type: behavior versions: Python 3.7, Python 3.8 Added file: https://bugs.python.org/file47508/dataclass_metaclass_issue.py ___ Python tracker <https://bugs.python.org/issue33188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError
Rick Teachey added the comment: Sorry: to be clear, the error only occurs when attempting to create the class using `make_dataclass`. -- ___ Python tracker <https://bugs.python.org/issue33188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError
Rick Teachey added the comment:
Same error on 3.7.
Probably getting beyond my knowledge here but from the error message, it seems
like the answer is simply that:
type('MyChild', (MyParent[int],), {})
...is just the wrong way to make a new `type` when utilizing type variables.
--
___
Python tracker
<https://bugs.python.org/issue33188>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33190] problem with ABCMeta.__prepare__ when called after types.new_class
New submission from Rick Teachey : I am pretty sure this is a bug. If not I apologize. Say I want to dynamically create a new `C` class, with base class `MyABC` (and dynamically assigned abstract method `m`). This works fine if I use `type`, but if I use `new_class`, the keyword argument to the `m` method implementation gets lost somewhere in the call to `ABCMeta.__prepare___`. I've attached a file to demo. Thanks. -- components: Library (Lib) files: abcmeta_prepare.py messages: 314714 nosy: Ricyteach, levkivskyi priority: normal severity: normal status: open title: problem with ABCMeta.__prepare__ when called after types.new_class type: behavior versions: Python 3.7, Python 3.8 Added file: https://bugs.python.org/file47509/abcmeta_prepare.py ___ Python tracker <https://bugs.python.org/issue33190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33190] problem with ABCMeta.__prepare__ when called after types.new_class
Rick Teachey added the comment: Excellent; thank you very much for the explanation. I have never done a PR on a project this size but I'll give it a try. -- ___ Python tracker <https://bugs.python.org/issue33190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError
Rick Teachey added the comment: Eric: see also Ivan's comment on Issue 33190, which will factor into the solution to this I think. It seems you can't just pass the `namespace` to the `kwds` argument (as I have done in my solution above). -- ___ Python tracker <https://bugs.python.org/issue33188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError
Rick Teachey added the comment:
> passing keyword arguments to metaclass will be much more rare for dataclasses
> than passing a ready namespace
The impetus of my running into these issues was assuming that things like
`Generic[MyTypeVar]` would "just work" with `make_dataclass`, which seemed like
a valid assumption since the class creation approach made heavy use of by
`dataclasses` implies this:
@dataclass
class MyDclass(Generic[MyTypeVar]):
var: MyTypeVar
The fact that I cannot do this, then, without error is surprising:
MyDclass = make_dataclass("MyDclass", (("var", MyTypeVar),),
bases=(Generic[MyTypeVar],))
I'm not stating it HAS to be fixed. Maybe it doesn't have to. But to me, the
above seems like the reason to do it if it's going to be done.
--
___
Python tracker
<https://bugs.python.org/issue33188>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError
Rick Teachey added the comment: I'll also say: one of the biggest reasons I was excited to read the `dataclasses` PEP was because I thought "AWESOME! Now I can delete all of the stupid boilerplate __init__ and __repr__ methods for those `typing.Sequences`, `typing.Mapping`, etc etc subclasses!" -- ___ Python tracker <https://bugs.python.org/issue33188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33190] problem with ABCMeta.__prepare__ when called after types.new_class
Change by Rick Teachey : -- keywords: +patch pull_requests: +6033 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33190] problem with ABCMeta.__prepare__ when called after types.new_class
Rick Teachey added the comment: Thank you; I gave it a go. Hopefully didn't cause too much additional work for someone. -- ___ Python tracker <https://bugs.python.org/issue33190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33328] pdb error when stepping through generator
New submission from Rick Teachey : Hello: The attached python file runs a pdb interactive session for a generator. It produces an error in Python 3.7 Beta 3, but no error in 3.6. I searched for this issue and there do seem to be things that are related to it already, but I haven't investigated the cause of this issue and am not acquainted with the details of the pdb module, so I was unable to determine whether previous reports discuss this same problem. -- files: demo.py messages: 315586 nosy: Ricyteach priority: normal severity: normal status: open title: pdb error when stepping through generator versions: Python 3.7 Added file: https://bugs.python.org/file47545/demo.py ___ Python tracker <https://bugs.python.org/issue33328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33328] pdb error when stepping through generator
Rick Teachey added the comment: The interactive session result is below: GeneratorExit Exception ignored in: Traceback (most recent call last): File "C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\types.py", line 27, in _ag File "C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\bdb.py", line 90, in trace_dispatch File "C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\bdb.py", line 128, in dispatch_call File "C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\bdb.py", line 250, in break_anywhere File "C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\bdb.py", line 49, in canonic AttributeError: 'NoneType' object has no attribute 'abspath' -- ___ Python tracker <https://bugs.python.org/issue33328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33328] pdb error when stepping through generator
Change by Rick Teachey : -- components: +Library (Lib) type: -> behavior ___ Python tracker <https://bugs.python.org/issue33328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33328] pdb error when stepping through generator
Rick Teachey added the comment: I am on Anaconda 4.5.1 on Windows 10 (Python 3.6.5). I have confirmed that I DO get the error on another machine with the same version installed, so the lack of an error seems specific to my current machine. I do not know what could be causing this; it is very odd. -- ___ Python tracker <https://bugs.python.org/issue33328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33328] pdb error when stepping through generator
Rick Teachey added the comment: Closed as duplicate of issue 13044. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33452] add user notification that parent init will not be called in dataclass init method
New submission from Rick Teachey : The dataclasses module is incredibly easy to use. This is a good thing. BUT one downside is it will definitely be utilized by people who don't have a thorough understanding of how it does what it does. Even for me, despite having a very good understanding of how it works, after heavily using it on a project for about 3 weeks now I made a mistake like the one below: class ImportantMixin: def __init__(self): super().__init__() important_task() @dataclass class NaiveDClass(ImportantMixin): data1 = int data2 = int I then went on along my merry way. Obviously, ImportantMixin.__init__ never gets called and I didn't realize this until it was a bigger problem than it should have been (should have written better tests! but I digress). It would seem like a good idea for the dataclasses module to let the user know they did this, probably via the warning system. Seems like it would be relatively easy to do: if there is an init method being create, just inspect the MRO for any previously defined init methods that weren't created by dataclasses. Thanks. -- components: Library (Lib) messages: 316331 nosy: Ricyteach, eric.smith priority: normal severity: normal status: open title: add user notification that parent init will not be called in dataclass init method type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue33452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33453] from __future__ import annotations breaks dataclasses ClassVar handling
New submission from Rick Teachey :
This is broken in 3.7 (both beta 3 and 4):
from __future__ import annotations
from dataclasses import dataclass
from typing import ClassVar, Any
@dataclass
class C():
class_var: ClassVar[Any] = object()
data: str
Traceback:
Traceback (most recent call last):
File "", line 1, in
File
"C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\dataclasses.py",
line 850, in dataclass
return wrap(_cls)
File
"C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\dataclasses.py",
line 842, in wrap
return _process_class(cls, init, repr, eq, order, unsafe_hash, frozen)
File
"C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\dataclasses.py",
line 763, in _process_class
else 'self',
File
"C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\dataclasses.py",
line 442, in _init_fn
raise TypeError(f'non-default argument {f.name!r} '
TypeError: non-default argument 'data' follows default argument
--
components: Library (Lib)
messages: 316333
nosy: Ricyteach, eric.smith
priority: normal
severity: normal
status: open
title: from __future__ import annotations breaks dataclasses ClassVar handling
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue33453>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33453] from __future__ import annotations breaks dataclasses ClassVar handling
Rick Teachey added the comment: To be clear: it works just fine with the annotations import. -- ___ Python tracker <https://bugs.python.org/issue33453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33453] from __future__ import annotations breaks dataclasses ClassVar handling
Rick Teachey added the comment: Sorry, mean to say it works just fine *without* the import. -- ___ Python tracker <https://bugs.python.org/issue33453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33452] add user notification that parent init will not be called in dataclass init method
Rick Teachey added the comment:
The init method that comes up for int, str, float, etc is just the object init:
assert int.__init__ is object.__init__
Probably the thing to do is grab any init methods that aren't the
object.__init__ while stripping out the dataclass-created init methods? Maybe
something like:
import warnings
if cls.__dataclass_params__.init:
for pcls in cls.mro():
if pcls.__init__ is not object.__init__:
try:
d_params = getattr(pcls, "__dataclass_params__")
except AttributeError:
warnings.warn('Found a not called init')
else:
if not d_params.init:
warnings.warn('Found a custom dataclass init')
--
___
Python tracker
<https://bugs.python.org/issue33452>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling
Rick Teachey added the comment: > Is there any scenario where the following code would be useful... Perhaps if someone, in search of a speedup, were sort of rolling their own lighter-weight equivalent to the typing module (in order to avoid importing the full typing module), but duck typed enough to fool the average type checker? Is that possible? -- ___ Python tracker <https://bugs.python.org/issue33453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling
Rick Teachey added the comment: Lending my voice to the suggestion of limiting the class attribute check to `typing.ClassVar` and `ClassVar`. It can always be expanded later if it is needed. -- ___ Python tracker <https://bugs.python.org/issue33453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14470] Remove using of w9xopen in subprocess module
Rick Rune added the comment: Removed w9xpopen usage in subprocess module via attached patch. -- keywords: +patch nosy: +Rune Added file: http://bugs.python.org/file25296/subprocess_minus_w9xpopen.patch ___ Python tracker <http://bugs.python.org/issue14470> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8970] Tkinter Litmus Test
New submission from Rick Johnson : There has been much discussion in the past and recently on c.l.p about how many python programmers *actually* use Tkinter. Recently i have been involved in a lengthy discussion on c.l.p about whether or not we should remove Tkinter, replace Tkinter, or fix Tkinter. However i feel a decision this important cannot be made from pydev, c.l.p, or anywhere. I believe the only proper way to proceed is to get a *real* vote from *real* python programmers out in the trenches. But how do we do that you may ask? Well thats a good question. Not every Python programmer lives on c.l.p, or any *one* place. The only way to truly reach everyone is thru Python itself in form of a Warning message. So i propose that an import warning be added to the next possible releases of Python 3.x and Python 3.x. This warning will be triggered upon importing Tkinter and should also be shown when starting IDLE. The message should read loosely as follows... """ - ModuleRemovalWarning: Tkinter (and dependencies) - The Tkinter module (Python's GUI module) is currently being considered for removal from the python stdlib FOREVER. We are providing this warning so that you can give the python devlopment team (and the wider community) your input on the subject. If you feel that Tkinter should or should not be removed we strongly incurage you to voice your opinion. You can do by casting your vote at "www.savetkinter.com". Whether your a complete noobie or a seasoned Pythonista we need to hear everyone. Voting will end on MM-DD-, so make sure your vote is counted! """ -- components: IDLE, Tkinter messages: 107531 nosy: rantingrick priority: normal severity: normal status: open title: Tkinter Litmus Test type: feature request versions: Python 2.7, Python 3.3 ___ Python tracker <http://bugs.python.org/issue8970> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8971] Tkinter Litmus Test
New submission from Rick Johnson : There has been much discussion in the past and recently on c.l.p about how many python programmers *actually* use Tkinter. Recently i have been involved in a lengthy discussion on c.l.p about whether or not we should remove Tkinter, replace Tkinter, or fix Tkinter. However i feel a decision this important cannot be made from pydev, c.l.p, or anywhere. I believe the only proper way to proceed is to get a *real* vote from *real* python programmers out in the trenches. But how do we do that you may ask? Well thats a good question. Not every Python programmer lives on c.l.p, or any *one* place. The only way to truly reach everyone is through Python itself in form of a Warning message. So i propose that an import warning be added to the next possible releases of Python 2.x and Python 3.x. This warning will be triggered upon importing Tkinter and should also be shown when starting IDLE. The message should read loosely as follows... """ - ModuleRemovalWarning: Tkinter (and dependencies) - The Tkinter module (Python's GUI module) is currently being considered for removal from the python stdlib FOREVER. We are providing this warning so that you can give the python development team (and the wider community) your feedback on the subject. If you feel that Tkinter should or should not be removed we strongly encourage you to voice your opinion. You can do by casting your vote at "www.savetkinter.com". We need to hear everyone whether your a complete newbie or a seasoned Pythonista. Voting will end on MM-DD- so make sure your vote is counted! """ -- components: IDLE, Tkinter messages: 107532 nosy: rantingrick priority: normal severity: normal status: open title: Tkinter Litmus Test type: feature request versions: Python 2.7, Python 3.3 ___ Python tracker <http://bugs.python.org/issue8971> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8970] Tkinter Litmus Test
Changes by Rick Johnson : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue8970> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1675951] [gzip] Performance for small reads and fix seek problem
Rick Harris added the comment: Are compatibility concerns the main reason this patch has yet to be applied? If so, could we allay those fears by keeping the default seek-y behavior and only introducing the new seek-less style when a 'noseek' flag is passed? -- nosy: +rharris ___ Python tracker <http://bugs.python.org/issue1675951> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23532] regex "|" behavior differs from documentation
Changes by Rick Otten : -- components: Regular Expressions nosy: Rick Otten, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: regex "|" behavior differs from documentation type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue23532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23532] regex "|" behavior differs from documentation
New submission from Rick Otten:
The documentation states that "|" parsing goes from left to right. This
doesn't seem to be true when spaces are involved. (or \s).
Example:
In [40]: mystring
Out[40]: 'rwo incorporated'
In [41]: re.sub('incorporated| inc|llc|corporation|corp| co', '', mystring)
Out[41]: 'rwoorporated'
In this case " inc" was processed before incorporated.
If I take the space out:
In [42]: re.sub('incorporated|inc|llc|corporation|corp| co', '', mystring)
Out[42]: 'rwo '
incorporated is processed first.
If I put a space with each, then " incorporated" is processed first:
In [43]: re.sub(' incorporated| inc|llc|corporation|corp| co', '', mystring)
Out[43]: 'rwo'
And If use \s instead of a space, it is processed first:
In [44]: re.sub('incorporated|\sinc|llc|corporation|corp| co', '', mystring)
Out[44]: 'rwoorporated'
--
___
Python tracker
<http://bugs.python.org/issue23532>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23532] regex "|" behavior differs from documentation
Rick Otten added the comment: Can the documentation be updated to make this more clear? I see now where the clause "As the target string is scanned, ..." is describing what you have listed here. I and a coworker both read the description several times and missed that. I thought it first tried "incorporated" against the whole string, then tried " inc" against the whole string, etc... When actually it was trying each, "incorporated" and " inc" and the others against the first position of the string. And then again for the second position. Since I want to force the order against the whole string before trying the next one for my particular use case, I'll do a series of re.subs instead of trying to do them all in one. It makes sense now and is easy to fix. Thanks for looking at it and explaining what is happening more clearly. It was really not obvious. I tried at least 100 variations and wasn't seeing the pattern. -- ___ Python tracker <http://bugs.python.org/issue23532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39637] Probably incorrect message after failed import
New submission from Rick van Rein : The following error message surprises me: >>> import os.environ Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'os.environ'; 'os' is not a package Shouldn't that say that "'environ' is not a package" instead? After all, 'os' will support >>> import os.path >>> This is confusing :) -- components: Interpreter Core messages: 362011 nosy: vanrein priority: normal severity: normal status: open title: Probably incorrect message after failed import versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue39637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39637] Probably incorrect message after failed import
Rick van Rein added the comment: Thanks for explaining. It is indeed confusing, even though I'm quite experienced with Python. -- ___ Python tracker <https://bugs.python.org/issue39637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39637] Probably incorrect message after failed import
Change by Rick van Rein : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42620] documentation on `getsockname()` wrong for AF_INET6
New submission from Rick van Rein :
Shown in the session below is unexpected output of a 4-tuple from an AF_INET6
socket along with documentation that *suggests* to expect a 2-tuple. The
phrasing "IP" might have to be toned down to "IPv4" or "AF_INET" to be accurate
enough to avoid confusion.
Opinion: I think you should be explicit about the different behaviour for
AF_INET6, so it is not reduced to a special/nut case for special interest
groups. IPv6 has a hard enough time getting in; different formats for AF_INET
and AF_INET6 should ideally be shown to all programmers, to at least avoid
*uninformed* decisions to be incompatible with IPv6 while they develop on an
IPv4 system (and the same in the opposite direction).
Python 3.7.3 (default, Jul 25 2020, 13:03:44)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> sox6 = socket.socket (socket.AF_INET6)
>>> sox6.getsockname ()
('::', 0, 0, 0)
>>> sox6.getsockname.__doc__
'getsockname() -> address info\n\nReturn the address of the local endpoint.
For IP sockets, the address\ninfo is a pair (hostaddr, port).'
--
components: Library (Lib)
messages: 382863
nosy: vanrein
priority: normal
severity: normal
status: open
title: documentation on `getsockname()` wrong for AF_INET6
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue42620>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42620] documentation on `getsockname()` wrong for AF_INET6
Rick van Rein added the comment: Excellent, thanks. I personally would appreciate if a remark about IPv6 would also be made. -- ___ Python tracker <https://bugs.python.org/issue42620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31725] Turtle/tkinter: NameError crashes ipython with "Tcl_AsyncDelete: async handler deleted by the wrong thread"
New submission from Rick J. Pelleg :
On Windows 10 Education, ran:
ipython
Python 3.6.3 (v3.6.3:2c5fed8, Oct 3 2017, 17:26:49) [MSC v.1900 32 bit (Intel)]
Type 'copyright', 'credits' or 'license' for more information
IPython 6.2.1 -- An enhanced Interactive Python. Type '?' for help.
After "from turtle import *" and several simple turtle commands:
In [36]: fill()
---
NameError Traceback (most recent call last)
in ()
> 1 fill()
NameError: name 'fill' is not defined
Tcl_AsyncDelete: async handler deleted by the wrong thread
Exception ignored in: >
Traceback (most recent call last):
File
"d:\users\yuval\appdata\local\programs\python\python36-32\lib\tkinter\__init__.py",
line 3501, in __del__
self.tk.call('image', 'delete', self.name)
--
components: Tkinter
messages: 303898
nosy: Rick J. Pelleg
priority: normal
severity: normal
status: open
title: Turtle/tkinter: NameError crashes ipython with "Tcl_AsyncDelete: async
handler deleted by the wrong thread"
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue31725>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31725] Turtle/tkinter: NameError crashes ipython with "Tcl_AsyncDelete: async handler deleted by the wrong thread"
Rick J. Pelleg added the comment: Mmm... right now I cannot reproduce at all, both in iPython and in python. Will continue to try. -- ___ Python tracker <https://bugs.python.org/issue31725> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31725] Turtle/tkinter: NameError crashes ipython with "Tcl_AsyncDelete: async handler deleted by the wrong thread"
Rick J. Pelleg added the comment: Sorry, all reproduction attempts failed, both in plain Python and in iPython. I guess you can close this for now. -- ___ Python tracker <https://bugs.python.org/issue31725> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31725] Turtle/tkinter: NameError crashes ipython with "Tcl_AsyncDelete: async handler deleted by the wrong thread"
Rick J. Pelleg added the comment: Just one more issue: since it happened before I found out that the "turtle" package already has the pre-defined short version of commands, such as "fd()", "lt()", etc., the crashed session included four function definitions, for "fd()", "bk()", "lt()" and "rt()", in the form of: def fd(val): forward(val) -- ___ Python tracker <https://bugs.python.org/issue31725> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31725] Turtle/tkinter: NameError crashes ipython with "Tcl_AsyncDelete: async handler deleted by the wrong thread"
Rick J. Pelleg added the comment: Thanks! On Sat, Jun 16, 2018, 18:53 Carol Willing wrote: > > Carol Willing added the comment: > > Hi Rick, > > I'm closing this issue as not reproducible. Thanks for filing it and using > Turtle. > > -- > nosy: +willingc > resolution: -> not a bug > stage: -> resolved > status: open -> closed > > ___ > Python tracker > <https://bugs.python.org/issue31725> > ___ > -- ___ Python tracker <https://bugs.python.org/issue31725> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
