[RELEASE] Python 3.6.2rc2 is now available for testing
On behalf of the Python development community and the Python 3.6 release team, I would like to announce the availability of Python 3.6.2rc2. 3.6.2rc2 is the second release candidate for Python 3.6.2, the next maintenance release of Python 3.6. 3.6.2rc2 includes fixes for three security-related issues resolved since the previous release candidate; see the change log (link below). While 3.6.2rc2 is a preview release and, thus, not intended for production environments, we encourage you to explore it and provide feedback via the Python bug tracker (https://bugs.python.org). Please see "What’s New In Python 3.6" for more information: https://docs.python.org/3.6/whatsnew/3.6.html You can find Python 3.6.2rc2 here: https://www.python.org/downloads/release/python-362rc2/ and its change log here: https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-2-release-candidate-2 3.6.2 is now planned for final release on 2017-07-17 with the next maintenance release expected to follow in about 3 months. More information about the 3.6 release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ -- Ned Deily n...@python.org -- [] -- https://mail.python.org/mailman/listinfo/python-list
Re: Windows: python3.exe missing
py -3.5 py -3.6 works. Don't know about py -3.6.0 py -3.6.1 On Fri, Jul 7, 2017 at 11:25 PM, Terry Reedy wrote: > On 7/7/2017 5:45 PM, Andrew Pennebaker wrote: > >> Could the Windows installer for Python 3 provide a "python3" command, >> such as a python3.bat or python3.exe file, to help with scripts that rely >> on the interpreter being called "python3"? >> >> The py launcher is somewhat helpful, but a proper python3 runnable is >> preferable. >> > > Not when one has multiple python 3 installations. > > > -- > Terry Jan Reedy > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Windows: python3.exe missing
On 7/7/2017 5:45 PM, Andrew Pennebaker wrote: Could the Windows installer for Python 3 provide a "python3" command, such as a python3.bat or python3.exe file, to help with scripts that rely on the interpreter being called "python3"? The py launcher is somewhat helpful, but a proper python3 runnable is preferable. Not when one has multiple python 3 installations. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
Random832 wrote: What's not abstract is that if an object has address X and is N bytes long, those bytes (and any larger subobjects) occupy a contiguous range of addresses between X and X+(N-1). If you're talking about Python objects, that's not necessarily true -- there's no requirement that a Python object occupy a contiguous range of machine addresses. In CPython, many don't, e.g. strings. Even for those that do, it's a range of *virtual* addresses, which doeesn't necessarily correspond to contiguous physical addresses, e.g. if it crosses a page boundary. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Check Python version from inside script? Run Pythons script in v2 compatibility mode?
On Fri, Jul 7, 2017 at 3:49 PM, wrote: > Is there any particular reason the Windows python does it that way? > Certainly it wouldn't be too difficult to include a "python2.exe" and > "python3.exe", even as symbolic links. Windows associates file types with applications by extension. When you double click on "holygrail.py" should it open with python2.exe or python3.exe? In Unix this is solved with a shebang, so the main purpose of py.exe is to do the same: it's the standard open handler for .py files and it delegates out the actual execution to the appropriate Python version by examining the file for version hints. -- https://mail.python.org/mailman/listinfo/python-list
Re: Check Python version from inside script? Run Pythons script in v2 compatibility mode?
On Friday, July 7, 2017 at 2:54:04 AM UTC-5, Steve D'Aprano wrote: > [...] That's now not only backwards compatible, but it is > forward compatible: if Python changes in the future to > bring reduce back into the built-in functions, your code > will automatically keep working. If python starts going all paranoid schizoid on us, the few remaining holdovers from the good old days will be choosing another language. But don't worry Steven, even if i find a new favorite language, i will always drop in preiodically to say hi. ;-) > > Additional question: Is there a way to execute a python > > script with v3 python engine in v2 compatibility mode? Nope. Even the though the most hated software developer in history offers a compatibility mode for their users, Python does not. Python's philosophy is that you will accept Python3, or you will suffer... As for myself, i'm waiting for Python4. I will skip right over Python3. I say, let the other saps to suffer the migration headaches, because i don't need them. I'm too busy getting stuff done. -- https://mail.python.org/mailman/listinfo/python-list
Re: Check Python version from inside script? Run Pythons script in v2 compatibility mode?
On Friday, July 7, 2017 at 11:58:33 AM UTC-7, eryk sun wrote: > On Fri, Jul 7, 2017 at 7:53 AM, Steve D'Aprano > wrote: > > On Fri, 7 Jul 2017 04:30 pm, Ben S. wrote: > > > >> Is there a way to execute a python script with v3 python engine in v2 > >> compatibility mode? I am thinking about a command parameter like > >> (python.exe > >> is v3.*): > >> > >> python.exe -execute_as_v2 myscript.py > > > > No. Python 3 is always Python 3, and Python 2 is always Python 2. But what > > you > > can do is install both, and then call > > > > python2.exe myscript.py > > > > python3.exe anotherscript.py > > Windows Python installs two loaders for each version of Python: > python.exe and pythonw.exe. No links or copies are created for > pythonX[w].exe, pythonX.Y[w].exe, or pythonX.Y-32[w].exe. Instead, > there are separate py.exe and pyw.exe launchers that use the registry > to find and execute a loader for a given version, e.g. > > py -2 myscript.py > py -3.6-32 anotherscript.py > > As of 3.6, the py launcher defaults to the highest version of Python 3 > that's installed. 64-bit Python is preferred on 64-bit Windows. The > default version can be overridden by setting the PY_PYTHON environment > variable. > > That said, you don't have to manually run a script as an argument of > py.exe or python.exe. For a default Python 3 installation, if the > PATHEXT environment variable contains ".PY", then you can run > "script.py" as > > script arg1 ... argN > > in CMD or PowerShell. If a script has a Unix shebang, the launcher > will read it to run the required version of Python, if that version is > installed. Is there any particular reason the Windows python does it that way? Certainly it wouldn't be too difficult to include a "python2.exe" and "python3.exe", even as symbolic links. -- https://mail.python.org/mailman/listinfo/python-list
Windows: python3.exe missing
Could the Windows installer for Python 3 provide a "python3" command, such as a python3.bat or python3.exe file, to help with scripts that rely on the interpreter being called "python3"? The py launcher is somewhat helpful, but a proper python3 runnable is preferable. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python3 : import
On Friday, July 7, 2017 at 4:16:38 PM UTC-4, Ian wrote: > On Fri, Jul 7, 2017 at 2:00 PM, Andrew Z wrote: > > [az@hp tst1]$ python3 ./uno.py > > Traceback (most recent call last): > > File "./uno.py", line 1, in > > from . import db > > SystemError: Parent module '' not loaded, cannot perform relative import > > That error message is a bit confusing, but relative imports are > relative to packages, not directories. If the module is not part of a > package then it can't do a relative import. You can use an absolute > import, though: > > import db Thank you Ian. that's right on the money. All works now. I was missing the " ..relative imports are relative to packages, not directories. If the module is not part of a package then it can't do a relative import." thank you! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python3 : import
On Fri, Jul 7, 2017 at 2:00 PM, Andrew Z wrote: > [az@hp tst1]$ python3 ./uno.py > Traceback (most recent call last): > File "./uno.py", line 1, in > from . import db > SystemError: Parent module '' not loaded, cannot perform relative import That error message is a bit confusing, but relative imports are relative to packages, not directories. If the module is not part of a package then it can't do a relative import. You can use an absolute import, though: import db -- https://mail.python.org/mailman/listinfo/python-list
Re: Python3 : import
On Friday, July 7, 2017 at 4:00:51 PM UTC-4, Andrew Z wrote:
> this has bee driving me nutz for the past few hours.
> 2 modules are in the same directory. I want to be able to use them both:
>
> [code]
>
> [az@hp tst1]$ pwd
> /home/az/Dropbox/work/Prjs/tst1
>
> [az@hp tst1]$ ls -l
> total 16
> -rw-rw-r--. 1 az az 66 Jul 7 12:58 db.py
> -rw-rw-r--. 1 az az 182 Jul 7 15:54 uno.py
> [az@hp tst1]$
> [az@hp tst1]$
> [az@hp tst1]$ cat ./db.py
>
> class DB():
> def __init__(self):
> print("I'm DB")
>
> [az@hp tst1]$ cat ./uno.py
> from . import db
>
> class Uno():
> def __init__(self):
> print("I'm uno")
> self.db = db.DB()
>
> def printing(self):
> print("Uno.printing DB")
>
>
> if __name__ == '__main__':
> uno = Uno()
>
> [az@hp tst1]$
> [az@hp tst1]$
> [az@hp tst1]$ python3 ./uno.py
> Traceback (most recent call last):
> File "./uno.py", line 1, in
> from . import db
> SystemError: Parent module '' not loaded, cannot perform relative import
>
> [/code]
>
>
> Much obliged.
[az@hp tst1]$ python3 --version
Python 3.5.3
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python3 : import
On Friday, July 7, 2017 at 4:00:51 PM UTC-4, Andrew Z wrote:
> this has bee driving me nutz for the past few hours.
> 2 modules are in the same directory. I want to be able to use them both:
>
> [code]
>
> [az@hp tst1]$ pwd
> /home/az/Dropbox/work/Prjs/tst1
>
> [az@hp tst1]$ ls -l
> total 16
> -rw-rw-r--. 1 az az 66 Jul 7 12:58 db.py
> -rw-rw-r--. 1 az az 182 Jul 7 15:54 uno.py
> [az@hp tst1]$
> [az@hp tst1]$
> [az@hp tst1]$ cat ./db.py
>
> class DB():
> def __init__(self):
> print("I'm DB")
>
> [az@hp tst1]$ cat ./uno.py
> from . import db
>
> class Uno():
> def __init__(self):
> print("I'm uno")
> self.db = db.DB()
>
> def printing(self):
> print("Uno.printing DB")
>
>
> if __name__ == '__main__':
> uno = Uno()
>
> [az@hp tst1]$
> [az@hp tst1]$
> [az@hp tst1]$ python3 ./uno.py
> Traceback (most recent call last):
> File "./uno.py", line 1, in
> from . import db
> SystemError: Parent module '' not loaded, cannot perform relative import
>
> [/code]
>
>
> Much obliged.
Variations on the subject with the same sad results:
[code]
from .db import DB
[/code]
--
https://mail.python.org/mailman/listinfo/python-list
Python3 : import
this has bee driving me nutz for the past few hours.
2 modules are in the same directory. I want to be able to use them both:
[code]
[az@hp tst1]$ pwd
/home/az/Dropbox/work/Prjs/tst1
[az@hp tst1]$ ls -l
total 16
-rw-rw-r--. 1 az az 66 Jul 7 12:58 db.py
-rw-rw-r--. 1 az az 182 Jul 7 15:54 uno.py
[az@hp tst1]$
[az@hp tst1]$
[az@hp tst1]$ cat ./db.py
class DB():
def __init__(self):
print("I'm DB")
[az@hp tst1]$ cat ./uno.py
from . import db
class Uno():
def __init__(self):
print("I'm uno")
self.db = db.DB()
def printing(self):
print("Uno.printing DB")
if __name__ == '__main__':
uno = Uno()
[az@hp tst1]$
[az@hp tst1]$
[az@hp tst1]$ python3 ./uno.py
Traceback (most recent call last):
File "./uno.py", line 1, in
from . import db
SystemError: Parent module '' not loaded, cannot perform relative import
[/code]
Much obliged.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Check Python version from inside script? Run Pythons script in v2 compatibility mode?
On Fri, Jul 7, 2017 at 7:53 AM, Steve D'Aprano wrote: > On Fri, 7 Jul 2017 04:30 pm, Ben S. wrote: > >> Is there a way to execute a python script with v3 python engine in v2 >> compatibility mode? I am thinking about a command parameter like (python.exe >> is v3.*): >> >> python.exe -execute_as_v2 myscript.py > > No. Python 3 is always Python 3, and Python 2 is always Python 2. But what you > can do is install both, and then call > > python2.exe myscript.py > > python3.exe anotherscript.py Windows Python installs two loaders for each version of Python: python.exe and pythonw.exe. No links or copies are created for pythonX[w].exe, pythonX.Y[w].exe, or pythonX.Y-32[w].exe. Instead, there are separate py.exe and pyw.exe launchers that use the registry to find and execute a loader for a given version, e.g. py -2 myscript.py py -3.6-32 anotherscript.py As of 3.6, the py launcher defaults to the highest version of Python 3 that's installed. 64-bit Python is preferred on 64-bit Windows. The default version can be overridden by setting the PY_PYTHON environment variable. That said, you don't have to manually run a script as an argument of py.exe or python.exe. For a default Python 3 installation, if the PATHEXT environment variable contains ".PY", then you can run "script.py" as script arg1 ... argN in CMD or PowerShell. If a script has a Unix shebang, the launcher will read it to run the required version of Python, if that version is installed. -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get partition information of a hard disk with python
Strange. The OP's message didn't make it here, but I'm seeing multiple replies > On Wednesday, September 22, 2010 at 4:01:04 AM UTC+5:30, Hellmut > Weber wrote: > > Hi list, > > I'm looking for a possibility to access the partiton inforamtion > > of a hard disk of my computer from within a python program. You don't specify whether your disk has MBR, GPT, or some other partitioning scheme. However, at least for MBR, I threw together this code a while back: https://mail.python.org/pipermail/python-list/2009-November/559546.html I imagine something similar could be done in the case of a GPT. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
On Fri, Jul 7, 2017 at 8:41 AM, Nathan Ernst wrote: > Looks like single expression statements are handled a bit differently than > multiple expression statements: > > Python 3.5.2 (default, Nov 17 2016, 17:05:23) > [GCC 5.4.0 20160609] on linux > Type "help", "copyright", "credits" or "license" for more information. n = 4000; m = 4000; n is m > True n = 4000 m = 4000 n is m > False It actually has to do with units of compilation. In the first example, all three statements are compiled together and the constants are optimized to the same object. In the second example, because you're testing this in the REPL they're compiled at different times and since 4000 is larger than what CPython will intern, you end up with different objects. If however, you take the second example and gather it into a function, you'll get the compile-time optimization again: >>> def f(): ... n = 4000 ... m = 4000 ... return n is m ... >>> f() True -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
On Thu, Jul 6, 2017 at 12:56 PM, Nathan Ernst wrote: > In Python, "==" is not a reference equality operator (and I hate Java for > their misuse of the operator), so I absolutely disagree with using the Java > description to describe Python's "==" operator, primarily because, well, > it's wrong. Simple example: I thought it went without saying that the direct quote that I posted would need some revision before it would apply to Python. The parts about "objects or arrays" would also need to be changed, since Python doesn't have Java-like arrays. -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
On Fri, Jul 7, 2017, at 10:41, Nathan Ernst wrote:
> Looks like single expression statements are handled a bit differently
> than
> multiple expression statements:
>
> Python 3.5.2 (default, Nov 17 2016, 17:05:23)
> [GCC 5.4.0 20160609] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> n = 4000; m = 4000; n is m
> True
> >>> n = 4000
> >>> m = 4000
> >>> n is m
> False
Equal constants are combined (into a single object in the code object's
constant list - the compiler actually uses a dictionary internally) at
compile time, when you execute two separate lines in the interactive
interpreter they are compiled separately.
I would call your first case multiple statements on a line, not multiple
expressions in one statement. But what's important is the separate lines
of the interactive interpreter and therefore separate compile contexts -
if you were to do exec('n=4000\nm=4000') you would get a single object.
With a sufficiently small number (between 0 and 256 inclusive), they are
globally cached and you will get the same object even across separate
compilations, because the compiler gets the same object when it parses
"10" in the first place.
Imagine more or less, this process:
d = {}
a = int("4000")
if a in d: i = d[a]
else: i = d[a] = len(d)
b = int("4000")
if b in d: j =d[b]
else: j = d[b] = len(d)
c = d.keys()
n = c[i]
m = c[j]
When you do it on two separate prompts you get:
d = {}
a = int("4000")
if a in d: i = d[a]
else: i = d[a] = len(d)
c = d.keys()
n = c[i]
d = {}
a = int("4000")
if a in d: i = d[a]
else: i = d[a] = len(d)
c = d.keys()
m = c[i]
--
https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
On Fri, Jul 7, 2017, at 04:12, Gregory Ewing wrote: > Only if you interpret the word "address" very narrowly. > > By the way, even the low-level notion of "address" that C > programs deal with is, on most modern hardware, a *virtual* > address that goes through a level of translation before it > identifies a physical set of transistors, and that mapping > can change as stuff gets paged in and out. So it's already > an abstract concept to some extent. What's not abstract is that if an object has address X and is N bytes long, those bytes (and any larger subobjects) occupy a contiguous range of addresses between X and X+(N-1). This is not required to be true of Python IDs. -- https://mail.python.org/mailman/listinfo/python-list
Re: Test 0 and false since false is 0
Nathan Ernst wrote: > On Fri, Jul 7, 2017 at 2:04 AM, Peter Otten <__pete...@web.de> wrote: >> >>> sorted([0.0, 0, False, [], "x"], key=lambda x: x == 0 and type(x) == >> int) >> [0.0, False, [], 'x', 0] > You'd be better off using the builtin "isinstance" function, e.g.: > isinstance(x, int). This also has the added benefit of working nicely with > inheritance (isinstance returns true if the actual type is derived from > the classinfo passed as the second argument). See > https://docs.python.org/3/library/functions.html#isinstance for details. Hm, I suggest that you run my code sample above with your suggested improvement ;) -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
Looks like single expression statements are handled a bit differently than multiple expression statements: Python 3.5.2 (default, Nov 17 2016, 17:05:23) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> n = 4000; m = 4000; n is m True >>> n = 4000 >>> m = 4000 >>> n is m False >>> On Fri, Jul 7, 2017 at 2:29 AM, Dan Wissme wrote: > Le 06/07/2017 à 20:56, Nathan Ernst a écrit : > >> In Python, "==" is not a reference equality operator (and I hate Java for >> their misuse of the operator), so I absolutely disagree with using the >> Java >> description to describe Python's "==" operator, primarily because, well, >> it's wrong. Simple example: >> >> With Python 3.5.2 (should hold for any version 2.4 or greater): >> >>> a = 1 > b = 1 > a == b > True >> >>> a is b > True >> >>> c = 1000 > d = 1000 > c == d > True >> >>> c is d > False >> > > Strange behavior in Python 3.6.0 > >>> i = 3000 > >>> j = 3000 > >>> i is j > False > >>> n = 4000 ; m = 4000 ; n is m > True > > dan > > > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Test 0 and false since false is 0
You'd be better off using the builtin "isinstance" function, e.g.:
isinstance(x, int). This also has the added benefit of working nicely with
inheritance (isinstance returns true if the actual type is derived from the
classinfo passed as the second argument). See
https://docs.python.org/3/library/functions.html#isinstance for details.
Regards,
Nathan
On Fri, Jul 7, 2017 at 2:04 AM, Peter Otten <__pete...@web.de> wrote:
> Sayth Renshaw wrote:
>
> > I was trying to solve a problem and cannot determine how to filter 0's
> but
> > not false.
> >
> > Given a list like this
> > ["a",0,0,"b",None,"c","d",0,1,False,0,1,0,3,[],0,1,9,0,0,{},0,0,9]
> >
> > I want to be able to return this list
> > ["a","b",None,"c","d",1,False,1,3,[],1,9,{},9,0,0,0,0,0,0,0,0,0,0]
> >
> > However if I filter like this
> >
> > def move_zeros(array):
> > l1 = [v for v in array if v != 0]
> > l2 = [v for v in array if v == 0]
> > return l1 + l2
> >
> > I get this
> > ['a', 'b', None, 'c', 'd', 1, 1, 3, [], 1, 9, {}, 9, 0, 0, 0, False, 0,
> 0,
> > [0, 0, 0, 0, 0]
> >
> > I have tried or conditions of v == False etc but then the 0's being false
> > also aren't moved. How can you check this at once?
> >
> >
> > Cheers
> >
> > Sayth
>
> Another option is to test for type(value) == int:
>
> >>> before = ["a",0,0,"b",None,"c","d",0,1,False,0,1,0,3,[],0,1,9,0,0,
> {},0,0,9]
> >>> wanted = ["a","b",None,"c","d",1,False,1,3,[],1,9,
> {},9,0,0,0,0,0,0,0,0,0,0]
> >>> after = sorted(before, key=lambda x: x == 0 and type(x) == int)
> >>> assert str(after) == str(wanted)
> >>> after
> ['a', 'b', None, 'c', 'd', 1, False, 1, 3, [], 1, 9, {}, 9, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0]
>
>
> That way float values will be left alone, too:
>
> >>> sorted([0.0, 0, False, [], "x"], key=lambda x: x == 0 and type(x) ==
> int)
> [0.0, False, [], 'x', 0]
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Test 0 and false since false is 0
On 2017-07-07, Stefan Ram wrote: > Sayth Renshaw writes: >>I have tried or conditions of v == False etc but then the 0's >>being false also aren't moved. How can you check this at >>once? > > »The Boolean type is a subtype of the integer type, and > Boolean values behave like the values 0 and 1, > respectively, in almost all contexts, the exception > being that when converted to a string, the strings > "False" or "True" are returned, respectively.« > > The Python Language Reference, Release 3.6.0; > 3.2 The standard type hierarchy > > So maybe you can add a test for the type? > def isfalse( x ): > ... return x == 0 and str( type( x )) == "" > ... What's wrong with the following? x is False Isn't False a singleton value? -- Grant Edwards grant.b.edwardsYow! I want a VEGETARIAN at BURRITO to go ... with gmail.comEXTRA MSG!! -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
On Fri, Jul 7, 2017 at 9:48 PM, Marko Rauhamaa wrote: > Chris Angelico : > >> On Fri, Jul 7, 2017 at 7:15 PM, Marko Rauhamaa wrote: >>> You can only define the semantics of Python (in this case) by >>> providing an *arbitrary* mapping to an imaginary abstract machine. >>> There's no way to define the objective abstraction. >> >> So aside from an artificial sense of purity, what's the point in >> defining object identity *at all*? Why invent an arbitrary number that >> you can't even see? > > Without such an invisible identity, you can't specify the desired > behavior of a Python program. (Well, id() returns a visible identity, > which you could equate with the invisible one.) > > I understand that not everything should be strictly formal, but all > attempts at clarifying Python's object system necessarily involve > evoking some silly abstract model. "x is y" returns True if and only if x and y refer to the same object. You have yet to demonstrate that the above statement is underspecified. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
Chris Angelico : > On Fri, Jul 7, 2017 at 7:15 PM, Marko Rauhamaa wrote: >> You can only define the semantics of Python (in this case) by >> providing an *arbitrary* mapping to an imaginary abstract machine. >> There's no way to define the objective abstraction. > > So aside from an artificial sense of purity, what's the point in > defining object identity *at all*? Why invent an arbitrary number that > you can't even see? Without such an invisible identity, you can't specify the desired behavior of a Python program. (Well, id() returns a visible identity, which you could equate with the invisible one.) I understand that not everything should be strictly formal, but all attempts at clarifying Python's object system necessarily involve evoking some silly abstract model. The Lisp community is so old they never thought of shunning hardware concepts (storage, pointers, Common Address Register, Common Data Register etc). There doesn't seem to be any better way for Python, either. It might be easiest to say that every Python object has an address and id() returns it. Even if you were lying, nobody would be able to call your bluff. Then, explaining objects to newcomers would be a bit more straightforward. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
On Fri, Jul 7, 2017 at 7:15 PM, Marko Rauhamaa wrote: > Chris Angelico : > >> On Fri, Jul 7, 2017 at 6:43 PM, Marko Rauhamaa wrote: >>> Python's integer object 0 might be equated with the (mathematical) >>> natural number 18974387634. Python code would have no way of >>> introspecting that natural number. >>> >>> The execution model would determine what properties object 18974387634 >>> would have. >> >> Then what's the point of that number? If you can't see it from Python >> code, it's not part of the language semantics. > > Excellent question!!! > > In fact, it is a very frustrating question. You can only define the > semantics of Python (in this case) by providing an *arbitrary* mapping > to an imaginary abstract machine. There's no way to define the objective > abstraction. So aside from an artificial sense of purity, what's the point in defining object identity *at all*? Why invent an arbitrary number that you can't even see? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Check Python version from inside script? Run Pythons script in v2 compatibility mode?
Pavol Lisy :
> On 7/7/17, Steve D'Aprano wrote:
>
>> import sys
>> if sys.version_info >= (3,): # the comma is important
>> print("version 3")
>
> But be careful inside script! It could live long enough to see python4
> :)
That's a serious concern. An application doesn't know about Python's
future. What would be needed is:
import sys
try:
sys.require_version((3, 4, 2))
except NotSupportedException:
sys.stderr.write("Sorry :(\n")
sys.exit(1)
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: Check Python version from inside script? Run Pythons script in v2 compatibility mode?
On 7/7/17, Steve D'Aprano wrote:
> import sys
> if sys.version_info >= (3,): # the comma is important
> print("version 3")
But be careful inside script! It could live long enough to see python4 :)
--
https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
Chris Angelico :
> On Fri, Jul 7, 2017 at 6:43 PM, Marko Rauhamaa wrote:
>> Python's integer object 0 might be equated with the (mathematical)
>> natural number 18974387634. Python code would have no way of
>> introspecting that natural number.
>>
>> The execution model would determine what properties object 18974387634
>> would have.
>
> Then what's the point of that number? If you can't see it from Python
> code, it's not part of the language semantics.
Excellent question!!!
In fact, it is a very frustrating question. You can only define the
semantics of Python (in this case) by providing an *arbitrary* mapping
to an imaginary abstract machine. There's no way to define the objective
abstraction.
Metamathematicians grappled with the same problem a century ago when
they tried to define natural numbers. Their promising start collapsed
because of the Russel paradox. To their great disappointment, they had
to choose an arbitrary set-theoretical model to be the standard:
0 = {}
1 = {0}
2 = {0, 1}
3 = {0, 1, 2}
etc
In fact, today's mathematicians couldn't care less what natural numbers
are. They have captured all relevant characteristics in a number axioms,
and those suffice to generate all interesting mathematics.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
On Fri, Jul 7, 2017 at 6:58 PM, Marko Rauhamaa wrote: > Steve D'Aprano : > >> But the Python virtual machine doesn't require objects to have an >> address at all. > > That's an interesting question. Is it possible to define formal > semantics for Python without the notion of an address (under some name)? > Ultimately it seems necessary to have an enumerable set (address space) > that maps to objects. Yes, it most definitely is. I have explained Python's object model on the kitchen table, using sheets of paper, and pencil lines/arrows representing references. Aside from being tedious, and being vulnerable to an accidental brush of the sleeve, this is a fully compliant Python interpreter. (And when we were done, the entire heap was garbage collected simultaneously.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
Steve D'Aprano : > But the Python virtual machine doesn't require objects to have an > address at all. That's an interesting question. Is it possible to define formal semantics for Python without the notion of an address (under some name)? Ultimately it seems necessary to have an enumerable set (address space) that maps to objects. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
Steve D'Aprano : > On Fri, 7 Jul 2017 05:45 pm, Chris Angelico wrote: > >> On Fri, Jul 7, 2017 at 4:43 PM, Steve D'Aprano >> wrote: >>> On Fri, 7 Jul 2017 01:41 am, Marko Rauhamaa wrote: In Second-Order Logic, you can define identity directly: ∀x ∀y x = y ↔ ∀P (P(x) ↔ P(y)) >>> >>> Translating to English: >>> >>> For all x, for all y, x equals y if and only if for all P >>> (P(x) if and only if P(y)) >>> >>> [...] >> >> It sounds to me like this has defined equality, not identity, right? > > In mathematics, I believe that equality and identity in this sense are > the same, and we could spell the mathematical operator "=" as "is" > instead. Mathematicians call the principle "extensionality" (https://en.wikipedia.org/wiki/Extensionality>). Python programmers call it duck-typing. That's why in set theory, you talk about "the empty set". Any two sets that satisfy the conditions for an empty set are indistinguishable and therefore identical: ∀x ∀y (∀z z ∈ x ↔ z ∈ y) ↔ x = y Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
On Fri, Jul 7, 2017 at 6:43 PM, Marko Rauhamaa wrote: > Steve D'Aprano : > >> On Fri, 7 Jul 2017 07:10 am, Marko Rauhamaa wrote: >> >>> I believe identity can be defined much better, in numerous isomorphic >>> ways in fact. >>> >>> For example, we could equate each object with a sequence number >>> (unrelated with its id()). You can define that the "None" object is >>> in fact the natural number 0. The "False" object is in fact the >>> natural number 1 etc for all the primordial objects. During the >>> execution of the program, new objects are created, which simply >>> associates characteristics to ever higher natural numbers. >> >> Hmmm... interesting. You might just be on the right track here. That >> might even work for "identity" as required by Python. >> >> Of course you can't say "equate each object with its sequence number" >> since that implies that: >> >> assert None == 0 > > Python's integer object 0 might be equated with the (mathematical) > natural number 18974387634. Python code would have no way of > introspecting that natural number. > > The execution model would determine what properties object 18974387634 > would have. Then what's the point of that number? If you can't see it from Python code, it's not part of the language semantics. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
On Fri, 7 Jul 2017 06:12 pm, Gregory Ewing wrote: > Steve D'Aprano wrote: >> That implies that it is impossible to implement Scheme: >> >> - using a programming language where variables and objects may move during >> their lifetime; >> >> - or using a computing device without conventional memory, e.g. implementing >> Scheme using hydraulics, DNA computing, clockwork, or emulated in the human >> brain. > > Only if you interpret the word "address" very narrowly. I don't know about that. Consider emulating a Python interpreter in your own brain by executing in your own head some code that you read. Where in your brain do the objects (the values) live? From everything we know about the brain, they will be distributed across great big swaths of the brain, over billions of neurons, and there is nowhere we could point to and say "this is where our mental model of this object is". The best we could say is that "if we damage such and such an area of the brain, then the victim will be unable to perform the task of executing Python code in his head, therefore we think that the objects are distributed in that area rather than another area". > By the way, even the low-level notion of "address" that C > programs deal with is, on most modern hardware, a *virtual* > address that goes through a level of translation before it > identifies a physical set of transistors, and that mapping > can change as stuff gets paged in and out. So it's already > an abstract concept to some extent. Indeed. But the Python virtual machine doesn't require objects to have an address at all. Spacial thinking is so important for us primates that it is hard for us puny humans to think of values without thinking of them existing in some location, but there's no logical requirement for that to be the case. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
Steve D'Aprano : > On Fri, 7 Jul 2017 07:10 am, Marko Rauhamaa wrote: > >> I believe identity can be defined much better, in numerous isomorphic >> ways in fact. >> >> For example, we could equate each object with a sequence number >> (unrelated with its id()). You can define that the "None" object is >> in fact the natural number 0. The "False" object is in fact the >> natural number 1 etc for all the primordial objects. During the >> execution of the program, new objects are created, which simply >> associates characteristics to ever higher natural numbers. > > Hmmm... interesting. You might just be on the right track here. That > might even work for "identity" as required by Python. > > Of course you can't say "equate each object with its sequence number" > since that implies that: > > assert None == 0 Python's integer object 0 might be equated with the (mathematical) natural number 18974387634. Python code would have no way of introspecting that natural number. The execution model would determine what properties object 18974387634 would have. > Are you satisfied now? Can we please put this debate to bed? Feel free to stop replying. These kinds of debate keep on going forever because you still don't understand what I'm getting at (and probably vice versa). Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
On Fri, 7 Jul 2017 06:05 pm, Gregory Ewing wrote: > Steve D'Aprano wrote: >> In practice, identity is hardly important in Python, except for a few limited >> cases, and the prohibition against using `is` when you mean `==`. > > On the contrary, it's a very important concept needed to make > sense of the way things behave when mutation is involved. > > Witness e.g. the classic newbie mistake of using [[0]*5]*5 > to create a matrix of zeroes. I don't know how to explain > why that goes wrong without using the phrase "same object" > in some way. That would be one of the few limited cases I mentioned :-) I'll grant you that having the concept of "the same object" can be important. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
On Fri, 7 Jul 2017 05:45 pm, Chris Angelico wrote: > On Fri, Jul 7, 2017 at 4:43 PM, Steve D'Aprano > wrote: >> On Fri, 7 Jul 2017 01:41 am, Marko Rauhamaa wrote: >>> In Second-Order Logic, you can define identity directly: >>> >>> ∀x ∀y x = y ↔ ∀P (P(x) ↔ P(y)) >> >> Translating to English: >> >> For all x, for all y, x equals y if and only if for all P >> (P(x) if and only if P(y)) >> >> >> That might be sufficient for second-order logic, but it won't do for >> programming. Defining if-and-only-if for functions that can return more than >> two values (true and false) requires having a definition of equality, which >> would make the definition circular. > > It sounds to me like this has defined equality, not identity, right? In mathematics, I believe that equality and identity in this sense are the same, and we could spell the mathematical operator "=" as "is" instead. Mathematicians normally use the word "identity" to refer to things like the identity function f(x) -> x, or the identity matrix [1 0][0 1] say, or the multiplicative identity (usually 1), rather than talking about "the identity of a value" since that would be redundant: the identity of the value is the value of the value which is the value. But programming languages can have values which are equal but not identical, such as 1 and 1.0. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
On Fri, 7 Jul 2017 05:29 pm, Dan Wissme wrote: > Strange behavior in Python 3.6.0 > >>> i = 3000 > >>> j = 3000 > >>> i is j > False > >>> n = 4000 ; m = 4000 ; n is m > True The Python interpreter is allowed to cache integers and reuse them. The interactive interpreter sometimes does so: if you write the same int literal on the same line in the interactive interpreter, it may re-use the same object instead of creating two equal objects. You should **NEVER** use `is` when you want to check for equality. You cannot rely on Python to cache or not cache int values. Whatever it does is purely an implementation detail that is subject to change without notice. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
Steve D'Aprano wrote: That implies that it is impossible to implement Scheme: - using a programming language where variables and objects may move during their lifetime; - or using a computing device without conventional memory, e.g. implementing Scheme using hydraulics, DNA computing, clockwork, or emulated in the human brain. Only if you interpret the word "address" very narrowly. By the way, even the low-level notion of "address" that C programs deal with is, on most modern hardware, a *virtual* address that goes through a level of translation before it identifies a physical set of transistors, and that mapping can change as stuff gets paged in and out. So it's already an abstract concept to some extent. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
Marko Rauhamaa wrote: In Second-Order Logic, you can define identity directly: ∀x ∀y x = y ↔ ∀P (P(x) ↔ P(y)) That looks more like a definition of *equality* to me. In mathematics, everything is immutable, so there isn't really any distinction between equality and identity. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
Steve D'Aprano wrote: In practice, identity is hardly important in Python, except for a few limited cases, and the prohibition against using `is` when you mean `==`. On the contrary, it's a very important concept needed to make sense of the way things behave when mutation is involved. Witness e.g. the classic newbie mistake of using [[0]*5]*5 to create a matrix of zeroes. I don't know how to explain why that goes wrong without using the phrase "same object" in some way. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
On Fri, Jul 7, 2017 at 5:29 PM, Dan Wissme wrote:
> Strange behavior in Python 3.6.0
i = 3000
j = 3000
i is j
> False
n = 4000 ; m = 4000 ; n is m
> True
Firstly, remember that immutables are allowed, but not required, to be
shared. So this kind of "strange behaviour" is completely fine - and
furthermore, can come and go at any time.
What you're seeing here is an artifact of the interactive interpreter.
Each statement or block that you enter gets compiled and executed on
its own. When you do the last block, the compiler looks at the whole
thing, and produces this code:
>>> c = compile("n = 4000 ; m = 4000 ; n is m", "", "single")
>>> c.co_consts
(4000, None)
>>> dis.dis(c)
1 0 LOAD_CONST 0 (4000)
2 STORE_NAME 0 (n)
4 LOAD_CONST 0 (4000)
6 STORE_NAME 1 (m)
8 LOAD_NAME0 (n)
10 LOAD_NAME1 (m)
12 COMPARE_OP 8 (is)
14 PRINT_EXPR
16 LOAD_CONST 1 (None)
18 RETURN_VALUE
The print and return at the end are how the REPL works. The rest is your code.
The compiler noticed that it needed to load the constant integer 4000
twice, so it put it into the co_consts collection once and used the
same integer object each time.
Armed with that information, it should be easy to see why your 3000
example returned False. Each of the assignments was compiled
separately, and the compiler didn't look at previous compilations to
reuse an integer. Thus the two are separate objects. The compiler
COULD, if it felt like it, reuse that; conversely, a naive and
inefficient compiler is welcome to generate brand new integers for n
and m. Actually, I believe a compliant Python interpreter is welcome
to not store integer objects in memory at all, as long as it can
guarantee the correct identity semantics (eg the 'is' and 'is not'
operators on integers would be defined on value, and id(x) would
return x*2+1 for ints and even numbers for other objects), although I
don't know of any implementations that do this.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Check Python version from inside script? Run Pythons script in v2 compatibility mode?
On Fri, 7 Jul 2017 04:30 pm, Ben S. wrote:
> Can I somehow check from inside a Python script if the executing Python engine
> is major version v2 or v3?
Yes you can, but generally speaking you shouldn't.
import sys
if sys.version_info >= (3,): # the comma is important
print("version 3")
else:
print("version 2")
But keep in mind that your code must be syntactically valid for the running
version regardless of the result of the test. This will **NOT** work:
import sys
if sys.version_info >= (3,): # the comma is important
print("version 3")
else:
print "version 2" # Python 2 syntax
Earlier I said that in general you shouldn't test for the version. Normally you
should test for a specific feature, not for the version number. For example,
suppose I want to use the "reduce()" function. In Python 2 it is a built-in
function, but in Python 3 it is moved into the functools module.
Don't do this:
if sys.version_info >= (3,):
from functools import reduce
This is better:
try:
reduce
except NameError:
# reduce no longer defined as a built-in
from functools import reduce
That's now not only backwards compatible, but it is forward compatible: if
Python changes in the future to bring reduce back into the built-in functions,
your code will automatically keep working.
Dealing with syntax changes in hybrid version 2 + 3 code is quite tricky. It can
be done, but it is painful, even for experts.
> Additional question:
> Is there a way to execute a python script with v3 python engine in v2
> compatibility mode? I am thinking about a command parameter like (python.exe
> is v3.*):
>
> python.exe -execute_as_v2 myscript.py
No. Python 3 is always Python 3, and Python 2 is always Python 2. But what you
can do is install both, and then call
python2.exe myscript.py
python3.exe anotherscript.py
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
On Fri, Jul 7, 2017 at 4:43 PM, Steve D'Aprano wrote: > On Fri, 7 Jul 2017 01:41 am, Marko Rauhamaa wrote: >> In Second-Order Logic, you can define identity directly: >> >> ∀x ∀y x = y ↔ ∀P (P(x) ↔ P(y)) > > Translating to English: > > For all x, for all y, x equals y if and only if for all P > (P(x) if and only if P(y)) > > > That might be sufficient for second-order logic, but it won't do for > programming. Defining if-and-only-if for functions that can return more than > two values (true and false) requires having a definition of equality, which > would make the definition circular. It sounds to me like this has defined equality, not identity, right? In Python, you could have x and y be two different integers with the same value, and the return values of all functions would be indistinguishable. Unless you're including the 'id' function, in which case... welcome to circular reasoning again. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
On 07/07/2017 07:42, Steve D'Aprano wrote: On Fri, 7 Jul 2017 03:05 am, Marko Rauhamaa wrote: ... [1] It may actually be instinctive -- there are studies that show that even young babies express surprise when they see something that violates the intuitive properties of identity. For example, if you pass a toy in front of the baby, then behind a screen, and swap it for a different toy before showing it again, babies tend to express surprise. presumably this is after they learn (or make the assumption) of object permanence. -stuffed-with-assumptions-ly yrs- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: Test 0 and false since false is 0
you can use the "is" for identity test.
l1 = [v for v in array if not v is 0]
l2 = [v for v in array if v is 0]
On Jul 6, 2017, at 10:31 PM, Sayth Renshaw
mailto:flebber.c...@gmail.com>> wrote:
I was trying to solve a problem and cannot determine how to filter 0's but not
false.
Given a list like this
["a",0,0,"b",None,"c","d",0,1,False,0,1,0,3,[],0,1,9,0,0,{},0,0,9]
I want to be able to return this list
["a","b",None,"c","d",1,False,1,3,[],1,9,{},9,0,0,0,0,0,0,0,0,0,0]
However if I filter like this
def move_zeros(array):
l1 = [v for v in array if v != 0]
l2 = [v for v in array if v == 0]
return l1 + l2
I get this
['a', 'b', None, 'c', 'd', 1, 1, 3, [], 1, 9, {}, 9, 0, 0, 0, False, 0, 0, 0,
0, 0, 0, 0]
I have tried or conditions of v == False etc but then the 0's being false also
aren't moved. How can you check this at once?
Cheers
Sayth
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
Le 06/07/2017 à 20:56, Nathan Ernst a écrit : In Python, "==" is not a reference equality operator (and I hate Java for their misuse of the operator), so I absolutely disagree with using the Java description to describe Python's "==" operator, primarily because, well, it's wrong. Simple example: With Python 3.5.2 (should hold for any version 2.4 or greater): a = 1 b = 1 a == b True a is b True c = 1000 d = 1000 c == d True c is d False Strange behavior in Python 3.6.0 >>> i = 3000 >>> j = 3000 >>> i is j False >>> n = 4000 ; m = 4000 ; n is m True dan -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get partition information of a hard disk with python
On 07/07/2017 07:18, palashkhair...@gmail.com wrote:
On Wednesday, September 22, 2010 at 4:01:04 AM UTC+5:30, Hellmut Weber wrote:
Hi list,
I'm looking for a possibility to access the partiton inforamtion of a
hard disk of my computer from within a python program.
Googling I found the module 'parted' but didn't see any possibility to
get the desired information.
Is there any reasonable documentation for the parted module?
Any idea is appreciated ;-)
import os
os.system("fdisk -l")
#you will get information about your hdd,partition
psutil is usually good for these sort of things:
http://pythonhosted.org/psutil/#disks
TJG
--
https://mail.python.org/mailman/listinfo/python-list
RE: Test 0 and false since false is 0
> From: Dan Sommers > > > On Thu, 06 Jul 2017 19:29:00 -0700, Sayth Renshaw wrote: > > > > I have tried or conditions of v == False etc but then the 0's being > > false also aren't moved. How can you check this at once? > > Maybe this will help: > > Python 3.5.3+ (default, Jun 7 2017, 23:23:48) > [GCC 6.3.0 20170516] on linux > Type "help", "copyright", "credits" or "license" for more > information. > >>> False == 0 > True > >>> False is 0 > False Funny how the subject line inadvertently prefigures the answer: False *isn't* 0. False *equals* 0. So just change "==" to "is" and "!=" to "is not" and it should work. Also, it can be done in a single expression, with no local variables. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Check Python version from inside script? Run Pythons script in v2 compatibility mode?
"Ben S. via Python-list" writes: > Can I somehow check from inside a Python script if the executing Python > engine is major version v2 or v3? import sys sys.version_info[0] (If you just need to print() consistently, you should follow Terry's advice) -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
On Fri, 7 Jul 2017 07:10 am, Marko Rauhamaa wrote: > I believe identity can be defined much better, in numerous isomorphic > ways in fact. > > For example, we could equate each object with a sequence number > (unrelated with its id()). You can define that the "None" object is in > fact the natural number 0. The "False" object is in fact the natural > number 1 etc for all the primordial objects. During the execution of the > program, new objects are created, which simply associates > characteristics to ever higher natural numbers. Hmmm... interesting. You might just be on the right track here. That might even work for "identity" as required by Python. Of course you can't say "equate each object with its sequence number" since that implies that: assert None == 0 assert False == 1 assert True == 2 should all succeed. Rather we would say that we associate each object with its sequence number. Then we say two objects are the same object if they have the same sequence number. Further more, we could relax the condition that the sequence number be assigned on object creation. Eventually the sequence number will be pretty big, and constructing that number would be time consuming. Since most objects never get compared for identity, why bother pre-allocating the sequence number? It can be allocated if and when needed. Replace the term "sequence number" with "ID number" and you have IronPython and Jython. Since objects can be destroyed as well as created, when an object is destroyed, we can push its sequence number into a pool of free sequence numbers. This reuse could help prevent sequence numbers from growing arbitrarily large. Then the next object which is created can reuse one of the sequence numbers from the free pool, instead of a new one. We can go further: rather than explicitly store the sequence number, it would be nice if we could find something in the environment that already exists, that can be guaranteed to be unique, and in at least some programming languages, is guaranteed to be stable for the life time of the object (until it is destroyed). If we allocated objects in a giant array, its position in the array could be treated as its sequence number. That way we don't have to explicitly record free sequence numbers: when we allocate an object in the array, provided it goes into a free slot, it automatically reuses the appropriate sequence number. In fact, for programming environments that use a memory heap model, we don't even need the giant array... we can use the heap itself as conceptually the giant array, and the memory address as the sequence number, so long as we give up on the requirement that we start sequence numbers at 0. Of course this only works for implementations where objects can't move around in the heap. Substitute the term "sequence number" with "ID number" and you have CPython. So... We say two objects are the same object if they have the same sequence number. Replacing the term "sequence number" with "ID number", and we say: Two objects are the same object if they have the same ID number. Are you satisfied now? Can we please put this debate to bed? -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
On Fri, 7 Jul 2017 07:10 am, Marko Rauhamaa wrote: > Steve D'Aprano : > >> An address is a concrete location or place, in other words a physical >> position in some space, while identity is the abstract state or >> quality of being identical (sameness), in other words a state of >> being. > > Whether id() returns one such thing or not can't be discerned by a > Python program. Since the id() function isn't documented as returning an address, I'm not sure why you think that it is significant that Python programs can't discern such a thing. > What's more, for any compliant implementation of id(), > you can interpret the returned number as an address in some address > space (whether it's useful or not to interpret it that way). You could equally interpret it as: - the IQ of the person reading the output; - the number of legs on the average insect; - the number of times per day the average teenager says "I don't even"; - the number of days in a month; - the amount of memory in terabytes required to store that object; - the number of atoms of hydrogen in Moscow; or - cost in US dollars in lost productivity caused by this discussion whether it's useful or not to interpret it that way. You are free to interpret it as anything you like, whether or not it is useful is up to you. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: About the implementation of del in Python 3
Steve D'Aprano : > On Fri, 7 Jul 2017 03:38 am, Marko Rauhamaa wrote: > >> Notice that Scheme refers directory to conventional RAM: >> >> Variables and objects such as pairs, vectors, and strings implicitly >> denote locations > > > That implies that it is impossible to implement Scheme: > > - using a programming language where variables and objects may move > during their lifetime; > > - or using a computing device without conventional memory, e.g. > implementing Scheme using hydraulics, DNA computing, clockwork, or > emulated in the human brain. > > I think that's pretty crap. It might be justifiable to define a > language like C to a specific hardware implementation, but > higher-level languages like Scheme should be more abstract. You are misunderstanding. Your implementation doesn't have to match the abstract machine as long as it produces the same behavior. They could be defining it using a Turing machine, but that doesn't mean a Scheme runtime would necessarily need a mile-long paper tape. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Test 0 and false since false is 0
Sayth Renshaw wrote:
> I was trying to solve a problem and cannot determine how to filter 0's but
> not false.
>
> Given a list like this
> ["a",0,0,"b",None,"c","d",0,1,False,0,1,0,3,[],0,1,9,0,0,{},0,0,9]
>
> I want to be able to return this list
> ["a","b",None,"c","d",1,False,1,3,[],1,9,{},9,0,0,0,0,0,0,0,0,0,0]
>
> However if I filter like this
>
> def move_zeros(array):
> l1 = [v for v in array if v != 0]
> l2 = [v for v in array if v == 0]
> return l1 + l2
>
> I get this
> ['a', 'b', None, 'c', 'd', 1, 1, 3, [], 1, 9, {}, 9, 0, 0, 0, False, 0, 0,
> [0, 0, 0, 0, 0]
>
> I have tried or conditions of v == False etc but then the 0's being false
> also aren't moved. How can you check this at once?
>
>
> Cheers
>
> Sayth
Another option is to test for type(value) == int:
>>> before = ["a",0,0,"b",None,"c","d",0,1,False,0,1,0,3,[],0,1,9,0,0,
{},0,0,9]
>>> wanted = ["a","b",None,"c","d",1,False,1,3,[],1,9,
{},9,0,0,0,0,0,0,0,0,0,0]
>>> after = sorted(before, key=lambda x: x == 0 and type(x) == int)
>>> assert str(after) == str(wanted)
>>> after
['a', 'b', None, 'c', 'd', 1, False, 1, 3, [], 1, 9, {}, 9, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0]
That way float values will be left alone, too:
>>> sorted([0.0, 0, False, [], "x"], key=lambda x: x == 0 and type(x) ==
int)
[0.0, False, [], 'x', 0]
--
https://mail.python.org/mailman/listinfo/python-list
Re: Check Python version from inside script? Run Pythons script in v2 compatibility mode?
On 7/7/2017 2:30 AM, Ben S. via Python-list wrote:
Can I somehow check from inside a Python script if the executing Python engine
is major version v2 or v3?
I am thinking about a code similar to
if (os.python-majorversion<3)
print hello
else
print (hello)
For this, just use print('hello').
Checkout 'from __future__ import print_function'
check __future__ module for spelling.
Checkout sys.version, sys.hexversion, platform module,
Some import will tell you.
try:
import tkinter as tk
pyversion = 3
except ImportError:
import Tkinter as tk
pyversion = 2
Additional question:
Is there a way to execute a python script with v3 python engine in v2
compatibility mode?
I am thinking about a command parameter like (python.exe is v3.*):
python.exe -execute_as_v2 myscript.py
No.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
