Re: annotations cause dataclass fields type side effects

> On 9 Aug 2021, at 19:28, Lukas Lösche wrote: > > I'm on Python 3.9.6 and trying to make sense of the following behaviour: > from dataclasses import dataclass, fields @dataclass > ... class Foobar: > ... name: str > ... fields(Foobar)[0].type >

annotations cause dataclass fields type side effects

I'm on Python 3.9.6 and trying to make sense of the following behaviour: >>> from dataclasses import dataclass, fields >>> @dataclass ... class Foobar: ... name: str ... >>> fields(Foobar)[0].type >>> type(fields(Foobar)[0].type) >>> from __future__ import annotations >>> from dataclasses

[issue44390] PC/frozen_dllmain.c, some expressions have no side effects

status: open title: PC/frozen_dllmain.c, some expressions have no side effects type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue44390> ___ ___

[issue43963] test_interpreters has side effects on test_signal

r has no longer side effects.", however I believe it should be "Importing the signal module in a subinterpreter no longer has side effects". The only difference is that "has" is moved after "no longer" instead of before. -- nosy: +Theelgirl __

[issue43963] test_interpreters has side effects on test_signal

STINNER Victor added the comment: New changeset a5e6e6df7d1d498576bab26deaddc288a7bd by Victor Stinner in branch 'master': bpo-43963: Add _signal module state (GH-25676) https://github.com/python/cpython/commit/a5e6e6df7d1d498576bab26deaddc288a7bd --

[issue43963] test_interpreters has side effects on test_signal

Change by STINNER Victor : -- pull_requests: +24367 pull_request: https://github.com/python/cpython/pull/25676 ___ Python tracker ___

[issue43963] test_interpreters has side effects on test_signal

Change by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue43963] test_interpreters has side effects on test_signal

STINNER Victor added the comment: New changeset a09766deab5aff549f40f27080895e148af922ed by Victor Stinner in branch 'master': bpo-43963: Fix import _signal in subinterpreters (GH-25674) https://github.com/python/cpython/commit/a09766deab5aff549f40f27080895e148af922ed --

[issue43963] test_interpreters has side effects on test_signal

STINNER Victor added the comment: This issue is a follow-up of bpo-41713: commit 7f9b25a21ab95f8cf8d663396993766307be475c Author: Victor Stinner Date: Tue Nov 17 23:28:25 2020 +0100 bpo-41713: Port _signal module to multi-phase init (GH-23355) Port the _signal extension

[issue43963] test_interpreters has side effects on test_signal

STINNER Victor added the comment: See also bpo-43955: "Windows: Running the Python test suite sequentially is interrupted by (Pdb) prompt". -- ___ Python tracker ___

[issue43963] test_interpreters has side effects on test_signal

Change by STINNER Victor : -- keywords: +patch pull_requests: +24365 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25674 ___ Python tracker ___

[issue43963] test_interpreters has side effects on test_signal

STINNER Victor added the comment: See also bpo-43962: "test_interpreters: when TestInterpreterAttrs.test_id_type() is run alone, it fails with an assertion error". -- ___ Python tracker

[issue43963] test_interpreters has side effects on test_signal

ms Tests result: FAILURE -- components: Tests messages: 392147 nosy: vstinner priority: normal severity: normal status: open title: test_interpreters has side effects on test_signal versions: Python 3.10 ___ Python tracker <https://bugs.py

Re: Having trouble with Mock and exception side effects

seException > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): > File "test_case.py", line 23, in > except package.module.MyException: > TypeError: catching classes that do not inherit from BaseExcepti

Having trouble with Mock and exception side effects

g handling of the above exception, another exception occurred: Traceback (most recent call last): File "test_case.py", line 23, in except package.module.MyException: TypeError: catching classes that do not inherit from BaseException is not allowed This is also causing problems f

[issue31676] test.test_imp.ImportTests.test_load_source has side effects

STINNER Victor added the comment: I tested "./python -m test -uall -M4G test_imp test_cgitb" on 3.6 and the master branch. Both tests now pass correctly. I close the issue. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed

[issue31676] test.test_imp.ImportTests.test_load_source has side effects

Mariatta Wijaya added the comment: New changeset 178148025494c4058571831fb11fc8eeff8b7365 by Mariatta (Miss Islington (bot)) in branch '3.6': bpo-31676: Fix test_imp.test_load_source() side effect (GH-3871) (GH-3988)

[issue31676] test.test_imp.ImportTests.test_load_source has side effects

Change by STINNER Victor : -- versions: +Python 3.6 ___ Python tracker ___ ___

[issue31676] test.test_imp.ImportTests.test_load_source has side effects

Change by Roundup Robot : -- pull_requests: +3964 ___ Python tracker ___

[issue31676] test.test_imp.ImportTests.test_load_source has side effects

STINNER Victor added the comment: New changeset a505ecdc5013cd8f930aacc1ec4fb2afa62d3853 by Victor Stinner in branch 'master': bpo-31676: Fix test_imp.test_load_source() side effect (#3871)

[issue31676] test.test_imp.ImportTests.test_load_source has side effects

Brett Cannon added the comment: The whole imp module is deprecated so I'm personally not bothered by imp.load_source() not being strengthened to be more sane. -- ___ Python tracker

[issue31676] test.test_imp.ImportTests.test_load_source has side effects

Change by STINNER Victor : -- keywords: +patch pull_requests: +3849 stage: -> patch review ___ Python tracker ___

[issue31676] test.test_imp.ImportTests.test_load_source has side effects

STINNER Victor added the comment: Attached PR 3871 fixes the side effect in test_imp, but I'm not sure that it's the best fix. Maybe load_source() should use a "transaction" to restore attributes on failure? load_source() seems to be used imp.reload() for example.

[issue31676] test.test_imp.ImportTests.test_load_source has side effects

Change by STINNER Victor <victor.stin...@gmail.com>: -- nosy: +brett.cannon, eric.snow, ncoghlan title: Strange failure in test_cgitb -> test.test_imp.ImportTests.test_load_source has side effects versions: +Python 3.7 ___ Python tra

[issue11063] uuid.py module import has heavy side effects

STINNER Victor added the comment: I marked bpo-20519 as a duplicate of this issue, even if it's not exactly the same. The main purpose of this issue was to use uuid_generate_time() using a C extension: +static PyObject * +_uuid_generate_random(void) +{ +uuid_t

[issue11063] uuid.py module import has heavy side effects

STINNER Victor added the comment: I marked bpo-5885 as a duplicate of this issue, even if it's not exactly the same. The main purpose of this issue was to use uuid_generate_time() using a C extension, as bpo-20519. +static PyObject * +uuid_uuid1(PyObject *self,

[issue11063] uuid.py module import has heavy side effects

Antoine Pitrou added the comment: PR 3684 seems mostly a subset of what I'm proposing. -- ___ Python tracker ___

[issue11063] uuid.py module import has heavy side effects

STINNER Victor added the comment: Oh. I was told that the PR 3684 of bpo-5885 in another fix for this issue. -- ___ Python tracker

[issue11063] uuid.py module import has heavy side effects

Antoine Pitrou added the comment: > I would prefer to reorganize uuid.py in a second step I am not reorganizing uuid.py, just making initialization lazy. -- ___ Python tracker

[issue11063] uuid.py module import has heavy side effects

INADA Naoki added the comment: >> Sorry, I reject my idea. It clearly overdone. uuid.py is not so huge. > Can you please elaborate? Do you think that my PR is wrong? I looked https://github.com/python/cpython/pull/3684 and I wonder if I should recommend to split

[issue11063] uuid.py module import has heavy side effects

STINNER Victor added the comment: It's nice to see things moving in this 6 years old issue :-) -- ___ Python tracker ___

[issue11063] uuid.py module import has heavy side effects

STINNER Victor added the comment: Antoine: "I think https://github.com/python/cpython/pull/3796 is a better resolution. It creates an optional _uuid C extension to avoid ctypes if possible *and* also loads system functions lazily." Implementing bpo-20519 is a very

[issue11063] uuid.py module import has heavy side effects

Antoine Pitrou added the comment: And on Windows, _windll_getnode() calls into _UuidCreate(). -- ___ Python tracker ___

[issue11063] uuid.py module import has heavy side effects

Antoine Pitrou added the comment: > Do you know a native APIs for Windows and Linux? On Linux, we already use uuid_generate_time(). See _unixdll_get_node(). -- ___ Python tracker

[issue11063] uuid.py module import has heavy side effects

native API's in a different issue and focus on avoiding "side effects" on "import uuid" in this issue. Do you know a native APIs for Windows and Linux? I don't. Do you have links to these "recipes"? If yes, please open a new issue. -- _

[issue11063] uuid.py module import has heavy side effects

Antoine Pitrou added the comment: I think https://github.com/python/cpython/pull/3796 is a better resolution. It creates an optional _uuid C extension to avoid ctypes if possible *and* also loads system functions lazily. -- versions: -Python 3.8

[issue11063] uuid.py module import has heavy side effects

STINNER Victor added the comment: uuid code contains 4 bare "except:" blocks which should be replaced with appropriate exceptions, or at least "except Exception:" to not catch KeyboardInterrupt. But this should be modified in a second time. --

[issue11063] uuid.py module import has heavy side effects

Change by Antoine Pitrou : -- pull_requests: +3780 ___ Python tracker ___ ___

[issue11063] uuid.py module import has heavy side effects

k that this PEP is needed here. IMHO a new _uuid1 module is enoguh to avoid "side effects" on "import uuid". > Sorry, I reject my idea. It clearly overdone. uuid.py is not so huge. Can you please elaborate? Do you think that my

[issue11063] uuid.py module import has heavy side effects

Change by STINNER Victor : -- pull_requests: +3779 ___ Python tracker ___ ___

[issue11063] uuid.py module import has heavy side effects

Change by Christian Heimes : -- versions: +Python 3.7, Python 3.8 -Python 3.5 ___ Python tracker ___

[issue11063] uuid.py module import has heavy side effects

INADA Naoki added the comment: Sorry, I reject my idea. It clearly overdone. uuid.py is not so huge. -- versions: +Python 3.5 -Python 3.7 ___ Python tracker

[issue11063] uuid.py module import has heavy side effects

Change by Antoine Pitrou : -- versions: +Python 3.7 -Python 3.5 ___ Python tracker ___ ___

[issue11063] uuid.py module import has heavy side effects

INADA Naoki added the comment: How often uuid1 is used? I never use it and it looks uuid1 makes uuid.py complicated. How about split it to _uuid1.py (or uuid/__init__.py and uuid/_uuid1.py)? I hope PEP 562 is accepted. It ease splitting out (heavy and slow and dirty)

[issue29645] webbrowser module import has heavy side effects

Serhiy Storchaka added the comment: New changeset a7cba27aea13837e2ab1d91584efcfeac4ec by Serhiy Storchaka in branch 'master': bpo-29645: Speed up importing the webbrowser module. (#484) https://github.com/python/cpython/commit/a7cba27aea13837e2ab1d91584efcfeac4ec --

[issue29645] webbrowser module import has heavy side effects

Changes by Larry Hastings : -- pull_requests: +626 ___ Python tracker ___ ___

[issue29645] webbrowser module import has heavy side effects

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue29645] webbrowser module import has heavy side effects

Changes by Serhiy Storchaka : -- pull_requests: +397 ___ Python tracker ___ ___

[issue29645] webbrowser module import has heavy side effects

Terry J. Reedy added the comment: This will help IDLE startup (though webbrowser should not be imported on windows, where os.startfile is used instead). This is a somewhat separate issue, but should the Windows code be modified for Win10 and Microsoft Edge? -- nosy: +terry.reedy

[issue29645] webbrowser module import has heavy side effects

Serhiy Storchaka added the comment: The new GitHub PR workflow still looks cumbersome and unclear to me. It needs using a lot of git commands different for different branches (and some command are failed or don't work as I expected when I try to repeat sequences from the devguide). How to

[issue29645] webbrowser module import has heavy side effects

Nick Coghlan added the comment: Patch LGTM. Serhiy, did you want to take this as a chance to run through the new GitHub PR workflow? Current details are at https://docs.python.org/devguide/pullrequest.html -- ___ Python tracker

[issue29645] webbrowser module import has heavy side effects

Serhiy Storchaka added the comment: Added tests. -- Added file: http://bugs.python.org/file46670/webbrowser-delayed-initialization-2.patch ___ Python tracker

[issue29645] webbrowser module import has heavy side effects

Nick Coghlan added the comment: Nice, this is much cleaner than the current approach! The one thing I would suggest is a new test case that: - asserts webbrowser._tryorder is None - asserts webbrowser._browsers is empty - calls webbrowser.get() - asserts webbrowser._tryorder is non-empty -

[issue29645] webbrowser module import has heavy side effects

Serhiy Storchaka added the comment: > What is the different of Cold start and Hot start? Disk caches are dropped before cold start. $ echo 3 | sudo tee /proc/sys/vm/drop_caches -- ___ Python tracker

[issue29645] webbrowser module import has heavy side effects

Changes by Serhiy Storchaka : -- keywords: +patch Added file: http://bugs.python.org/file46667/webbrowser-delayed-initialization.patch ___ Python tracker

[issue29645] webbrowser module import has heavy side effects

Serhiy Storchaka added the comment: Following patch makes searching of all platform browsers delayed until it is needed. In addition it makes webbrowser.register() thread safe. Cold start: $ time ./python -c 'import webbrowser' real0m2.851s user0m0.224s sys 0m0.056s Hot start:

[issue29645] webbrowser module import has heavy side effects

Louie Lu added the comment: What is the different of Cold start and Hot start? It that CPU speed or something else. In Linux 4.9.11 with i7-2k, I can't reproduce the significant real time you gave: # CPU gov powersave $ time ./python -c 'import webbrowser' 0.16s user 0.02s system 93% cpu

[issue29645] webbrowser module import has heavy side effects

New submission from Serhiy Storchaka: `import webbrowser` has heavy side effects. It searches a number of executables. On X Window it also runs external program xdg-settings. Cold start: $ time ./python -c '' real0m1.719s user0m0.088s sys 0m0.036s $ time ./python -c 'import

[issue11063] uuid.py module import has heavy side effects

aixtools added the comment: The way I have seen that resolved - in many locations, is to have the option to specify a specific version, e.g., libFOO.so.1 and then as long as that version remains available, perhaps as read-only for running with existing programs,they continue to work even when

[issue11063] uuid.py module import has heavy side effects

Martin Panter added the comment: There is already Issue 20519 for that, although it looks like the proposed patch keeps ctypes as a fall-back. (My interest here is only theoretical.) -- ___ Python tracker

[issue11063] uuid.py module import has heavy side effects

Christian Heimes added the comment: It sounds like ctypes is causing you some headache. How about we get rid of ctypes for uuid and replace it with a simple implementation in C instead? Autoconf (configure) can take care of the library detection easily. --

[issue11063] uuid.py module import has heavy side effects

Martin Panter added the comment: The versioning problem with libFOO.so.N already occurs with compiled programs. A C program compiled against libuuid.so.1 will fail to load if you only have libuuid.so.2. On the other hand, a Python program using find_library() will find either version. My

[issue11063] uuid.py module import has heavy side effects

Michael Felt added the comment: I cannot comment on uuid directly, but for me, this is yet another example of how assumptions can break things. imho - if you know the exact version of s shared library that you want, calling cdll directly should be find. Maybe find_library is historic.

[issue11063] uuid.py module import has heavy side effects

Martin Panter added the comment: One thing I am wondering about is why we have to use find_library() at all. Wouldn’t it be more robust, and more efficient, to call CDLL() directly? We just have to know the exactly library version we are expecting. On Linux, the full soname is libuuid.so.1.

Re: (side-)effects and ...

On Sat, Jul 11, 2015 at 12:05 AM, Skip Montanaro skip.montan...@gmail.com wrote: I'm not sure about X-No-Html. A quick Google search for that header returned nothing useful. Yeah. At best it seems redundant - Hey look, there's no HTML in this message! - but I suspect it's mainly bragging I can

Re: (side-)effects and ...

On Thu, Jul 9, 2015 at 9:05 PM, Chris Angelico ros...@gmail.com wrote: Even if it respects that, there's no way that Mailman can know to respect his ridiculous copyright restriction. Well, sure. But Mailman is probably not alone in this regard. In case it wasn't clear from Tony the Tiger's

Re: (side-)effects and ...

On 07/09/2015 08:05 PM, Chris Angelico wrote: I thought so at first add well. It looks like the Mailman system handles the X-No-Archive and/or Archive headers. I couldn't find his name in this month's archive. Even if it respects that, there's no way that Mailman can know to respect his

Re: (side-)effects and ...

On Fri, Jul 10, 2015 at 9:27 AM, Skip Montanaro skip.montan...@gmail.com wrote: Also, he should not post here, because all articles posted here are automatically put on a mailing list and that list's web-accessible archive. I thought so at first add well. It looks like the Mailman system

Re: (side-)effects and ...

On Thu, Jul 9, 2015, at 15:36, Tony the Tiger wrote: On Sun, 05 Jul 2015 20:29:11 +, Stefan Ram wrote: X-Copyright: (C) Copyright 2015 Stefan Ram. All rights reserved. Distribution through any means other than regular usenet channels is forbidden. It is forbidden to publish this

Re: (side-)effects and ...

Also, he should not post here, because all articles posted here are automatically put on a mailing list and that list's web-accessible archive. I thought so at first add well. It looks like the Mailman system handles the X-No-Archive and/or Archive headers. I couldn't find his name in this

Re: (side-)effects and ...

And this is the intention of my post: Maybe there is such a term, and I just missed to learn it so far? So, do you know a term for the phenomenon that can be found in Python but not in mathematics and consists in the state of the world influencing the value of an expressions? In the

Re: (side-)effects and ...

In a message of 05 Jul 2015 20:29:11 +, Stefan Ram writes: But why do we not have a common and well-known term for the counterpart, that something does not modify the state of the world, but that the state of the world does influence the value (behaviour) of a call such as

Re: (side-)effects and ...

On 2015-07-06 00:44, Robert Kern wrote: I believe the term is idempotent No, idempotent means that if it changes the state, then applying it twice or more has the same effect as applying it once. Ah, thanks for the clarification. -tkc --

Re: (side-)effects and ...

On 07/05/2015 01:29 PM, Stefan Ram wrote: The function »datetime.datetime.now().time()« does not yield a value that is determined by the expression »time()«; instead its value can /differ/ between two calls even when the call »time()« does not differ. In mathematics, however, a

Re: (side-)effects and ...

On 2015-07-05 15:36, Tim Chase wrote: On 2015-07-05 20:29, Stefan Ram wrote: But why do we not have a common and well-known term for the counterpart, that something does not modify the state of the world, but that the state of the world does influence the value (behaviour) of a

Re: (side-)effects and ...

influencing the value of an expressions? The Pike optimizer short-cuts this by flagging such functions as have side effects. As far as optimizers are concerned, there's not a lot of difference between print() and time(); both of them need to be called every time they're written (unlike, for instance

Re: (side-)effects and ...

On 2015-07-05 21:36, Tim Chase wrote: On 2015-07-05 20:29, Stefan Ram wrote: But why do we not have a common and well-known term for the counterpart, that something does not modify the state of the world, but that the state of the world does influence the value (behaviour) of a call

Re: (side-)effects and ...

On 2015-07-05 20:29, Stefan Ram wrote: But why do we not have a common and well-known term for the counterpart, that something does not modify the state of the world, but that the state of the world does influence the value (behaviour) of a call such as

Re: (side-)effects and ...

On 7/5/2015 4:29 PM, Stefan Ram wrote: And this is the intention of my post: Maybe there is such a term, and I just missed to learn it so far? So, do you know a term for the phenomenon that can be found in Python but not in mathematics and consists in the state of the world

Re: (side-)effects and ...

On 07/05/2015 04:29 PM, Stefan Ram wrote: But why do we not have a common and well-known term for the counterpart, that something does not modify the state of the world, but that the state of the world does influence the value (behaviour) of a call such as

Side-effects [was Re: I am out of trial and error again Lists]

. There are large numbers of functions with side effects (mutator methods like list.append, anything that needs lots of state like random.random, everything with external effect like I/O, heaps of stuff), and it is most definitely not frowned upon. Hmmm. You might be overstating it a tad. You

Re: Side-effects [was Re: I am out of trial and error again Lists]

, but over all it prefers mutable state for compound objects, prefers immutable state for scalar objects (like numbers), and discourages the unnecessary use of global mutable state. It's not really compound vs scalar, but yes, I agree. Practicality beats purity, on so many levels. Functions with side

[issue11063] uuid.py module import has heavy side effects

Changes by Antoine Pitrou pit...@free.fr: -- nosy: +serhiy.storchaka stage: needs patch - patch review versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11063

[issue21882] turtledemo modules imported by test___all__ cause side effects or failures

Terry J. Reedy added the comment: I opened #22051 about removing reload to force better code. Since the tests are passing and I think the demo modules should be minimally tested by importing, and no one has said otherwise since the fix, I am closing this. -- resolution: - fixed

[issue21882] turtledemo modules imported by test___all__ cause side effects or failures

Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +jesstess ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21882 ___ ___ Python-bugs-list

[issue21882] turtledemo modules imported by test___all__ cause side effects or failures

Terry J. Reedy added the comment: I am working on the turtle demos now. Victor gave more info in #21884. I was partly wrong in my comments. turtledemo uses reload to re-initialize demos when one switches between them. I am tempted to remove this as part of discouraging side-effects on import

[issue21882] turtledemo modules imported by test___all__ cause side effects or failures

Roundup Robot added the comment: New changeset c173a34f20c0 by Terry Jan Reedy in branch '2.7': Issue #21882: In turtle demos, remove module scope gui and sys calls by http://hg.python.org/cpython/rev/c173a34f20c0 New changeset fcfa9c5a00fd by Terry Jan Reedy in branch '3.4': Issue #21882: In

[issue21882] turtledemo modules imported by test___all__ cause side effects or failures

Terry J. Reedy added the comment: 2. Done 3. I just removed the setrecursionlimit call, added for 3.0. I moved the colormixer sliders around for longer than anyone is likely to and it ran fine. 4. two-canvases works fine now. The extra window just has to be clicked away. 5. nim had a call to

[issue21882] turtledemo modules imported by test___all__ cause side effects or failures

Terry J. Reedy added the comment: The __all__ test now passes on Snow Leapard. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21882 ___ ___

[issue21882] turtledemo modules imported by test___all__ cause side effects or failures

New submission from Ned Deily: Although the turtledemo modules are not run directly during by make test or by python -m test -uall, they are currently being inadvertently imported by test___all__. This can lead to test failures and side effects because some of the turtledemo modules execute

[issue21882] turtledemo modules imported by test___all__ cause side effects or failures

Antoine Pitrou added the comment: 1. test___all__ should be changed to exclude turtledemo modules. Agreed. In general, the test suite shouldn't open any GUI windows except if the gui resource is enabled (which isn't the default). The turtledemo behaviour is quite new in that regard.

[issue21882] turtledemo modules imported by test___all__ cause side effects or failures

Terry J. Reedy added the comment: 6. Add 'good citizenship' note to demohelp.txt. Also point out that all turtle initialiazation should be in main anyway (see 2. and 3. below). Demo should run independently of what other demos do. re 2: If the mode call is needed, it is a bug that it is not

Re: Extracting lines from text files - script with a couple of 'side effects'

Hi, Thanks for the answers! And Dave, thanks for explaining the cause of the problem I will keep that in mind for the future. You're right, I am doing the search backward, it just seemed easier for me to do it in that way. Looks like I need to keep practising... Both your suggestions work, I

Extracting lines from text files - script with a couple of 'side effects'

, but with a couple of 'side effects' Here is my script: --- import re class Extractor(): def __init__(self,headers_file, fasta_file,output_file): with open(headers_file,'r') as inp0: counter0=0

Re: Extracting lines from text files - script with a couple of 'side effects'

the first. I have done a script which seems to work, but with a couple of 'side effects' Here is my script: --- import re class Extractor(): def __init__(self,headers_file, fasta_file,output_file

Re: Extracting lines from text files - script with a couple of 'side effects'

the first. I have done a script which seems to work, but with a couple of 'side effects' Here is my script: --- import re class Extractor(): def __init__(self,headers_file, fasta_file,output_file): with open(headers_file,'r

[issue11063] uuid.py module import has heavy side effects

Hynek Schlawack added the comment: Jyrki, roundup doesn’t seem to recognize you patch so we can’t review it in Rietveld. Could you re-try, maybe using hg? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11063

[issue11063] uuid.py module import has heavy side effects

Changes by Jyrki Pulliainen jy...@dywypi.org: Removed file: http://bugs.python.org/file29189/issue11063_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11063 ___

[issue11063] uuid.py module import has heavy side effects

Jyrki Pulliainen added the comment: Here's a second take on the patch -- Added file: http://bugs.python.org/file29220/issue11063_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11063

[issue11063] uuid.py module import has heavy side effects

Jyrki Pulliainen added the comment: The implementation does not actually end up in infinite loop, just repeating the loading of the CDLL is slow. I added caching to that and fixed the ctypes imports too. -- nosy: +nailor Added file: http://bugs.python.org/file29189/issue11063_2.patch

  1   2   >