py2exe output flagged as malware
I see this has happened to others in the past. I'm using 32 bit python 2.7.10 with py2exe 3.3 on windows 7. The exes work fine, but when I try to download into windows 10 I'm getting the exes immediately removed as malware. Is there any way to prevent this. It's very bad for python programs to get this kind of reputation. Anyone know if the same happens with PyInstaller etc etc? -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: py2exe output flagged as malware
On Wed, 28 Feb 2018 09:53:09 +, Robin Becker wrote: > I see this has happened to others in the past. I'm using 32 bit python > 2.7.10 with py2exe 3.3 on windows 7. The exes work fine, > but when I try to download into windows 10 I'm getting the exes > immediately removed as malware. > > Is there any way to prevent this. It's very bad for python programs to > get this kind of reputation. > > Anyone know if the same happens with PyInstaller etc etc? I would suggest you contact the Anti-virus vendor, Are you sure you have download a clean copy of py2exe. -- There are two ways to write error-free programs; only the third one works. -- https://mail.python.org/mailman/listinfo/python-list
Re: Questions about `locals` builtin
On Wed, 28 Feb 2018 18:04:11 +1100, Chris Angelico wrote: > On Wed, Feb 28, 2018 at 5:54 PM, dieter wrote: [...] >> I am still working with Python 2 (Python 3 may behave differently). >> There, during debugging, I would sometimes like to change the value of >> variables (I know that the variable has got a wrong value and would >> like to fix it to continue senseful debugging without a restart). This >> works for variables not yet known inside the function but does not work >> for true local variables. >> I assume that this is one effect of the "locals()" restriction. >> >> > That seems like a hairy thing to do, honestly. Well, yeah, but it is during debugging, not production code. > But if you know that > there's only a handful of variables that you'd actually want to do that > to, you can simply put those into an object of some form, and then > mutate that object. o_O If I knew ahead of time which variables held the wrong value, I'd fix them so they held the right value ahead of time, and not bother using a debugger. :-) -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Questions about `locals` builtin
On Wed, 28 Feb 2018 18:01:42 +1100, Chris Angelico wrote:
> If you really want a list of ALL the local names in a function, you can
> look at its __code__ object, which has a tuple of variable names:
>
> print(func1.__code__.co_varnames)
>
> That information is static to the function, as it is indeed determined
> when the function is compiled.
Ho ho ho, not in Python 2 it isn't!!!
py> def bizarre():
... x = 1
... from math import * # oww my aching head!
... print 'sin' in locals()
... print sin
...
:1: SyntaxWarning: import * only allowed at module level
py> bizarre()
True
py> bizarre.__code__.co_varnames
('x',)
In Python 2, you can also use exec inside a function, for extra
obfuscatory goodness.
Python 3 locks down these loopholes, and ensures that locals inside
functions can be statically determined.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
Re: Questions about `locals` builtin
On Wed, Feb 28, 2018 at 10:58 PM, Steven D'Aprano wrote: > On Wed, 28 Feb 2018 18:04:11 +1100, Chris Angelico wrote: >> But if you know that >> there's only a handful of variables that you'd actually want to do that >> to, you can simply put those into an object of some form, and then >> mutate that object. > > o_O > > If I knew ahead of time which variables held the wrong value, I'd fix > them so they held the right value ahead of time, and not bother using a > debugger. > > :-) Ahh but that requires that you know the right value as well. It's plausible that you have a handful of "tweakables" but you have no idea what to tweak them *to*. That's where this would be plausible. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Questions about `locals` builtin
On Wed, Feb 28, 2018 at 10:59 PM, Steven D'Aprano wrote: > On Wed, 28 Feb 2018 18:01:42 +1100, Chris Angelico wrote: > >> If you really want a list of ALL the local names in a function, you can >> look at its __code__ object, which has a tuple of variable names: >> >> print(func1.__code__.co_varnames) >> >> That information is static to the function, as it is indeed determined >> when the function is compiled. > > Ho ho ho, not in Python 2 it isn't!!! > > py> def bizarre(): > ... x = 1 > ... from math import * # oww my aching head! > ... print 'sin' in locals() > ... print sin > ... The sin in question is that you're using a star import inside a function. The penance is to kneel before the altar and recite PEP 20 nineteen times. And then cut down the tallest tree in the forest... with... a debugger. (When I tried that, I got a SyntaxWarning. Yay!) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil
On Tue, Feb 27, 2018 at 8:30 PM, Matt Wheeler wrote: > > > On Wed, 28 Feb 2018, 00:49 Larry Martell, wrote: >> >> On Tue, Feb 27, 2018 at 7:36 PM, José María Mateos >> wrote: >> > On Tue, Feb 27, 2018 at 07:29:50PM -0500, Larry Martell wrote: >> >> Trying to install psutil (with pip install psutil) on Red Hat EL 7. >> >> It's failing with: >> >> >> >> Python.h: No such file or directory >> > >> > Two questions come to my mind: >> > >> > - Does it work if you try to install some other package? >> >> Yes, I have installed other packages (e.g. numpy) > > > Did that install definitely involve a build from source? > >> > - Is `pip` by any change trying to install a Python 3 package, but you >> > only have the libraries for Python 2 installed? >> >> No, here is the gcc command line that failed: >> >> gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall >> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong >> --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic >> -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall >> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong >> --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic >> -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DPSUTIL_POSIX=1 >> -DPSUTIL_VERSION=543 -DPSUTIL_LINUX=1 >> -I/opt/rh/python27/root/usr/include/python2.7 -c >> psutil/_psutil_common.c -o >> build/temp.linux-x86_64-2.7/psutil/_psutil_common.o > > > Based on the include path you have here this looks like you have a non > standard python package for EL7 (in addition to the system one, or you'd be > having a worse day), which is probably the root of your problem. > > Are you using python packages from scl perhaps? > If so you probably need to install python27-python-devel (found at > http://mirror.centos.org/centos/7/sclo/x86_64/rh/python27/) Thanks to all who replied. The machine got rebooted (for an unrelated issue) and when it came back up the install worked fine. -- https://mail.python.org/mailman/listinfo/python-list
Re: py2exe output flagged as malware
On 28/02/2018 11:46, alister via Python-list wrote: On Wed, 28 Feb 2018 09:53:09 +, Robin Becker wrote: I see this has happened to others in the past. I'm using 32 bit python 2.7.10 with py2exe 3.3 on windows 7. The exes work fine, but when I try to download into windows 10 I'm getting the exes immediately removed as malware. Is there any way to prevent this. It's very bad for python programs to get this kind of reputation. Anyone know if the same happens with PyInstaller etc etc? I would suggest you contact the Anti-virus vendor, Are you sure you have download a clean copy of py2exe. The anti-virus vendor is Microsoft; I imagine I will get short shrift from them regarding this issue. Turns out my py2exe script was just pyinstaller under the hood. Apologies to py2exe. I guess someone changed the build script script to use a different python packager. I upgraded pyinstaller using the very latest pip and now the version of pyinstaller at least is 3.3.1. I don't actually know how to check the validity of the installed code or the binary stubs. After rebuilding with 3.3.1 the new exe is 10 bytes shorter and is not recognized as malware by windows 10. -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: py2exe output flagged as malware
Am 28.02.2018 um 16:47 schrieb Robin Becker: > I upgraded pyinstaller using the very latest pip and now the version > of pyinstaller at least is 3.3.1. I don't actually know how to check > the validity of the installed code or the binary stubs. The current archives are PyPI are PGP/GnuPG-signed, as the ones at github. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | -- https://mail.python.org/mailman/listinfo/python-list
Re: py2exe output flagged as malware
On 28/02/2018 16:25, Hartmut Goebel wrote: Am 28.02.2018 um 16:47 schrieb Robin Becker: I upgraded pyinstaller using the very latest pip and now the version of pyinstaller at least is 3.3.1. I don't actually know how to check the validity of the installed code or the binary stubs. The current archives are PyPI are PGP/GnuPG-signed, as the ones at github. so presumably I can locate the downloaded tar zip and hash it to check. Of course if pip is already busted it can out fox me anyhow. -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: py2exe output flagged as malware
Am 28.02.2018 um 16:47 schrieb Robin Becker: > I upgraded pyinstaller using the very latest pip and now the version > of pyinstaller at least is 3.3.1. I don't actually know how to check > the validity of the installed code or the binary stubs. The current archives are PyPI are PGP/GnuPG-signed, as the ones at github. -- Schönen Gruß Hartmut Goebel Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer Information Security Management, Security Governance, Secure Software Development Goebel Consult, Landshut http://www.goebel-consult.de Blog: http://www.goebel-consult.de/blog/nicht-pgp-ist-gescheitert-die-entwickler-haben-versagt Kolumne: http://www.cissp-gefluester.de/2012-02-bring-your-own-life-glosse -- https://mail.python.org/mailman/listinfo/python-list
Which sites allow you to learn interactively Python3
Which sites allow you to learn interactively Python3? they can be payed, actually payed would probably be bettter Good quality source -- https://mail.python.org/mailman/listinfo/python-list
Re: Which sites allow you to learn interactively Python3
see clever programmer python by projects. Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ On 28 Feb 2018 21:56, wrote: > Which sites allow you to learn interactively Python3? > > they can be payed, > > actually payed would probably be bettter > Good quality source > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: help me ? (Posting On Python-List Prohibited)
On Wednesday, 28 February 2018 06:00:07 UTC+1, Lawrence D’Oliveiro wrote: > On Wednesday, February 28, 2018 at 4:44:04 PM UTC+13, jlad...@itu.edu wrote: > > This is part of the reason why interviews for software developer jobs > > have gotten so crazy. > > This is why you need to have a CV that basically says “Google me”. what the hell do you care about cheating.. the world doest care about cheating. its about skill. You guys been too much in school -- https://mail.python.org/mailman/listinfo/python-list
PyDev 6.3.1 Released
PyDev 6.3.1 Release Highlights
- PyDev is now also available for Python coding on Visual Studio Code --
see: http://www.pydev.org/vscode/ for more details.
PyDev changes:
-
Type inference
- Folders no longer require *__init__* to be considered a package.
- Properly recognize *cx_Oracle.cp36-win_amd64.pyd* as *cx_Oracle* (
*#PyDev-885*).
-
Empty numpy arrays properly handled in debugger.
-
Fix to get path to activate conda env on Linux.
-
Fix debug console freeze when evaluation raises exception with Python
3.5 onwards (*#PyDev-877*).
-
Interactive console accepting new args passed by IPython in
showtraceback (*#PyDev-882*).
-
Improve terminating running processes (and children).
-
Properly parsing f-strings which contain double *{{* or *}}* (
*#PyDev-884*).
About PyDev
PyDev is an open-source Python IDE on top of Eclipse for Python, Jython and
IronPython development, now also available for Python on Visual Studio Code.
It comes with goodies such as code completion, syntax highlighting, syntax
analysis, code analysis, refactor, debug, interactive console, etc.
It is also available as a standalone through LiClipse with goodies such as
Multiple cursors, theming and support for many other languages, such as
Django Templates, Jinja2, Html, JavaScript, etc.
Links:
PyDev: http://pydev.org
PyDev Blog: http://pydev.blogspot.com
PyDev on VSCode: http://pydev.org/vscode
LiClipse: http://www.liclipse.com
PyVmMonitor - Python Profiler: http://www.pyvmmonitor.com/
Cheers,
Fabio Zadrozny
--
https://mail.python.org/mailman/listinfo/python-list
Re: cute interview problem
On Tuesday, 27 February 2018 00:42:02 UTC+1, Paul Rubin wrote: > Ron Aaron posted the below url on comp.lang.forth. It points to what I > thought was a cute problem, along with his solution in his Forth dialect > 8th: > > https://8th-dev.com/forum/index.php/topic,1584.msg8720.html > > I wrote a solution in Forth and additional ones in Python and Haskell > and thought people here might like trying it themselves. I'll post my > Python version here in a few days if anyone wants to see it. Time limit > for the problem is supposed to be 45 minutes. I spent a lot longer > because I ended up writing several versions in various languages. I dont think its cute at all. how did the interview go? -- https://mail.python.org/mailman/listinfo/python-list
Re: cute interview problem
On Tuesday, 27 February 2018 00:42:02 UTC+1, Paul Rubin wrote: > Ron Aaron posted the below url on comp.lang.forth. It points to what I > thought was a cute problem, along with his solution in his Forth dialect > 8th: > > https://8th-dev.com/forum/index.php/topic,1584.msg8720.html > > I wrote a solution in Forth and additional ones in Python and Haskell > and thought people here might like trying it themselves. I'll post my > Python version here in a few days if anyone wants to see it. Time limit > for the problem is supposed to be 45 minutes. I spent a lot longer > because I ended up writing several versions in various languages. teh interview how did it go -- https://mail.python.org/mailman/listinfo/python-list
Re: cute interview problem
On Wed, Feb 28, 2018 at 12:55 PM, wrote: > On Tuesday, 27 February 2018 00:42:02 UTC+1, Paul Rubin wrote: >> Ron Aaron posted the below url on comp.lang.forth. It points to what I >> thought was a cute problem, along with his solution in his Forth dialect >> 8th: >> >> https://8th-dev.com/forum/index.php/topic,1584.msg8720.html >> >> I wrote a solution in Forth and additional ones in Python and Haskell >> and thought people here might like trying it themselves. I'll post my >> Python version here in a few days if anyone wants to see it. Time limit >> for the problem is supposed to be 45 minutes. I spent a lot longer >> because I ended up writing several versions in various languages. > > I dont think its cute at all. > how did the interview go? Yeah, seems to me this is basically just asking "have you ever heard of an interval tree (or can you invent one on the fly)". -- https://mail.python.org/mailman/listinfo/python-list
Re: Detection of ultrasonic side channels in mobile devices with Python?
Hey, I want to know why this question is being silently ignored by this group. I think it is essential to develop cryptoanalysis tools (like softwares) to detect and block ultrasonic signals in mobile devices. Using Python to detect or block ultrasonic side channels would be very interesting. I want to know what exactly do I need to develop open source softwares for analyzing and decoding ultrasonic side channels in smart tvs, mobile phones, and computers in Python. Please speak your mind out... Tell me how exactly ultrasonic side channels may activate remotely specific neural pathways implicated in aggressivity and how to block theses specific side channels from neuromodulating human behavior. Thank you. Etienne Le 2018-02-26 à 05:25, Etienne Robillard a écrit : Hi, I would like to know if its possible to detect or decode ultrasonic signals in mobiles devices like Android with Python? For a introduction to ultrasonic tracking, see: https://www.wired.com/2016/11/block-ultrasonic-signals-didnt-know-tracking/ Thank you, Etienne -- Etienne Robillard tkad...@yandex.com https://www.isotopesoftware.ca/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Detection of ultrasonic side channels in mobile devices with Python?
On 2/28/18 4:13 PM, Etienne Robillard wrote: I want to know why this question is being silently ignored by this group. If no one has any information about your topic, then no one will say anything. Python on Android is very specialized as it is, and I have no idea what ultrasonic side channels are, much less what it would take to detect or block them. There's no guarantee that any given question will get a response, much less a satisfactory answer. The silence is not malicious, you just haven't piqued anyone's interest enough for them to respond. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Detection of ultrasonic side channels in mobile devices with Python?
On Thu, Mar 1, 2018 at 8:49 AM, Ned Batchelder wrote: > On 2/28/18 4:13 PM, Etienne Robillard wrote: >> >> I want to know why this question is being silently ignored by this group. > > > If no one has any information about your topic, then no one will say > anything. Python on Android is very specialized as it is, and I have no > idea what ultrasonic side channels are, much less what it would take to > detect or block them. > > There's no guarantee that any given question will get a response, much less > a satisfactory answer. The silence is not malicious, you just haven't > piqued anyone's interest enough for them to respond. > I rather suspect that this is more an Android question than a Python one, so there's likely to be more interest in an Android community. But this part sounds like prime quality tinfoil hat material: > Tell me how exactly ultrasonic side channels may activate remotely specific > neural pathways implicated in aggressivity and how to block theses specific > side channels from neuromodulating human behavior. Should be easy to find some whack-job newsgroups that would love to discuss that aspect of it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Detection of ultrasonic side channels in mobile devices with Python?
If ultrasonic side channels are a threat to privacy, it is because smart phones were designed to exploit this precise feature. A great number of studies have shown that ultrasonic neuromodulation of the central nervous system can be exploited via brain-computer interfaces... It is cutting edge science however, and my knowledge on techniques for activating human behavior by remote means is limited. I am only an amateur scientist/programmer with no experience whatsoever in Android or neuroscience. However, the possibility of ultrasonic side channels to be exploited by a third-party remotely without the user consent seem highly likely. I want to develop Python tools to provide experimental evidences that Android may exploit ultrasonic side channels to stimulate or impair the auditory cortex of someone. In other words, I plan to disclose the ability of the US government to use mobile devices as psychoenergetics (non-lethal) bioweapons. Etienne Le 2018-02-28 à 16:54, Chris Angelico a écrit : On Thu, Mar 1, 2018 at 8:49 AM, Ned Batchelder wrote: On 2/28/18 4:13 PM, Etienne Robillard wrote: I want to know why this question is being silently ignored by this group. If no one has any information about your topic, then no one will say anything. Python on Android is very specialized as it is, and I have no idea what ultrasonic side channels are, much less what it would take to detect or block them. There's no guarantee that any given question will get a response, much less a satisfactory answer. The silence is not malicious, you just haven't piqued anyone's interest enough for them to respond. I rather suspect that this is more an Android question than a Python one, so there's likely to be more interest in an Android community. But this part sounds like prime quality tinfoil hat material: Tell me how exactly ultrasonic side channels may activate remotely specific neural pathways implicated in aggressivity and how to block theses specific side channels from neuromodulating human behavior. Should be easy to find some whack-job newsgroups that would love to discuss that aspect of it. ChrisA -- Etienne Robillard tkad...@yandex.com https://www.isotopesoftware.ca/ -- https://mail.python.org/mailman/listinfo/python-list
RFC: Proposal: Deterministic Object Destruction
Informal Background === Python's lack of Deterministic Object Destruction semantics strikes me as very unpythonic. This state of affairs spawns lengthy diatribes on __del__(), a variety of specialised and onerous resource management solutions and malignant carbuncles such as PEP 343 (the "with" statement). None of these match the practical utility, simplicity, generality and robustness of Deterministic Object Destruction combined with the RAII idiom to manage resources. I have therefore drafted the radical but simple and 100% backward compatible proposal below to remedy this situation and pave the way for numerous tidy ups (out of scope of this proposal). I am now retiring to a safe distance and invite your comments on the PEP below:- Abstract This PEP proposes that valid python interpreters *must* synchronously destroy objects when the last reference to an object goes out of scope. This interpreter behaviour is currently permitted and exhibited by the reference implementation [CPython], but it is optional. Motivation == To make the elegance (simplicity, generality, and robustness) of the "Resource Acquisition Is Initialization" (RAII) idiom available to all python applications and libraries. To render less elegant and more onerous resource management solutions, such as the "with" Statement [PEP 343] obsolete. Specification = When the last reference to an object goes out of scope the intepreter must synchronously, in the thread that releases the last reference, invoke the object's __del__() method and then free the memory occupied by that object. Backwards Compatibility === This proposal preserves 100% backwards compatibility. The language currently does not prescribe when, or even if, __del()__ will be called and object memory freed. Existing python applications and libraries can make no assumptions about this behaviour. Reference Implementation CPython References == PEP 343 -- The "with" Statement -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Thu, Mar 1, 2018 at 9:51 AM, wrote:
> Specification
> =
>
> When the last reference to an object goes out of scope the intepreter must
> synchronously, in the thread that releases the last reference, invoke the
> object's __del__() method and then free the memory occupied by that object.
>
If it were that simple, why do you think it isn't currently mandated?
Here's one example: reference cycles. When do they get detected?
Taking a really simple situation:
class Foo:
def __init__(self):
self.self = self
print("Creating a Foo")
def __del__(self):
print("Disposing of a Foo")
foo = Foo()
foo = 1
When do you expect __del__ to be called? How do you implement this
efficiently and reliably?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Detection of ultrasonic side channels in mobile devices with Python?
On Wed, 28 Feb 2018 16:13:52 -0500, Etienne Robillard wrote: > Hey, > > I want to know why this question is being silently ignored by this > group. Possibly because we have no idea of the answer? Or we thought it was too obvious to answer? Do you have a microphone that can detect ultrasound? Can Python communicate with that microphone? If the answer to both of those questions is Yes, then the answer to your question is also yes. The answer to EVERY question "Can Python do Foo?" usually comes down to: - can you do Foo using a computer? then Python can do it too although it might not always be fast enough. [...] > I want to know what exactly do I need to develop open source softwares > for analyzing and decoding ultrasonic side channels in smart tvs, mobile > phones, and computers in Python. What makes you think we're experts on analyzing and decoding ultrasonic side channels in smart TVs, mobile phones, or computers? Let alone all three. > Tell me how exactly ultrasonic side channels may activate remotely > specific neural pathways implicated in aggressivity and how to block > theses specific side channels from neuromodulating human behavior. And what on Earth gave you the idea that we're experts on ultrasonic activation of neural pathways I'd go further... what gave you the idea that ANYONE is an expert on ultrasonic activation of neural pathways? -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Detection of ultrasonic side channels in mobile devices with Python?
On Thu, Mar 1, 2018 at 10:23 AM, Steven D'Aprano wrote: > I'd go further... what gave you the idea that ANYONE is an expert on > ultrasonic activation of neural pathways? Definitely tinfoil hat material here; expertise is completely immaterial. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Wednesday, February 28, 2018 at 11:02:17 PM UTC, Chris Angelico wrote:
> On Thu, Mar 1, 2018 at 9:51 AM, ooomzay wrote:
> > Specification
> > =
> >
> > When the last reference to an object goes out of scope the intepreter must
> > synchronously, in the thread that releases the last reference, invoke the
> > object's __del__() method and then free the memory occupied by that object.
> >
>
> If it were that simple, why do you think it isn't currently mandated?
We know the implementation is feasible because CPython, the reference
interpreter implementation, already does this. I am guessing that there is a
lobby from garbage platforms where it would be harder to implement and
integrate however the object of this proposal is the integrity of the language,
not on making it easier to implement using garbage platforms.
> Here's one example: reference cycles. When do they get detected?
Orphan cycle _detection_ is orthogonal to this proposal. As cycles are always a
symptom of a design error I personally have little interest in them other than
some facility to detect/debug and eliminate them from applications by design
(another topic).
> Taking a really simple situation:
>
> class Foo:
> def __init__(self):
> self.self = self
> print("Creating a Foo")
> def __del__(self):
> print("Disposing of a Foo")
>
> foo = Foo()
> foo = 1
>
> When do you expect __del__ to be called?
At the point of (re)assignment: "foo = 1"
> How do you implement this efficiently and reliably?
CPython already has a reliable and reasonably efficient implementation based on
reference counting.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Detection of ultrasonic side channels in mobile devices with Python?
On 2018-02-28, Chris Angelico wrote: > On Thu, Mar 1, 2018 at 10:23 AM, Steven D'Aprano > wrote: >> I'd go further... what gave you the idea that ANYONE is an expert on >> ultrasonic activation of neural pathways? > > Definitely tinfoil hat material here; expertise is completely immaterial. I miss Ludwig Plutonium. :/ -- Grant Edwards grant.b.edwardsYow! Nipples, dimples, at knuckles, NICKLES, gmail.comwrinkles, pimples!! -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Wed, 28 Feb 2018 14:51:09 -0800, ooomzay wrote: > Informal Background > === > > Python's lack of Deterministic Object Destruction semantics strikes me > as very unpythonic. This state of affairs spawns lengthy diatribes on > __del__(), I've never seen any of these lengthy diatribes. If they're on your blog, you may be over-estimating how many readers you have. > malignant carbuncles such as PEP 343 (the "with"statement). Ah, this is going to be one of *those* posts. > This PEP proposes that valid python interpreters *must* synchronously > destroy objects when the last reference to an object goes out of scope. Well, that rules out any practical Python interpreter running on the Java or .Net virtual machines, not to mention banning advanced and modern garbage collectors unless they also include a reference counter. So that's Jython and IronPython out, and PyPy's useful work on alternative garbage collectors out the window. It also enshrines the GIL (or some other locking mechanism) as not just an implementation detail of CPython, but as mandatory for all Python interpreters. > Motivation > == > > To make the elegance (simplicity, generality, and robustness) of the > "Resource Acquisition Is Initialization" (RAII) idiom available to all > python applications and libraries. I've never yet seen an explanation of RAII that makes the least amount of sense. I wouldn't call it either elegant or simple. More like "confusing and badly named". > Specification > = > > When the last reference to an object goes out of scope the intepreter > must synchronously, in the thread that releases the last reference, > invoke the object's __del__() method and then free the memory occupied > by that object. What happens if the __del__ method recreates a reference to the object? > Backwards Compatibility > === > > This proposal preserves 100% backwards compatibility. So long as you're not using IronPython, Jython, or some alternate builds of PyPy. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Thu, Mar 1, 2018 at 10:44 AM, wrote:
> On Wednesday, February 28, 2018 at 11:02:17 PM UTC, Chris Angelico wrote:
>> On Thu, Mar 1, 2018 at 9:51 AM, ooomzay wrote:
>> > Specification
>> > =
>> >
>> > When the last reference to an object goes out of scope the intepreter must
>> > synchronously, in the thread that releases the last reference, invoke the
>> > object's __del__() method and then free the memory occupied by that object.
>> >
>>
>> If it were that simple, why do you think it isn't currently mandated?
>
> We know the implementation is feasible because CPython, the reference
> interpreter implementation, already does this. I am guessing that there is a
> lobby from garbage platforms where it would be harder to implement and
> integrate however the object of this proposal is the integrity of the
> language, not on making it easier to implement using garbage platforms.
>
Good to know that Jython and friends are "garbage platforms". I hope
you were referring to garbage collection, and that this was merely a
clumsy choice of words, rather than actually insulting these other
Python implementations.
>> Here's one example: reference cycles. When do they get detected?
>
> Orphan cycle _detection_ is orthogonal to this proposal. As cycles are always
> a symptom of a design error I personally have little interest in them other
> than some facility to detect/debug and eliminate them from applications by
> design (another topic).
>
No, they're not always a symptom of a design error.
>> Taking a really simple situation:
>>
>> class Foo:
>> def __init__(self):
>> self.self = self
>> print("Creating a Foo")
>> def __del__(self):
>> print("Disposing of a Foo")
>>
>> foo = Foo()
>> foo = 1
>>
>> When do you expect __del__ to be called?
>
> At the point of (re)assignment: "foo = 1"
>
>
>> How do you implement this efficiently and reliably?
>
> CPython already has a reliable and reasonably efficient implementation based
> on reference counting.
>
http://catb.org/jargon/html/koans.html
Just before reassignment, there are two references to that object: one
from the name "foo", and another from its own "self" attribute. After
reassignment, there is one reference, from its own "self" attribute.
The reference count will never drop to zero.
I suggest you read up on why other forms of garbage collection exist,
rather than simply demanding that Python behave in a particular way.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Wednesday, February 28, 2018 at 11:45:24 PM UTC, ooo...@gmail.com wrote:
> On Wednesday, February 28, 2018 at 11:02:17 PM UTC, Chris Angelico wrote:
> > On Thu, Mar 1, 2018 at 9:51 AM, ooomzay wrote:
> > [snip]
> > Taking a really simple situation:
> >
> > class Foo:
> > def __init__(self):
> > self.self = self
> > print("Creating a Foo")
> > def __del__(self):
> > print("Disposing of a Foo")
> >
> > foo = Foo()
> > foo = 1
> >
> > When do you expect __del__ to be called?
>
> At the point of (re)assignment: "foo = 1"
Oh... I now see there is a (non-weak) self reference in there.
So in this case it would be orphaned. It is a design error and should be
recoded. I don't care how it is detected for current purposes.
--
https://mail.python.org/mailman/listinfo/python-list
Drinking from the fire-hose
Hey Chris, regretting writing that "Statement-Local Name Bindings" PEP yet? :-) I know *I'm* regretting that you wrote it, because this is the sort of language feature that has the potential to make Python significantly ugly and worse, and I'd like to have my say, but there's no way I have time to troll through 50+ and counting (in just 25 hours!) posts. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Detection of ultrasonic side channels in mobile devices with Python?
What do rats find rewarding in play fighting? Le 2018-02-28 à 18:29, Chris Angelico a écrit : On Thu, Mar 1, 2018 at 10:23 AM, Steven D'Aprano wrote: I'd go further... what gave you the idea that ANYONE is an expert on ultrasonic activation of neural pathways? Definitely tinfoil hat material here; expertise is completely immaterial. ChrisA -- Etienne Robillard tkad...@yandex.com https://www.isotopesoftware.ca/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Drinking from the fire-hose
On Thu, Mar 1, 2018 at 10:58 AM, Steven D'Aprano wrote: > Hey Chris, regretting writing that "Statement-Local Name Bindings" PEP > yet? :-) Haha, nah. I'm okay with the fire hose. > I know *I'm* regretting that you wrote it, because this is the sort of > language feature that has the potential to make Python significantly ugly > and worse, and I'd like to have my say, but there's no way I have time to > troll through 50+ and counting (in just 25 hours!) posts. But the proposals keep coming up every now and then. This way, if the PEP gets rejected, it'll be easy to point people to it instead of having to rehash the arguments every time. Maybe flip through the PEP and make comments on that, regardless of previous posts? I'm not unaccustomed to the same topics coming up multiple times during PEP firehosings, and it doesn't much bother me. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: help me ? (Posting On Python-List Prohibited)
On Wed, 28 Feb 2018 09:58:24 -0800, Aktive wrote: > what the hell do you care about cheating.. > > the world doest care about cheating. > > its about skill. Because cheaters don't have skill. That's why they cheat. > You guys been too much in school Ah, spoken like a cheater. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Wed, 28 Feb 2018 15:44:45 -0800, ooomzay wrote: >> Here's one example: reference cycles. When do they get detected? > > Orphan cycle _detection_ is orthogonal to this proposal. It certainly is not. Dealing with cycles is why most of the world has moved on from reference counters. (Or at least, from using reference counters *alone*.) > As cycles are always a symptom of a design error "Always"? So, because you personally don't like the with-statement (possibly because it is too clear, understandable, explicit and deterministic for your tastes?), you want to mandate that everyone else use the clumsy work- around of weak references to avoid an artificial and pointless "design error" of a reference cycle. Great. I'm loving this RFC more and more. Not. Hint: the real world is *full* of cycles. Many problems have to deal with cycles. Having to manage those cycles by hand is *awful*, and completely unnecessary given that garbage collectors exist that can manage them for you. > I personally have little interest in > them other than some facility to detect/debug and eliminate them from > applications by design (another topic). And for your next tricks, you'll solve the political problems of the Middle East without hurting anyone, and then colonise Mars on a budget of ten thousand dollars. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Thu, Mar 1, 2018 at 10:48 AM, Steven D'Aprano wrote: > On Wed, 28 Feb 2018 14:51:09 -0800, ooomzay wrote: >> Motivation >> == >> >> To make the elegance (simplicity, generality, and robustness) of the >> "Resource Acquisition Is Initialization" (RAII) idiom available to all >> python applications and libraries. > > I've never yet seen an explanation of RAII that makes the least amount of > sense. I wouldn't call it either elegant or simple. More like "confusing > and badly named". Badly named, yes, but it's not too confusing. RAII is just a fancy name for "when I construct a file object, you open the file, and when the file object is disposed of, you close the file for me". Which is exactly how Python works, with the exception that RAII depends on prompt object disposal (hence the OP's demands). In CPython, you can happily write this: def save_file(fn): f = open(fn, "w") print(data, file=f) print(more_data, file=f) save_file(...) The file object gets disposed of as the function terminates, and the underlying file handle gets closed. That's RAII. The only problem is that this doesn't work reliably with reference counting (the C++ way to do it is to have a single automatic object, no refcounting, no pointers, nothing), and definitely doesn't work with most non-refcount garbage collection (mark-and-sweep, arena, etc). >> Backwards Compatibility >> === >> >> This proposal preserves 100% backwards compatibility. > > So long as you're not using IronPython, Jython, or some alternate builds > of PyPy. > Hmm, I think actually it does; if all Python implementations magically became compliant with the OP's demands, they'd be fully backward-compatible. This is a tightening of requirements on the language. It's still not a good idea though. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
csv module and NULL data byte
I have a csv data file that may become corrupted (already happened) resulting in a NULL byte appearing in the file. The NULL byte causes an _csv.Error exception. I'd rather like the csv reader to return csv lines as best it can and subsequent processing of each comma separated field deal with illegal bytes. That way as many lines from the file may be processed and the corrupted ones simply dumped. Is there a way of getting the csv reader to accept all 256 possible bytes. (with \r,\n and ',' bytes delimiting lines and fields). My test code is, with open( fname, 'rt', encoding='iso-8859-1' ) as csvfile: csvreader = csv.reader(csvfile, delimiter=',', quoting=csv.QUOTE_NONE, strict=False ) data = list( csvreader ) for ln in data: print( ln ) Result >>python36 csvTest.py Traceback (most recent call last): File "csvTest.py", line 22, in data = list( csvreader ) _csv.Error: line contains NULL byte strict=False or True makes no difference. Help appreciated, John -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On 2018-03-01 00:14, Steven D'Aprano wrote: On Wed, 28 Feb 2018 15:44:45 -0800, ooomzay wrote: Here's one example: reference cycles. When do they get detected? Orphan cycle _detection_ is orthogonal to this proposal. It certainly is not. Dealing with cycles is why most of the world has moved on from reference counters. (Or at least, from using reference counters *alone*.) As cycles are always a symptom of a design error "Always"? So, because you personally don't like the with-statement (possibly because it is too clear, understandable, explicit and deterministic for your tastes?), you want to mandate that everyone else use the clumsy work- around of weak references to avoid an artificial and pointless "design error" of a reference cycle. Great. I'm loving this RFC more and more. Not. Hint: the real world is *full* of cycles. Many problems have to deal with cycles. Having to manage those cycles by hand is *awful*, and completely unnecessary given that garbage collectors exist that can manage them for you. I personally have little interest in them other than some facility to detect/debug and eliminate them from applications by design (another topic). And for your next tricks, you'll solve the political problems of the Middle East without hurting anyone, and then colonise Mars on a budget of ten thousand dollars. Or, if you want something a little more challenging, work on Brexit! :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Detection of ultrasonic side channels in mobile devices with Python?
In Chris Angelico writes: > > Tell me how exactly ultrasonic side channels may activate remotely specific > > neural pathways implicated in aggressivity and how to block theses specific > > side channels from neuromodulating human behavior. > Should be easy to find some whack-job newsgroups that would love to > discuss that aspect of it. Sounds like the plot to the latest Kingsman movie. -- John Gordon A is for Amy, who fell down the stairs gor...@panix.com B is for Basil, assaulted by bears -- Edward Gorey, "The Gashlycrumb Tinies" -- https://mail.python.org/mailman/listinfo/python-list
Re: Detection of ultrasonic side channels in mobile devices with Python?
On Thu, 01 Mar 2018 08:54:52 +1100, Chris Angelico wrote: > But this part sounds like prime quality tinfoil hat material: > >> Tell me how exactly ultrasonic side channels may activate remotely >> specific neural pathways implicated in aggressivity and how to block >> theses specific side channels from neuromodulating human behavior. I wouldn't entirely rule it out. (On the other hand, I wouldn't give it much credence in the absence of solid evidence either.) I'm too lazy to google it right now, but I recall that there's definitely evidence for inaudible *subsonic* frequencies being able to affect human emotions, mostly to induce feelings of disquiet and nameless dread. I recall a panel of US scientists in the 1980s trying to work out how to protect long-lived nuclear waste from inquisitive humans for periods of many millions of years. Obviously Keep Out signs aren't going to do the job, so one of the ideas they were tossing around was to surround the area in artificial rock carved into shapes which would generate the appropriate subsonic frequencies when the wind blew. Of course it is only a matter of time before malware, spyware, adware and hostile-national-security-ware[1] takes advantage of ultrasonic side channels to screw us over however they can. Including the US government. But I think the idea that the mobile phone manufacturers *intentionally* built phones with this capability in order to give the US government the ability to weaponise people's phones against them is sheer nuttiness. [1] In the current political climate, I think it is safe to say that nearly all national security ware is hostile, and every one of us are the targets. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Detection of ultrasonic side channels in mobile devices with Python?
On 2/28/18 7:01 PM, Etienne Robillard wrote: What do rats find rewarding in play fighting? This is well outside the topics for this list. --Ned. Le 2018-02-28 à 18:29, Chris Angelico a écrit : On Thu, Mar 1, 2018 at 10:23 AM, Steven D'Aprano wrote: I'd go further... what gave you the idea that ANYONE is an expert on ultrasonic activation of neural pathways? Definitely tinfoil hat material here; expertise is completely immaterial. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: csv module and NULL data byte
While inelegant, I've "solved" this with a wrapper/generator
f = file(fname, …)
g = (line.replace('\0', '') for line in f)
reader = csv.reader(g, …)
for row in reader:
process(row)
My actual use at $DAYJOB cleans out a few other things
too, particularly non-breaking spaces coming from client data
that .strip() doesn't catch in Py2.x ("hello\xa0".strip())
-tkc
On 2018-02-28 23:40, John Pote wrote:
> I have a csv data file that may become corrupted (already happened)
> resulting in a NULL byte appearing in the file. The NULL byte
> causes an _csv.Error exception.
>
> I'd rather like the csv reader to return csv lines as best it can
> and subsequent processing of each comma separated field deal with
> illegal bytes. That way as many lines from the file may be
> processed and the corrupted ones simply dumped.
>
> Is there a way of getting the csv reader to accept all 256 possible
> bytes. (with \r,\n and ',' bytes delimiting lines and fields).
>
> My test code is,
>
> with open( fname, 'rt', encoding='iso-8859-1' ) as csvfile:
> csvreader = csv.reader(csvfile, delimiter=',',
> quoting=csv.QUOTE_NONE, strict=False )
> data = list( csvreader )
> for ln in data:
> print( ln )
>
> Result
>
> >>python36 csvTest.py
> Traceback (most recent call last):
> File "csvTest.py", line 22, in
> data = list( csvreader )
> _csv.Error: line contains NULL byte
>
> strict=False or True makes no difference.
>
> Help appreciated,
>
> John
>
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Detection of ultrasonic side channels in mobile devices with Python?
On Wednesday, February 28, 2018 at 4:34:11 PM UTC-6, Etienne Robillard wrote: > A great number of studies have shown that ultrasonic > neuromodulation of the central nervous system can be > exploited via brain-computer interfaces... It is cutting > edge science however, and my knowledge on techniques for > activating human behavior by remote means is limited. I am > only an amateur scientist/programmer with no experience > whatsoever in Android or neuroscience. I doubt anyone in this group will have knowledge in such a high-tech experimental/theoretical field such as "remote behavior modification"? And even if someone did, i'm sure they'd wise enough to keep quiet about it. Because if such technology exists today, then it would have military applications, and thus, be highly classified. And, just as a thought experiment, if we imagined that -- somehow -- you attained this specialized knowledge, and you were _not_ already employed by one of the military labs -- oh boy! -- you would then become a threat to national security, and be hunted by every spy agency on the face of this planet. With that in mind, i think you're in way over your head. And perhaps you should apply a reversed transformation to your current vector path. > However, the possibility of ultrasonic side channels to be > exploited by a third-party remotely without the user > consent seem highly likely. I want to develop Python tools > to provide experimental evidences that Android may exploit > ultrasonic side channels to stimulate or impair the > auditory cortex of someone. That sounds malicious to me. Although, considering the abysmal state of music these days... sometimes i wish my smart phone _would_ impair my auditory cortex. > In other words, I plan to disclose the ability of the US > government to use mobile devices as psychoenergetics (non- > lethal) bioweapons. Why take the chance? Ditch the phone all together and live free! Who cares about the lemmings anyway. The worms have already ate into their brains. Even if you provide evidence proving your claims to be true, people (*AHEM*, "Sheeple") are so wedded to their smart phones that even *IF* smart phones caused chronic explosive diarrhea, i seriously doubt anyone would put their phone down for more than five minutes. We're talking about OCD on a _galactic_ scale here, my friend. In fact, smart phone users have become so OCD about their phones, that soon they plan to borrow the NRA's slogan (slightly modified, of course): 'From my *COLD*. *DEAD*. *BROWN*. *HAND*." -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Wednesday, February 28, 2018 at 5:02:17 PM UTC-6, Chris Angelico wrote: > Here's one example: reference cycles. When do they get detected? > Taking a really simple situation: > > class Foo: > def __init__(self): > self.self = self *shudders* Can you provide a real world example in which you need an object which circularly references _itself_? This looks like a highly contrived example used to (1) merely win the argument, and (2) Bump fib() up one position from it's current position as "the worst introductory example of how to write a function in the history of programming tutorials" -- https://mail.python.org/mailman/listinfo/python-list
Re: Detection of ultrasonic side channels in mobile devices with Python?
Instead of berating us for not answering an extremely obscure question, you should have use Ms SearchBox first, like I did to determine whether these are real subjects. On 2/28/2018 5:31 PM, Etienne Robillard wrote: If ultrasonic side channels are a threat to privacy, it is because smart phones were designed to exploit this precise feature. (Near) Ultrasonic beacons are apparently a real and rather sneaky tracking mechanism. https://www.schneier.com/blog/archives/2017/05/using_ultrasoni.html This is actually about using near-ultrasonic, 18-20 KHtz, which can be produced by some TVs and other off-the-shelf gear and detected by phone microphones. Read or ask *them* about what android/Dalvik system calls they used to access phone microphones. Investigate for yourself whether any Python implementations for Android give you such access. A great number of studies have shown that ultrasonic neuromodulation of the central nervous system can be exploited via brain-computer interfaces... https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4981830/ is a review article about clinical use for brain and nerve stimulation in patients. I am rather sure that they are talking about *real* ultrasound, well away from the audio range. So this seems to be a completely separate topic. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Wednesday, February 28, 2018 at 5:50:53 PM UTC-6, Steven D'Aprano wrote: > On Wed, 28 Feb 2018 14:51:09 -0800, ooomzay wrote: > > > > [...] > > > > Specification > > = > > > > When the last reference to an object goes out of scope the > > intepreter must synchronously, in the thread that releases > > the last reference, invoke the object's __del__() method > > and then free the memory occupied by that object. > > What happens if the __del__ method recreates a reference to > the object? So make instantation of the object in its __del__ method an illegal op! -- https://mail.python.org/mailman/listinfo/python-list
Re: csv module and NULL data byte
On 2018-02-28 21:38, Dennis Lee Bieber wrote:
> > with open( fname, 'rt', encoding='iso-8859-1' ) as csvfile:
>
> Pardon? Has the CSV module changed in the last year or so?
>
> Last time I read the documentation, it was recommended that
> the file be opened in BINARY mode ("rb").
It recommends binary mode, but seems to largely work fine with
text/ascii mode or even arbitrary iterables. I've not seen the
rationale behind the binary recommendation, but in 10+ years of using
the csv module, I've not found any issues in using text/ascii mode
that were solved by switching to using binary mode.
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: csv module and NULL data byte
On 2/28/2018 8:35 PM, Tim Chase wrote:
While inelegant, I've "solved" this with a wrapper/generator
f = file(fname, …)
g = (line.replace('\0', '') for line in f)
reader = csv.reader(g, …)
for row in reader:
process(row)
I think this is elegant in that is cleans the input stream independently
of the consumer. It is easier than what I was going to suggest, which
is to read the cvs source for the line that raises the exception and
modify the code until it works with \0 in the stream.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Detection of ultrasonic side channels in mobile devices with Python?
On 2018-03-01, Dennis Lee Bieber wrote: > The bandwidth normally used for voice grade telephone traffic is closer > to 6kHz (say 300Hz to 6.3kHz) Wow, that's pretty high -- where was that? Back when I was designing telephony electronics in US in the late 80's, POTS bandwidth was 3KHz: 300-3.3K. That same bandpass spec was used for the audio stages in the first couple generations of AMPS cellular mobile phones. The Codecs used in digital telephony (e.g. a T1 trunk) used 7-bit converts with 8KHz sampling, which means a cutoff frequency below 4KHz. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Thu, Mar 1, 2018 at 1:46 PM, Rick Johnson wrote: > On Wednesday, February 28, 2018 at 5:02:17 PM UTC-6, Chris Angelico wrote: > >> Here's one example: reference cycles. When do they get detected? >> Taking a really simple situation: >> >> class Foo: >> def __init__(self): >> self.self = self > > *shudders* > > Can you provide a real world example in which you need an > object which circularly references _itself_? This looks like > a highly contrived example used to (1) merely win the > argument, and (2) Bump fib() up one position from it's > current position as "the worst introductory example of how > to write a function in the history of programming tutorials" Not off hand, but I can provide an EXTREMELY real-world example of a fairly tight loop: exceptions. An exception has a reference to the local variables it came from, and those locals may well include the exception itself: try: 1/0 except Exception as e: print(e) The ZeroDivisionError has a reference to the locals, and 'e' in the locals refers to that very exception object. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Wed, Feb 28, 2018, Rick Johnson wrote: > On Wednesday, February 28, 2018 at 5:02:17 PM UTC-6, Chris Angelico wrote: > >> Here's one example: reference cycles. When do they get detected? >> Taking a really simple situation: >> >> class Foo: >> def __init__(self): >> self.self = self > >*shudders* > >Can you provide a real world example in which you need an >object which circularly references _itself_? This looks like >a highly contrived example used to (1) merely win the >argument, and (2) Bump fib() up one position from it's >current position as "the worst introductory example of how >to write a function in the history of programming tutorials" If you want something that looks like a real world example, consider the very common doubly-linked list: [ 1 ] <---> [ 2 ] <---> [ 3 ] <--.--> [ N ] This is chock-full of reference cycles, everywhere you see a <--> Then you have a wrapper List object that has a head referencing the 1 node and a tail referencing the N node. And you decide you don't need that List any more. You could: 1) Take the time the code to carefully delete every single node in this linked list, taking the time to set all of the internal references to None, or 2) Just discard your List object, and let the GC take care of the rest. Note that removing the list alone does not clear any of the reference counts in the picture above, because those internal <--> references are all still there. You either have to manually remove all the references, or rely on the garbage collector. Oh, and for those who claim that reference counting is 'efficient', do bear in mind that every single assignment statement increases the reference count of one value and possibly reduces the reference count of another. So down in the machine or byte-code world, every assignment operation is really two arithmetic computations and three assignments, which takes 5 times as many operations as not doing any reference counting at all. So if you have a program that can get by leaving unused memory allocated, and can still terminate the program before all the memory is claimed, your reference count system is far less efficient than relying on a garbage collector that happens to not get activated before your program ends. Roger Christman Pennsylvania State University -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Wed, 28 Feb 2018 18:46:05 -0800, Rick Johnson wrote: > On Wednesday, February 28, 2018 at 5:02:17 PM UTC-6, Chris Angelico > wrote: > >> Here's one example: reference cycles. When do they get detected? Taking >> a really simple situation: >> >> class Foo: >> def __init__(self): >> self.self = self > > *shudders* > > Can you provide a real world example in which you need an object which > circularly references _itself_? This looks like a highly contrived > example used to (1) merely win the argument, and (2) Bump fib() up one > position from it's current position as "the worst introductory example > of how to write a function in the history of programming tutorials" Of course it is a contrived example: it is close to the simplest possible example of a reference cycle. Its not intended as an example of useful code. (Useful or not, your interpreter better not crash when faced with a cycle like this.) But of course there are uses for objects to hold a reference to themselves. If you're writing a general purpose collection (say, a list or dict) then you better be able to cope with the case that somebody puts your list in itself: L = [] L.append(L) either directly, as above, or indirectly. And that's the point really: cycles don't just occur when an object holds a reference to itself. They occur when one object holds a reference to another object, which holds a reference to a third, which holds a reference to a fourth (and so on...), which eventually holds a reference to the original again. Cycles are useful. For example, you might think of a window which holds a reference to a control, which in turn needs a reference to its owning window. Or a network which contains loops, say a network of streets, or networks of disease transmission (I caught the stomach bug from Bob, who caught it from Sally, who caught it from Georgina, who originally caught it from me the *first* time I had it). It shouldn't take much imagination to think of cycles in real life which you may want to model in a program. https://en.wikipedia.org/wiki/I'm_My_Own_Grandpa -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
Rick Johnson writes: > ... > Can you provide a real world example in which you need an > object which circularly references _itself_? Circular structures occur in real life. One example are tracebacks (which are very helpful for debugging reasons). Keeping a traceback in a variable can easily introduce a cycle. Another example is a tree structure where you need both efficient access to children and ancestors of a node (see the DOM standard). -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
01.03.18 04:46, Rick Johnson пише: On Wednesday, February 28, 2018 at 5:02:17 PM UTC-6, Chris Angelico wrote: Here's one example: reference cycles. When do they get detected? Taking a really simple situation: class Foo: def __init__(self): self.self = self *shudders* Can you provide a real world example in which you need an object which circularly references _itself_? This looks like a highly contrived example used to (1) merely win the argument, and (2) Bump fib() up one position from it's current position as "the worst introductory example of how to write a function in the history of programming tutorials" Every global function (or method of global class) creates a reference cycle. def f(): pass f.__globals__['f'] is f -- https://mail.python.org/mailman/listinfo/python-list
