Re: Python handles globals badly.
On Sat, 12 Sep 2015 01:03 am, Ian Kelly wrote:
> On Fri, Sep 11, 2015 at 2:42 AM, Steven D'Aprano
> wrote:
[...]
>> Almost. If it's never assigned within the function, then it is looked up
>> according to the non-local scoping rules:
>>
>> - closures and enclosing functions (if any);
>> - globals;
>> - builtins;
>>
>> in that order.
>
> I excluded non-locals intentionally, but if you want to be pedantic
> about it, then that's still not quite right. Non-locals are indeed
> identified by the compiler and compiled with the
> LOAD_DEREF/STORE_DEREF opcodes (rather than the _GLOBAL and _FAST
> variants used by globals and locals, respectively).
Ah, nice, yes I forgot about that, thanks for the correction.
> The compiler
> doesn't make any such distinction between globals and builtins
> however, as that can only be determined at run-time.
>
>> There's also a bunch of specialised and complicated rules for what
>> happens if you make a star import ("from module import *") inside a
>> function, or call eval or exec without specifying a namespace. Both of
>> these things are now illegal in Python 3.
>
> Huh?
>
exec("x = 42")
x
> 42
exec("x = 43", None, None)
x
> 43
>
> That's in Python 3.4.0. Maybe I don't understand what you mean by
> "without specifying a namespace".
Inside a function star imports are illegal in Python 3:
py> def f():
... from math import *
...
File "", line 1
SyntaxError: import * only allowed at module level
My recollection was incorrect about exec. You can still exec inside a
function, but it may have no effect:
py> def f():
... x = 1
... exec("x = 2")
... return x
...
py> f()
1
You can specify locals, but it doesn't help:
py> def f():
... x = 1
... exec("x = 2", globals(), locals())
... return x
...
py> f()
1
However, in Python 2, Python tried hard to make exec work:
py> def f():
... x = 1
... exec("x = 2")
... return x
...
py> f()
2
I don't recall all the details, but in Python 2 functions could use two
different schemes for local variables: the regular, optimized one using
memory slots, and a dict-based one that came into play with exec. So we
have this:
py> def g():
... a = 1
... exec("b = 2")
... return (a, b)
...
py> dis.dis(g)
2 0 LOAD_CONST 1 (1)
3 STORE_FAST 0 (a)
3 6 LOAD_CONST 2 ('b = 2')
9 LOAD_CONST 0 (None)
12 DUP_TOP
13 EXEC_STMT
4 14 LOAD_FAST0 (a)
17 LOAD_NAME0 (b)
20 BUILD_TUPLE 2
23 RETURN_VALUE
`a` is a regular, optimized local looked up with LOAD_FAST; but `b` gets the
same old LOAD_NAME used for globals and built-ins.
In Python 3.3, that same function uses LOAD_GLOBAL for `b`, even though the
variable does actually exist:
py> dis.dis(g)
2 0 LOAD_CONST 1 (1)
3 STORE_FAST 0 (a)
3 6 LOAD_GLOBAL 0 (exec)
9 LOAD_CONST 2 ('b = 2')
12 CALL_FUNCTION1 (1 positional, 0 keyword pair)
15 POP_TOP
4 16 LOAD_FAST0 (a)
19 LOAD_GLOBAL 1 (b)
22 BUILD_TUPLE 2
25 RETURN_VALUE
py> g()
Traceback (most recent call last):
File "", line 1, in
File "", line 4, in g
NameError: global name 'b' is not defined
The conclusion I draw from all this is that the rules governing local
variables in Python are a mess :-)
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08.09.2015 16:31, Ian Kelly wrote: > On Tue, Sep 8, 2015 at 5:55 AM, Vladimir Ignatov > wrote: >>> I had some experience programming in Lua and I'd say - that >>> language is bad example to follow. Indexes start with 1 (I am >>> not kidding) >> >> What is so bad about that? > > It's different from the rest 99.9% of languages for no particular > reason. It's not "different from the rest 99.9% of languages". > There are many languages that use 1-based indexing, e.g. Matlab, > Pascal, Fortran. To be fair, that is not entirely true. In Pascal, there are three cases (you can argue that this doesn’t improve anything): (a) statically allocated arrays where the programmer chooses the bounds, e.g. const InBitData: array [1..4] of Integer = (128, 32, 16, 64); (b) strings, which start at 1, as historically, the length of the string was stored at position 0; pascal uses length-delimiting instead of NUL-delimiting. (c) dynamically allocated arrays which always start at 0. So let aside the historical cruft from Strings, Pascal uses zero-based indexing unless told otherwise. regards, jwi -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJV8+eJAAoJEMBiAyWXYliKe4gP/ipqzEWQvp3jDwINm8Ofdlpc 4ngOlwUQxAo25DNPG1qnT06iRj+CN5wpJDr5CgYW0Hb6nkoLzlJG6XDqK7S3BAQy msTvDlZFwnWEJ7AQcLP1RCYNy1Z0O9j+/XAEWD7wDk02wlZnEtrIWXGvxpR98fjx HOKLxHHEQsi4+qhgpQJzqXHEi5UozN52f6AC1B7JGAwueCx8+gjAeIGHwcYQXFRZ L78pBRZQpwoLBumylShUOO8HvouHSyRwfMF+we907oDAgWREnmwu82Q2jOHqAPXt UDMlyi2hueQXNvJFTqCfdkOAEcDk/Jn2Agx7w5A5k2oHptK8uwS+2/SghmPwPZuh G+Gqi5+FxSEkQDJBvsU9dUwCy/OIBm2kxGlaVB+MRN8LxvLVYsx5DdZbIlce9VVn SrehJPo6TnFBsgpRsjr9Ahpnmh769ej/jcyfKDgYb6tXW0XANlPUQ/nGxtNES4hJ l7ds3VE/n91WU/cQlTKB9EviteMDit0iqYRlPOwV1QPNWx0z2a+/nMGyRH/Baaqj r1rdmzWkks+vMmkYd8Yl+IlHmnWUBM/gI4qh9I1mA+iyH/n/Se9SdSISLqmccdoB 0ph1UmM3Tz/vGvguVdaF8WJzpL2sdtaR4ibjeN5IhYyhzREOFnJkKvofxfYNm3TF kCSAK5/Q6qPg4s9X2nCt =KixQ -END PGP SIGNATURE- -- https://mail.python.org/mailman/listinfo/python-list
Wholesale Sports Shoes Clear Air Force One AAA++quality(www.cnnshoe.com)
What is the new adrss -- https://mail.python.org/mailman/listinfo/python-list
Re: monospaced font in MS Windows with wxpython
In a message of Fri, 11 Sep 2015 22:16:36 -, Javier writes: >I am trying to use a monospaced font (preferably small) in MS Windows >with wxpython. I have tried > >txtctrl.SetFont(wx.Font(10, wx.MODERN, wx.NORMAL, wx.NORMAL, False, >u'Consolas')) > >but no success, I still get a proportional font. > >-- >https://mail.python.org/mailman/listinfo/python-list wxpython has its own mailing lists where the response might be better: http://www.wxpython.org/maillist.php Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote: > Random832 writes: > > > Ben Finney writes: > > > The reference value is inaccessible to the program, it can only be > > > used to get at the referenced object. > > > > What does it mean to access something, if not to do some operation on > > it? Getting the referenced object is the operation you can do with it. > > You've clearly committed to some ontology that just doesn't match the > Python data model. How about lay-English ontology in which "point to" and "refer to" are fairly synonymous? -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes: >How about lay-English ontology in which "point to" and "refer to" are fairly >synonymous? This I have found is important in teaching, which is why I favour 'bind' and 'binding' -- rather than pointer, pointer, refer to, referring. However, the problem that even people who have never used C, and probably have never read about it, either (children) really want a word that means 'when I use this name I get this physical chunk of memory, over there' cannot be completely defeated with this simple language change. I know kids who think that python variable names bind to actual physical chunks of their memory sticks, because they haven't got around to understanding what RAM is, yet. On the other hand, being able to say 'Right. You are a garbage collector. Because only garbage collectors need to care about such things.' makes for a pretty memorable lesson. Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton wrote: > In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes: > >How about lay-English ontology in which "point to" and "refer to" are fairly > >synonymous? > > This I have found is important in teaching, which is why I favour 'bind' > and 'binding' -- rather than pointer, pointer, refer to, referring. Well we can play humpty dumpty and make any word mean whatever we like. However if you are a teacher you will recognize a need for pictures. And (as far as I can tell) "Random832" finds a need for the box-n-arrow diagrams of classic data-structure books -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 12-09-2015 05:38, Mark Lawrence wrote: > > Nothing to do with this being untested software then? Actually it was > so I'd put that down to a programmer error. "The code always worked > before so it's bound to work this time". Such a pity that this > particular launch wasn't the same as anything done previously. I am not even sure what you are saying. Can't be that C++ bugs are not not caused by programmer errors. Because C++ is actually used in numerous mission critical systems. But anyways. If you are that scared of C++ it is indeed best you don't fly. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Picking a post to respond to, more or less at random... On Saturday, September 12, 2015 at 9:14:00 AM UTC-6, Rustom Mody wrote: > On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton wrote: > > In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes: > > >How about lay-English ontology in which "point to" and "refer to" are > > >fairly > > >synonymous? > > > > This I have found is important in teaching, which is why I favour 'bind' > > and 'binding' -- rather than pointer, pointer, refer to, referring. > > Well we can play humpty dumpty and make any word mean whatever we like. > However if you are a teacher you will recognize a need for pictures. > And (as far as I can tell) "Random832" finds a need for the box-n-arrow > diagrams of classic data-structure books *The* python data model is a concept that, like all concepts, exist in human brains. It (and its related terminology) are descriptions agreed upon by a majority of Python developers, documentors and others. Its purpose is to explain in a simpler way the behavior of a running Python program. [*] It is only one of many possible descriptions. Its value is measured in how well and efficiently it allows Python programmers to predict the behavior of a Python program. I never found its presentation in the Python documentation very understandable or helpful. Having programmed in C in the past, the model of Python I eventually developed is very much (I think, haven't read the whole thread) like Random832's. I think of boxes (objects) with slots containing "pointers" that "point" to other boxes. Even today when dealing with complex Python data structures, I draw boxes and arrows to help me understand them and think of the arrows as "pointers". Frankly, I feel a little insulted by people who presume that having learned what a pointer is in C, that my brain is so rigid that I must necessarily think that pointer means exactly what pointer means in C forever after. FYI (the general you), I am capable of extracting the general principle and applying it to Python. Not just capable, but using the concept from C made understanding Python faster than pretending that somehow Python has some magical and unique way of structuring data that's brand new. Maybe pedagogical research will show that one particular model is more easily understood by python learners that some other model. But please keep in mind that learners come in many varieties and that one size will not fit all. Knowing what a pointer is in C and applying the concept to model python worked well for me and I would have no hesitation offering it as an explanation to others as an option to help someone else's understanding if they, like me, find the official model less then helpful. [*] There is also possibly a "data model" used in specifying the Python language for implementors but this thread seems to be about how to describe Python's behavior to users. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: “reference” versus “pointer”
On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: > Anyway, maybe we do need a term to distinguish Python/C#/Java pointers > from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since > the key thing about it is you can't do pointer arithmetic on them to get > the object "next to" the one it points at. How about *just don't call them pointers*? You know, since they aren't pointers in the computer science sense. The Free On-line Dictionary of Computing defines "pointer": 1. An address, from the point of view of a programming language. A pointer may be typed, with its type indicating the type of data to which it points. Arithmetic is irrelevant to the definition of "pointer". That's a foible of C, not fundamental to the concept of pointer. Pascal, for example, has pointers too, implemented pretty much in the same way as C/C++, but the type system doesn't allow you to perform arithmetic on them because they aren't treated as integers. Computer science and IT is *dominated* by a single usage for "pointer" -- it's an abstract memory address. The fundamental characteristics of pointers are: - they are first-class values; you can assign a pointer to a variable; - you can dereference a pointer: get the value pointed to; - (in some languages) you can get a pointer to a specific variable (possibly an unnamed, dynamic variable allocated in the heap rather than a named, statically allocated variable). The last two imply that the language must be one where values have fixed addresses, not just as a matter of implementation, but as a matter of language semantics. If they are free to move, they cannot have a fixed address. Python, Java, Ruby, Lua, Javascript etc. have *no such concept* as pointer. There are no values in these languages which correspond to the standard definition of pointer: - you cannot get a pointer to an object or a variable (a name); - since there are no pointers, you cannot dereference them; - or assign them to a variable. Since pointers can be considered an indirect reference to a value, what sort of indirect references does Python have? The simplest thing in Python that is somewhat analogous to a pointer is a *name*, since names allow you to indirectly refer to some value: x = 23 print(x) # prints the value referred to by x, not "x" itself. ptr = "x" # equivalent to "the address of x" y = globals()[ptr] # equivalent to dereferencing Note that names are not first-class values in Python: there is no Name type, and you cannot bind a name to a variable, you have to use a string. It's not a very close analogy, but it's the closest Python has. Implementations of Python, Javascript, Lua, Java, Ruby etc. *may or may not* use pointers in the implementation, but they are not part of the language interface. These languages have no "addressof" operator, no dereference operator, and no "pointer" type; values do not necessarily have fixed addresses (indeed, in Jython and IronPython, values can move in memory). Insisting that Python has pointers is like insisting that you use a text editor by flipping bits. "What happens if I press Ctrl-X?" "Well, these bits on the screen flip from black to white, these bits flip from white to black, and these stay the same." -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: “reference” versus “pointer”
On Sat, 12 Sep 2015 03:03 pm, Random832 wrote: > Yes I am. You're just making the implicit assumption that a "value" has > to be a number, and I was ignoring that assumption. The value is the > address of an object. The unknown, unknowable, and in fact possibly non-existent address of an object. There is nothing about the Python language which demands that objects have addresses. We could build a Python interpreter using a giant clockwork mechanical computing machine, like the Difference Engine only much more complex, and it would not have addressable objects. If you would prefer a more practical counter-example, we can simulate a Python interpreter in our head (at least for short programs). Again, there is no addressable memory in the human brain, and hence the objects have no address. But for the sake of the argument, let's suppose you are right, and that Python values are "the address of the object". Given: x = "blue cats eat green mice" I would say that the value of x is the string "blue cats eat green mice". You, apparently, believe that the value of x is 0xb7aea480. Or possibly 0xb43384aa. Or whatever address the interpreter happens to give you on this specific run of your program. This abuse of the word "value" is sheer balderdash. To quote Fredrik Lundh: well, I guess you can, in theory, value an artificial number assigned to an object as much as the object itself. "Joe, I think our son might be lost in the woods" "Don't worry, I have his social security number" http://effbot.org/zone/call-by-object.htm. Python values are not addresses. Python values are objects. Addresses, even when they exist, are not accessible in the Python language. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Saturday, September 12, 2015 at 10:02:40 PM UTC+5:30, Steven D'Aprano wrote: > On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: > > > Anyway, maybe we do need a term to distinguish Python/C#/Java pointers > > from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since > > the key thing about it is you can't do pointer arithmetic on them to get > > the object "next to" the one it points at. > > How about *just don't call them pointers*? You know, since they aren't > pointers in the computer science sense. > > The Free On-line Dictionary of Computing defines "pointer": > >1. An address, from the point of view of a >programming language. A pointer may be typed, with its type >indicating the type of data to which it points. > Insisting that Python has pointers is like insisting that you use a text > editor by flipping bits. "What happens if I press Ctrl-X?" "Well, these > bits on the screen flip from black to white, these bits flip from white to > black, and these stay the same." > This is from the docs https://docs.python.org/3/library/functions.html#id id(object) Return the "identity" of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. Two objects with non-overlapping lifetimes may have the same id() value. CPython implementation detail: This is the address of the object in memory. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Saturday, September 12, 2015 at 10:21:08 PM UTC+5:30, Steven D'Aprano wrote: > Python values are not addresses. Python values are objects. Which means for example...??? Atoms? Stars? People? Countries? > Addresses, even when they exist, are not accessible in the Python language. And you claim that these addresses are less accessible to python than the objects above? -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Sun, Sep 13, 2015 at 2:54 AM, Rustom Mody wrote: >> Insisting that Python has pointers is like insisting that you use a text >> editor by flipping bits. "What happens if I press Ctrl-X?" "Well, these >> bits on the screen flip from black to white, these bits flip from white to >> black, and these stay the same." >> > > This is from the docs > https://docs.python.org/3/library/functions.html#id > > id(object) > > Return the "identity" of an object. This is an integer which is > guaranteed to be unique and constant for this object during its lifetime. Two > objects with non-overlapping lifetimes may have the same id() value. > > CPython implementation detail: This is the address of the object in > memory. *Python* does not have addresses. *CPython* is an implementation of the Python language which uses memory. Jython uses Java objects, and thus doesn't have memory addresses. PyPy doesn't keep things at fixed locations in memory, and maintains a separate concept of object identities, even though it is implemented using some form of system memory. Python does not have pointers or addresses. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 2015-09-12 06:22, Skybuck Flying wrote: "Michael Torrie" wrote in message news:mailman.384.1442016089.8327.python-l...@python.org... On 09/11/2015 03:50 PM, Skybuck Flying wrote: Something which python does not seem to do currently ?! So that's weird. I will leave it at that for now. " Seems to me you have a completely mistaken understanding of how variables work in Python. This is one of the reasons why I have said in the past, erroneously, that Python does not have variables. It does of course but not in the same way as C or Pascal. In those languages names are source-code abstractions only, and irrelevant to the compiler and machine code. C and Pascal define variables as boxes that can be written to. Not so in Python. " Well you basically said it yourself: " irrelevant to the compiler and machine code". That's kinda nice about a high level language. Programmer does not need to understand anything below the language. A python programmer shouldn't need to understand a damn thing to write: A = 10 A = A + 1 print A However for sake of your discussion I will continue your arguments below, since I get the impression you guys are clueless how to change python implementation ;) " In Python most common objects are immutable. Meaning they can never change or be overwritten. They are bound to names. This binding is what makes names look like and act like traditional variables. The secret to understanding the global keyword is to understand how Python namespaces work. The statement "a=5" does not assign a 5 to the box called "a." Rather it binds the name "a" to the "5" object, which is immutable and called into existence by the interpreter implementation. Subsequently "a=6" disconnects a from the 5 object, casting the 5 object loose to be reclaimed in some fashion that doesn't matter at this point. "a" is then rebound to a new object, 6. " What happens for following code: A=123456789011 Are you going to claim it's going to bind to all these numbers and then also multiple times ? "all these numbers"? I see only one number there. At runtime, it'll bind the name to the number, putting the pair into a dict. (Actually, in a function, it can determine the names of all of the local variables, so it uses 'slots' instead, as an optimisation.) Sounds a bit shady ?! ;) Perhaps python considers it a string ? Python applies math to strings ? Sounds a bit slow... therefore perhaps you're wrong... Why would _he_ be wrong? _He_ never claimed any such thing! " When doing a look-up on a name, the interpreter first checks the local scope's dictionary and if it does not find the name there there, goes to the outer scope and so forth until you get to the module global namespace. So we don't need any special keywords to do Pascal-style constants. We just define them in the module and they work. Usually we name them in all caps so we have a bit of a convention as to where they come from. And yes we're talking about looking up strings in a dictionary here. " So big deal, solution is easy to see, invert interpreter logic: Everything declared is "not constant". Everything declared as "constant" suddenly becomes constant. And thus everything declared as not constant behaves the same way as "global", problem solved. " When binding a name to an object, the interpreter always binds a name in the local namespace, unless the global keyword has been used previously and then it goes right to the global namespace. As has been said numerous times on this thread, how else would the interpreter do this? There simply isn't any other way that makes sense. Certainly you haven't made the case for it, seeing as you have some fundamental misunderstandings about variables in Python. " You didn't completely explain how the global namespace becomes writeable ? or re-bindeable ? (It seems not necessary to explain it you implement the constant idea, as explained above already). Do I have to assume that global namespace is "re-bindeable" = writeable ? " You keep saying things like "writing to a variable" or "declared variables" which just don't apply to Python because that's not how Python variables work. It may appear this way on the surface, but the differences are subtle yet important. Namespaces are written to, not variables, some objects can be mutated. Names are bound to objects, but variables are not declared, as a name can be bound to an object of any type. " Well again you didn't explain how using namespaces suddenly lead to "rewritable" and/or "rebinding" Namespaces don't "become writeable". The purpose of "global" is to tell the compiler that this name should be bound in the global namespace, not the local namespace. if A is declared as global as follows: global A and then code is written as follows: A = 10 A = 20 def Test() global A = 30 return How does this make A "rewriteable" ? Or "rebindable" to 30 ? " Namespaces are powerful constructs that give Python muc
Re: Python handles globals badly.
On 2015-09-12 17:29, Dennis Lee Bieber wrote: On Sat, 12 Sep 2015 05:11:46 +0100, Mario Figueiredo declaimed the following: On 12-09-2015 03:35, Mark Lawrence wrote: Ada took over from CORAL in the UK, at least in military projects. It was also used in the aircraft industry. My old work mates tell me that its completely died a death, to be replaced by C++. Someone please remind me never to fly again. Alright. But then someone should probably have reminded you that a long time ago. Maybe you missed it when an Ada integer overflow bug produced one of the most expensive software bugs in history by crashing the Ariane 501 rocket and its 4 cluster sattelites payload. As I recall, the software did exactly what it was supposed to do in that situation... But no one had tested the algorithm with the rate of change the Ariane 5 could produce -- so an algorithm that was developed for, and safe with, the smaller Ariane suddenly went "something's wrong -- abandon ship" Nothing inherent in the language... What would C++ have done in the same situation? Would Ariane still have failed? Probably... -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Sat, 12 Sep 2015 10:46 pm, Rustom Mody wrote: > On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote: >> You've clearly committed to some ontology that just doesn't match the >> Python data model. > > How about lay-English ontology in which "point to" and "refer to" are > fairly synonymous? "Pointer" in English is also a synonym for - a type of dog; - an instrument which pierces (as used by engravers, lace workers, etc); - an item of private information; - a hint or tip; - a caution or warning; - a recommendation; - the index finger; - a cricketer fielding at a specific position; - the hour/minute/second hand on a timepiece; - a compass needle; - two specific stars in the constellation of the Great Bear (Ursa Major); - diagonal braces fastened across the hold of a ship; - the small icon whose movement across the screen follows that of the mouse, trackball or other pointing device; - a signpost or milepost; and more. I don't think that arguing on the basis of lay-English or plain English terms is going to be terribly useful. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On 9/12/2015 9:54 AM, Rustom Mody wrote: On Saturday, September 12, 2015 at 10:02:40 PM UTC+5:30, Steven D'Aprano wrote: On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: Anyway, maybe we do need a term to distinguish Python/C#/Java pointers from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since the key thing about it is you can't do pointer arithmetic on them to get the object "next to" the one it points at. How about *just don't call them pointers*? You know, since they aren't pointers in the computer science sense. The Free On-line Dictionary of Computing defines "pointer": 1. An address, from the point of view of a programming language. A pointer may be typed, with its type indicating the type of data to which it points. Insisting that Python has pointers is like insisting that you use a text editor by flipping bits. "What happens if I press Ctrl-X?" "Well, these bits on the screen flip from black to white, these bits flip from white to black, and these stay the same." This is from the docs https://docs.python.org/3/library/functions.html#id id(object) Return the "identity" of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. Two objects with non-overlapping lifetimes may have the same id() value. CPython implementation detail: This is the address of the object in memory. Quoting from above: >> The Free On-line Dictionary of Computing defines "pointer": >> >> 1. An address, from the point of view of a >> programming language. So, how does the CPython program access the contents given its 'address in memory'? From the definition it would seem it's not a pointer, as from the perspective of the programming language, you can't get there from the id. Look-ma,-no-pointers-ly y'rs, Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Saturday, September 12, 2015 at 9:47:33 PM UTC+5:30, rurpy wrote: > Frankly, I feel a little insulted by people who presume that having > learned what a pointer is in C, that my brain is so rigid that I must > necessarily think that pointer means exactly what pointer means in C > forever after. Its more amusing than insulting Just open CPython sources and there's a pointer on every other line Best I can see, the people frothing at the mouth that python has no pointers are basically saying that "non-first-class" == "non-existent" By that same logic C has neither types nor functions Speaking as a teacher, sometimes one needs to be clean and dishonest Sometimes one needs to be honest and mop up after leaky abstractions -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 9/11/2015 10:22 PM, Skybuck Flying wrote: I didn't learn anything from this posting, sorry ! ;) I'm seeing a pattern here... Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Sun, 13 Sep 2015 02:54 am, Rustom Mody wrote: > This is from the docs > https://docs.python.org/3/library/functions.html#id Yes, what of it? What point do you think you are making? > id(object) > > Return the "identity" of an object. This is an integer which is > guaranteed to be unique and constant for this object during its > lifetime. Two objects with non-overlapping lifetimes may have the same > id() value. > > CPython implementation detail: This is the address of the object in > memory. What part of "CPython implementation detail" was too difficult for you to understand? id() is not an addressof function. It returns, and I quote: "an integer which is guaranteed to be unique and constant for this object during its lifetime" which is *not the case for memory addresses*. Here are the IDs of a few objects in Python: steve@orac:~$ jython -c "print id(None); import sys; print id(sys)" 1 2 steve@orac:~$ ipy -c "print id(None); import sys; print id(sys)" 0 43 Are you going to argue that these are memory addresses? If not, what relevance do you think the id() function has here? Note: when I write my own Python implementation, all IDs will be negative odd numbers. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Saturday, September 12, 2015 at 10:38:46 PM UTC+5:30, Steven D'Aprano wrote: > On Sat, 12 Sep 2015 10:46 pm, Rustom Mody wrote: > > > On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote: > > >> You've clearly committed to some ontology that just doesn't match the > >> Python data model. > > > > How about lay-English ontology in which "point to" and "refer to" are > > fairly synonymous? > > "Pointer" in English is also a synonym for > > - a type of dog; > - an instrument which pierces (as used by engravers, lace workers, etc); > - an item of private information; > - a hint or tip; > - a caution or warning; > - a recommendation; > - the index finger; > - a cricketer fielding at a specific position; > - the hour/minute/second hand on a timepiece; > - a compass needle; > - two specific stars in the constellation of the Great Bear (Ursa Major); > - diagonal braces fastened across the hold of a ship; > - the small icon whose movement across the screen follows that of the > mouse, trackball or other pointing device; > - a signpost or milepost; > > and more. I don't think that arguing on the basis of lay-English or plain > English terms is going to be terribly useful. So if someone's ontology disagrees with yours its not very useful. You're welcome to that view of course Its called "Humpty-Dumpty" (in Alice ontology). We could have had a more 'useful' discussion if alongside the meanings of "pointer" you had provided meanings of "reference" as well -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Sun, Sep 13, 2015 at 3:24 AM, Steven D'Aprano wrote: > Note: when I write my own Python implementation, all IDs will be negative > odd numbers. When I build my own CPU architecture, all memory addresses will be negative odd numbers, so people think your Python uses addresses again. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Sun, 13 Sep 2015 02:17 am, ru...@yahoo.com wrote: > Having programmed in C in the past, Well, there's your problem. Like BASIC before it, anyone who has learned C is mentally crippled for life as a programmer *wink* > the model of Python I eventually > developed is very much (I think, haven't read the whole thread) like > Random832's. I think of boxes (objects) with slots containing "pointers" > that "point" to other boxes. Even today when dealing with complex > Python data structures, I draw boxes and arrows to help me understand > them and think of the arrows as "pointers". If you're going to abuse terminology, why don't you call the boxes "floats" since they "float around in memory", or some other story? After all, the JVM and .NET runtimes can and will move the boxes around as needed, which is sort of floating around. Then you can say that all Python objects are floats. Of course, what *you* mean by float is not what everyone else means by floats. But you've already made it clear that you're happy to use your own special meaning of "pointer" that disagrees with the computer science standard meaning, so what's the difference? > Frankly, I feel a little insulted by people who presume that having > learned what a pointer is in C, that my brain is so rigid that I must > necessarily think that pointer means exactly what pointer means in C > forever after. You C programmers, you always think it's about C *wink* C is not the only, or even the first, language to have standardised on a meaning for pointer in computer science. Pascal had pointers long before C, and I'm sure Pascal wasn't the first either. "Pointer" is a standard primitive data type across dozens of languages: it's an abstract data type holding the memory address of a variable (either a named, statically allocated variable, or more often, an anonymous, dynamically allocated variable). As such, it requires that variables have a fixed address. If the variable can move, the pointer will no longer point to the variable. If you want to use "pointer" to refer to something else, the onus is on you to make it clear that you're using it in a non-standard way. Some day, most programmers will be using nothing by dynamic languages which lack pointers-the-data-type, and the term will lose its baggage and can be safely used as a generic English term for "a thing which points". The tiny minority of systems programmers writing device drivers and kernel code in Rust (C having been long-since delegated to the wastebin of history -- well that's my fantasy and I'm sticking to it) will learn that, outside of their own niche, "pointer" does not have the technical meaning that they are used to, and everyone else will be as blissfully unaware of said technical meaning as the average programmer today is of continuations and futures. But this is not that day. > FYI (the general you), I am capable of extracting the > general principle and applying it to Python. Not just capable, but > using the concept from C made understanding Python faster than pretending > that somehow Python has some magical and unique way of structuring data > that's brand new. It's not magical or unique. It is shared by many other languages, such as Ruby, Lua, Java, Javascript. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Rustom Mody writes: > On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton wrote: >> In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes: >> >How about lay-English ontology in which "point to" and "refer to" are fairly >> >synonymous? >> >> This I have found is important in teaching, which is why I favour 'bind' >> and 'binding' -- rather than pointer, pointer, refer to, referring. > > Well we can play humpty dumpty and make any word mean whatever we like. > However if you are a teacher you will recognize a need for pictures. > And (as far as I can tell) "Random832" finds a need for the box-n-arrow > diagrams of classic data-structure books Speaking of pictures and names in Python http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#other-languages-have-variables -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Sun, 13 Sep 2015 03:12 am, Rustom Mody wrote: > Best I can see, the people frothing at the mouth that python has no > pointers are basically saying that "non-first-class" == "non-existent" Not at all. In Python, at least, all values are first-class, but that's not the case with all languages which lack pointers. Java has classes but they aren't first-class values. They aren't values at all, but they do exist as entities in Java code. You don't have to drop out of Java into some underlying implementation language in order to write Java classes. I trust that you agree that Fortran lacks pointers -- or at least, old versions of Fortran, like FORTRAN 5 and (by memory) Fortran 77 lack them. (Modern Fortran almost certain has pointers.) Old versions of Fortran lacks dynamic memory management, it has no pointers, no equivalent of Pascal's "new" and "dispose". It also has a variable model like C's (named variables with fixed memory locations). Suppose I write a Fortran 77 compiler in C. I daresay I would use C's ability to dynamically allocate and free memory (i.e. pointers) in my implementation of Fortran 77. But because this is a faithful implementation of the Fortran 77 standard, warts and all, the Fortran compiler itself won't have the ability to create, dereference or free pointers. Would you insist that Fortran 77 has pointers just because my implementation uses pointers under the hood? > By that same logic C has neither types nor functions No. C has both types and functions. You can define your own types, and you can define your own functions. They might not be first-class values, but they are entities you manipulate in your C code. You don't have to drop out of the C language into (say) machine code to write a function. In Python, the language *lacks pointers altogether*. It's not just that you can't treat them as first-class values, or that they aren't values, but that they aren't even entities in the Python programming model. In order to interact with pointers, you have to drop out of Python altogether, and start programming in the implementation language C, or use an interface to C such as ctypes. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Are there any "correct" implementations of tzinfo?
I was trying to find out how arithmetic on aware datetimes is "supposed to" work, and tested with pytz. When I posted asking why it behaves this way I was told that pytz doesn't behave correctly according to the way the API was designed. The tzlocal module, on the other hand, appears to simply defer to pytz on Unix systems. My question is, _are_ there any correct reference implementations that demonstrate the proper behavior in the presence of a timezone that has daylight saving time transitions? -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Saturday, September 12, 2015 at 11:26:18 PM UTC+5:30, Akira Li wrote: > Rustom Mody writes: > > > On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton > > wrote: > >> In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes: > >> >How about lay-English ontology in which "point to" and "refer to" are > >> >fairly > >> >synonymous? > >> > >> This I have found is important in teaching, which is why I favour 'bind' > >> and 'binding' -- rather than pointer, pointer, refer to, referring. > > > > Well we can play humpty dumpty and make any word mean whatever we like. > > However if you are a teacher you will recognize a need for pictures. > > And (as far as I can tell) "Random832" finds a need for the box-n-arrow > > diagrams of classic data-structure books > > Speaking of pictures and names in Python > http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#other-languages-have-variables Yeah cute [I think I will even use these in my classes] However they dont address the issue that I think random832 is referring to. viz. I have two variables (or names!) say a and b which look the same >>> a [[1,2],[1,2]] >>> b [[1,2],[1,2]] And yet doing >>> a[0][0] = "Oops!" gives a data structure one "Oops!" whereas doing it to b mysteriously gives 2 Best I can see you can only explain this seemingly-similar-but-structurally-different with box-n-arrow diagrams. Or some moral equivalent. And some people see no advantage to playing semantics and proclaiming "The arrows in C look similar to the arrows in python but they are not the same" -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On 09/12/2015 10:32 AM, Steven D'Aprano wrote: > On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: >[...] > Computer science and IT is *dominated* by a single usage for "pointer" -- > it's an abstract memory address. The fundamental characteristics of > pointers are: Just upthread, you claimed something was "universally agreed" that was not so at all; so please forgive me for not taking your *dominated*/single assertion on simply your claim that it is so. > - they are first-class values; you can assign a pointer to a variable; Not true for Python "pointers" > - you can dereference a pointer: get the value pointed to; True for Python "pointers" > - (in some languages) you can get a pointer to a specific variable (possibly > an unnamed, dynamic variable allocated in the heap rather than a named, > statically allocated variable). True for Python "pointers". > The last two imply that the language must be one where values have fixed > addresses, not just as a matter of implementation, but as a matter of > language semantics. If they are free to move, they cannot have a fixed > address. The *address* must be fixed, that is, when you dereference the address you must always get the same thing back. But that implies nothing about how or where the thing is stored, or whether it can move or not. Indeed C and other languages with what even you call pointers get the same thing back even though the thing actually *has* moved in physical memory, because the address is denoted as a virtual memory address. I take the generalized meaning of "address" to be simply a token that allows you to get back the same thing each time you use it. > Python, Java, Ruby, Lua, Javascript etc. have *no such concept* as pointer. > There are no values in these languages which correspond to the standard > definition of pointer: They have not such concept because the developers and documentors choose not to describe that language that way. That does not mean one could not come up with a perfectly valid description that did include the concept of pointers. > - you cannot get a pointer to an object or a variable (a name); > > - since there are no pointers, you cannot dereference them; > > - or assign them to a variable. > > > Since pointers can be considered an indirect reference to a value, what sort > of indirect references does Python have? The simplest thing in Python that > is somewhat analogous to a pointer is a *name*, since names allow you to > indirectly refer to some value: > > x = 23 > print(x) # prints the value referred to by x, not "x" itself. > ptr = "x" # equivalent to "the address of x" > y = globals()[ptr] # equivalent to dereferencing Here is another kind of indirect reference a[0] = 23 The "pointer" in the first item of the list "a" does not have a name. But we can still dereference it. The dereferencing happens automatically when "a[0]" is executed. > Note that names are not first-class values in Python: there is no Name type, > and you cannot bind a name to a variable, you have to use a string. > > It's not a very close analogy, but it's the closest Python has. I think it is a close analogy. Things refer to other things and can be used to access those other things act like pointers. You are correct that they are not first class items: one cannot do with them everything one can do with other items, all one can actually do with them is create them and dereference them. That of course is a good thing. But that they are not first class objects does not mean that one can't or shouldn't use the term "pointer" to describe them. That is, I don't see first- classness as being a requirement for pointerness. The defining characteristic of a pointer is that it, well, points to something. It may not be appropriate way to describe Python for everybody but it is perfectly reasonable (and even preferable) for people with an understanding of "pointers" from some other language. And for those people who don't then one could argue they are a clean slate and using the word "pointer" won't hurt. (JFTR, I am not against describing python in terms of "reference", "binding" etc, I just object to the vehement frothing at the mouth and insistence of one Single Truth that occurs here whenever anyone attempts to present some alternative. As I said in another post one size does not fit all.) -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
> I was trying to find out how arithmetic on aware datetimes is "supposed
> to" work, and tested with pytz. When I posted asking why it behaves this
> way I was told that pytz doesn't behave correctly according to the way
> the API was designed.
You were told (by me) that its implementation of tzinfos was not the
_intended_ way. Which is another way of saying it was an
unanticipated way. "Correctly" is a whole different kind of judgment.
pytz users who faithfully follow the docs seem happy with it.
> The tzlocal module, on the other hand, appears to
> simply defer to pytz on Unix systems.
>
> My question is, _are_ there any correct reference implementations that
> demonstrate the proper behavior in the presence of a timezone that has
> daylight saving time transitions?
Which specific "proper behaviors"? :"Hybrid" tzinfos following the
recommendations in the Python docs, including the sample
implementations in the docs, correctly mimic local clock behavior
(skipping the clock ahead when DST starts, and moving the clock back
when DST ends) when converting from UTC. It's impossible now to do
local -> UTC conversions correctly in all cases, because it's
impossible now to know which UTC time was intended for a local time in
a fold. For the same reason, it's impossible now to know whether a
local time in a fold is intended to be viewed as being in daylight
time or standard time.
But do note limitations of the default .fromutc() implementation: it
only guarantees correct mimic-the-local-clock behavior when
total-offset transitions are solely due to a notion of "daylight time"
that strictly alternates between .dst() returning zero and non-zero
values.
Transitions due to any other reason may or may not be reflected in
.fromutc()'s treatment of the local clock. Most importantly, a
transition due to a zone changing its base ("standard") UTC offset is
a possibility the default .fromutc() knows nothing about.
The wrapping of the IANA ("Olson") zoneinfo database in dateutil uses
hybrid tzinfos (the intended way of wrapping zones with multiple UTC
offsets), and inherits the default .fromutc(), so all the above
applies to it.
Including all behaviors stemming from the impossibility of
disambiguating local times in a fold. That's not a bug in dateutil.
It's a gap in datetime's design, It was an intentional gap at the
time, but that pytz went to such heroic lengths to fill it suggests
PEP 495 may well be overdue ;-)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Are there any "correct" implementations of tzinfo?
On 09/12/2015 12:23 PM, Random832 wrote: > I was trying to find out how arithmetic on aware datetimes is "supposed > to" work, and tested with pytz. When I posted asking why it behaves this > way I was told that pytz doesn't behave correctly according to the way > the API was designed. The tzlocal module, on the other hand, appears to > simply defer to pytz on Unix systems. > > My question is, _are_ there any correct reference implementations that > demonstrate the proper behavior in the presence of a timezone that has > daylight saving time transitions? Well, the problem is that because datetime doesn't include any way to disambiguate ambiguous times, it's not really possible to implement complex timezones in a way that is both correct (if your definition of correct includes "timezone conversions are lossless") and also matches the intended model of datetime. I believe that dateutil.tz has a tzinfo implementation (though I haven't used it myself) which is zoneinfo-based and matches the intended model of datetime (in that "Eastern" is always the same tzinfo object, and all operations within "Eastern" are always done on a local-clock-time basis). But in order to do this it has to sacrifice round-trippable conversions during a DST fold (because it has no way to disambiguate between the first and second 1:30am in local time during a DST fold). Pytz makes the other choice, making all operations consistent and loss-less by using only fixed-offset tzinfo instances. The cost of this choice is the need to "normalize" after arithmetic, because you may end up with e.g. an EDT datetime during a timeframe when DST is not in effect and it should be EST instead. PEP 495 is intended to solve the "no way to disambiguate ambiguous local times other than using fixed-offset tzinfos" problem, which would make it possible to implement tzinfo classes following the dateutil model while still having loss-less conversions. Carl signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Are there any "correct" implementations of tzinfo?
On Sat, Sep 12, 2015, at 14:36, Carl Meyer wrote: > Well, the problem is that because datetime doesn't include any way to > disambiguate ambiguous times, it's not really possible to implement > complex timezones in a way that is both correct (if your definition of > correct includes "timezone conversions are lossless") and also matches > the intended model of datetime. I'm not even talking about ambiguous times. I'm mostly talking about unambiguous times on opposite sides of the transition. It's not even clear to me how the model of datetime envisions _those_ working with "classic arithmetic". -- https://mail.python.org/mailman/listinfo/python-list
Random MAC generator error
import random # global mac1 def randomMAC(): mac = [ 0x00, 0x16, 0x3e, random.randint(0x00, 0x7f), random.randint(0x00, 0xff), random.randint(0x00, 0xff) ] return ':'.join(map(lambda x: "%02x" % x, mac)) # print randomMAC() for x in range(1,11): mac1 = randomMAC() print mac1 I got the following random mac generator script from the net (simple google search) i want to use random mac in one of mine script.What i need is mac1=randomMAC() should give mac value to mac1 that i use in a function and this runs in a loop. -- https://mail.python.org/mailman/listinfo/python-list
Re: Are there any "correct" implementations of tzinfo?
Random832 writes: > I was trying to find out how arithmetic on aware datetimes is "supposed > to" work, and tested with pytz. When I posted asking why it behaves this > way I was told that pytz doesn't behave correctly according to the way > the API was designed. The tzlocal module, on the other hand, appears to > simply defer to pytz on Unix systems. > > My question is, _are_ there any correct reference implementations that > demonstrate the proper behavior in the presence of a timezone that has > daylight saving time transitions? The only way to get correct[*] results now is to use *pytz*. PEP 495 might allow to fix some of non-avoidable (at the moment) bugs[1] in *dateutil* (another library that provides access to the tz database). Some core Python developers feel that pytz model does not implement the initial datetime design intent: both naive and timezone-aware datetime objects use the same model for arihtmetic (though the actual implementation contains a mix: aware datetime objects are treated as naive datetime objects in some cases but in others they behave as though they are utc-based). pytz model: aware datetime objects behave *as if* they are converted to UTC during arithmetic operations, comparisons, etc: # d = datetime.now(tz) (d2 - d1) == (d2.astimezone(utc) - d1.astimezone(utc)) tz.normalize(d + delta) == (d.astimezone(utc) + delta).astimezone(tz) tz.normalize() is necessary to get the correct local time (utc time is correct even without tz.normalize()) in presence of DST transitions (or other changes in UTC offset for any reason). Here's how the stdlib implementation behaves at the moment for a timezone-aware datetime object that represents local time (the only timezone with a non-fixed utc offset that is available in stdlib): # d = datetime.now(utc).astimezone() (d2 - d1) == (d2.astimezone(utc) - d1.astimezone(utc)) (d + delta).astimezone() == (d.astimezone(utc) + delta).astimezone() If utc offset is fixed then both naive and aware models are the same. [*] according to the tz database [1] https://github.com/dateutil/dateutil/issues/112 -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
[]
> My context is that I am working on an idea to include utc offsets in
> datetime objects (or on a similar object in a new module), as an
> alternative to something like a "fold" attribute. and since "classic
> arithmetic" is apparently so important,
Love it or hate it, it's flatly impossible to change anything about it
now, for backward compatibility.
> I'm trying to figure out how
> "classic arithmetic" _is actually supposed to work_ when adding a
> timedelta to a time lands it on the opposite side of a transition (or in
> the middle of a "spring forward" gap).
datetime arithmetic is defined in the Python docs.
> If there is a "fall back" transition tonight, then adding a day to a
> time of 12 noon today could end up as:
>
> 12 noon tomorrow, offset still DST.
> 12 noon tomorrow, offset in standard time, 25 hours from now in real
> time.
> 11 AM tomorrow, offset in standard time, 24 hours from now in real time
>
> Which one of these is "classic arithmetic"?
12 noon tomorrow in every case, regardless of tzinfo and regardless of
whether any kind of transition may or may not have occurred. Whether
it is or isn't in DST in this specific case isn't defined by Python -
that's entirely up to what the tzinfo implementation says. The
_intended_ way of implementing tzinfos would say it was in standard
time.
> Pytz (if you don't
> explicitly call a "normalize" function) results in something that looks
> like the first.
Yes, because pytz always uses a fixed-offset tzinfo. There is no
difference between timeline arithmetic and classic arithmetic in any
fixed-offset zone.
> In one of the models I've thought of, you can get the
> second by replacing the tzinfo again, or the third by doing astimezone,
> but the first preserves "exactly 24 hours in the future" in both the UTC
> moment and the naive interpretation by leaving the offset alone even if
> it is an "unnatural" offset.
>
> The second one above is what you get when you call normalize.
Yes. .normalize() effectively converts to UTC and back again In
fact, this is all it does:
def normalize(self, dt, is_dst=False):
if dt.tzinfo is self:
return dt
if dt.tzinfo is None:
raise ValueError('Naive time - no tzinfo set')
return dt.astimezone(self)
.fromutc() is called as the last step of .astimezone(), and .pytz
overrides the default .fromutc() to plug "the appropriate"
fixed-offset pytz tzinfo into the result.
> My question was whether there are any real implementations that work the
> intended way.
dateutil, plus all implementations anyone may have written for
themselves based on the Python doc examples. When datetime was
originally released, there were no concrete tzinfo implementations in
the world, so lots of people wrote their own for the zones they needed
by copy/paste/edit of the doc examples.
> If there are not, maybe the intended semantics should go
> by the wayside and be replaced by what pytz does.
Changing anything about default arithmetic behavior is not a
possibility. This has been beaten to death multiple times on this
mailing list already, and I'm not volunteering for another round of it
;-)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On 09/12/2015 11:48 AM, Steven D'Aprano wrote: > On Sun, 13 Sep 2015 02:17 am, ru...@yahoo.com wrote: > [...] >> the model of Python I eventually >> developed is very much (I think, haven't read the whole thread) like >> Random832's. I think of boxes (objects) with slots containing "pointers" >> that "point" to other boxes. Even today when dealing with complex >> Python data structures, I draw boxes and arrows to help me understand >> them and think of the arrows as "pointers". > > If you're going to abuse terminology, why don't you call the boxes "floats" > since they "float around in memory", > [...] I was not proposing that, I was talking about the use of the term "pointer". > C is not the only, or even the first, language to have standardised on a > meaning for pointer in computer science. Pascal had pointers long before C, > and I'm sure Pascal wasn't the first either. [I'm not sure about the "long before" part given they were nearly contemporaneous.] Right, and each of them uses the word (and others like "function", "call" "arguments", etc) in their own specific way, which they define as part of the description of the language. "function" in C is different than "function" in Pascal which is different than "function" in Python. That C (or Pascal) used the term first does not mean that it was "standardized" by that use to have that precise definition forever after. > "Pointer" is a standard primitive data type across dozens of languages: it's > an abstract data type holding the memory address of a variable (either a > named, statically allocated variable, or more often, an anonymous, > dynamically allocated variable). As such, it requires that variables have a > fixed address. If the variable can move, the pointer will no longer point > to the variable. See my comments on "fixed address" in another post. Your definition of "address" is too narrow. > If you want to use "pointer" to refer to something else, the onus is on you > to make it clear that you're using it in a non-standard way. Of course. Nobody should ever say (a least formally) just "pointer" and expect the entire (assumed diverse) audience to have a common single understanding of what is meant. But that applies to most terminology like "reference" as well. It is why language documentation has things like definitions and glossaries. > Some day, most programmers will be using nothing by dynamic languages which > lack pointers-the-data-type, I don't think there is any direct relationship between pointers and dynamic languages. Go is not a dynamic language yet it does not not allow unrestrained pointer use a'la C. My impression is that unmanaged pointers (in the C sense) are recognized these days as dangerous and that nearly all new languages including static ones manage "pointers" (perhaps under a different name) to prevent the problems that occur with C. > and the term will lose its baggage and can be > safely used as a generic English term for "a thing which points". The tiny > minority of systems programmers writing device drivers and kernel code in > Rust (C having been long-since delegated to the wastebin of history -- well > that's my fantasy and I'm sticking to it) That's fine, so we are talking about the far distant future, maybe year 3000 or so. :-) > will learn that, outside of their > own niche, "pointer" does not have the technical meaning that they are used > to, and everyone else will be as blissfully unaware of said technical > meaning as the average programmer today is of continuations and futures. > > But this is not that day. I think you underestimate the ability of human beings (even programmers) to interpret words in a context dependent way. The question is whether what "pointer" means in languages that use the word is *so* different than its meaning in the Python sense, that using it for Python is more misleading than helpful. You think so, perhaps because you focus on the unmanaged and memory-address aspects of its use. I consider those as non-determining characteristics of a thing that points to something and instead consider its pointingness to be its defining characteristic, in those languages and in Python, and thus find it perfectly descriptive for Python. -- https://mail.python.org/mailman/listinfo/python-list
string_formatter 1.0.1 released
string_formatter is a backport of the 3.4.1+ string.Formatter class, to
2.7, 3.3 and 3.4.0. This allows the use of empty keys {} in its format
strings.
At the same time it solves an existing (at least until 3.5.0.rc3) bug in
string.Formatter, breaking with the use of nested empty keys.
Python 3.4.3:
>>> import string
>>> string.Formatter().format("|{:<{}} {}|", 'a', 3, 5)
'|a 3|'
In addition (that is how it all started) it provides TrailingFormatter
which allows a type specification "t" with a single character parameter.
That character will be added to the (stringified) value before applying
(left-aligned) formatting:
import string_formatter as string
fmt = string.TrailingFormatter()
d = dict(a=1, bc=2, xyz=18)
for key in sorted(d):
print(fmt.format("{:t{}<{}} {:>3}", key, ':', 15, d[key]))
giving:
a:1
bc: 2
xyz: 18
--
https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
On Sat, Sep 12, 2015, at 14:53, Tim Peters wrote: > > I was trying to find out how arithmetic on aware datetimes is > > "supposed to" work, and tested with pytz. When I posted asking why > > it behaves this way I was told that pytz doesn't behave correctly > > according to the way the API was designed. > > You were told (by me) that its implementation of tzinfos was not the > _intended_ way. Which is another way of saying it was an > unanticipated way. "Correctly" is a whole different kind of judgment. > pytz users who faithfully follow the docs seem happy with it. My context is that I am working on an idea to include utc offsets in datetime objects (or on a similar object in a new module), as an alternative to something like a "fold" attribute. and since "classic arithmetic" is apparently so important, I'm trying to figure out how "classic arithmetic" _is actually supposed to work_ when adding a timedelta to a time lands it on the opposite side of a transition (or in the middle of a "spring forward" gap). If there is a "fall back" transition tonight, then adding a day to a time of 12 noon today could end up as: 12 noon tomorrow, offset still DST. 12 noon tomorrow, offset in standard time, 25 hours from now in real time. 11 AM tomorrow, offset in standard time, 24 hours from now in real time Which one of these is "classic arithmetic"? Pytz (if you don't explicitly call a "normalize" function) results in something that looks like the first. In one of the models I've thought of, you can get the second by replacing the tzinfo again, or the third by doing astimezone, but the first preserves "exactly 24 hours in the future" in both the UTC moment and the naive interpretation by leaving the offset alone even if it is an "unnatural" offset. The second one above is what you get when you call normalize. My question was whether there are any real implementations that work the intended way. If there are not, maybe the intended semantics should go by the wayside and be replaced by what pytz does. -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
Oops, pressed the wrong reply button and it didn't include the datetime list. On Sat, Sep 12, 2015, at 14:53, Tim Peters wrote: > > I was trying to find out how arithmetic on aware datetimes is > > "supposed to" work, and tested with pytz. When I posted asking why > > it behaves this way I was told that pytz doesn't behave correctly > > according to the way the API was designed. > > You were told (by me) that its implementation of tzinfos was not the > _intended_ way. Which is another way of saying it was an > unanticipated way. "Correctly" is a whole different kind of judgment. > pytz users who faithfully follow the docs seem happy with it. My context is that I am working on an idea to include utc offsets in datetime objects (or on a similar object in a new module), as an alternative to something like a "fold" attribute. and since "classic arithmetic" is apparently so important, I'm trying to figure out how "classic arithmetic" _is actually supposed to work_ when adding a timedelta to a time lands it on the opposite side of a transition (or in the middle of a "spring forward" gap). If there is a "fall back" transition tonight, then adding a day to a time of 12 noon today could end up as: 12 noon tomorrow, offset still DST. 12 noon tomorrow, offset in standard time, 25 hours from now in real time. 11 AM tomorrow, offset in standard time, 24 hours from now in real time Which one of these is "classic arithmetic"? Pytz (if you don't explicitly call a "normalize" function) results in something that looks like the first. In one of the models I've thought of, you can get the second by replacing the tzinfo again, or the third by doing astimezone, but the first preserves "exactly 24 hours in the future" in both the UTC moment and the naive interpretation by leaving the offset alone even if it is an "unnatural" offset. The second one above is what you get when you call normalize. My question was whether there are any real implementations that work the intended way. If there are not, maybe the intended semantics should go by the wayside and be replaced by what pytz does. -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
On Sat, Sep 12, 2015 at 3:41 PM, Tim Peters wrote: > > If there are not, maybe the intended semantics should go > > by the wayside and be replaced by what pytz does. > > Changing anything about default arithmetic behavior is not a > possibility. This has been beaten to death multiple times on this > mailing list already, and I'm not volunteering for another round of it > ;-) Tim and Guido only grudgingly accept it, but datetime already gives you "the pytz way" and PEP 495 makes a small improvement to it. The localize/normalize functionality is provided by the .astimezone() method which when called without arguments will attach an appropriate fixed offset timezone to a datetime object. You can then add timedeltas to the result and stay within a "fictitious" fixed offset timezone that extends indefinitely in both directions. To get back to the actual civil time - you call .astimezone() again. This gives you what we call here a "timeline" arithmetic and occasionally it is preferable to doing arithmetic in UTC. (Effectively you do arithmetic in local standard time instead of UTC.) Using a fixed offset timezone other than UTC for timeline arithmetic is preferable in timezones that are far enough from UTC that business hours straddle UTC midnight. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Rustom Mody writes: a > [[1,2],[1,2]] b > [[1,2],[1,2]] > And yet doing a[0][0] = "Oops!" > gives a data structure one "Oops!" > whereas doing it to b mysteriously gives 2 > > Best I can see you can only explain this > seemingly-similar-but-structurally-different > with box-n-arrow diagrams. > Or some moral equivalent. I think the best way is to say that a[0] and a[1] are the same object, while b[0] and b[1] are different objects. Possibly b[0] is also the same object as a[0] and a[1]. Then b[0][0] = "Oops!" was redundant. And the way to work out whether two objects are the same is to trace where they come from. Certain pieces of code result in new objects. Other pieces of code pass old objects around. Possibly store them in places, or change them in some way. Never make copies. Works for me. Some sort of pointer-talk is useful to discuss the implementation of all this (how can an object be in different places? how does an arbitrary object fit in a 64-bit register?) but for ordinary reasoning about a program, pointer-talk with those diagrams mostly gets in the way. -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
>>> If there are not, maybe the intended semantics should go >> > by the wayside and be replaced by what pytz does. >> Changing anything about default arithmetic behavior is not a >> possibility. This has been beaten to death multiple times on this >> mailing list already, and I'm not volunteering for another round of it >> ;-) [Alex] > Tim and Guido only grudgingly accept it, but datetime already gives you "the > pytz way" and PEP 495 makes a small improvement to it. To be clear, "Tim and Guido" have nothing at all against timeline arithmetic. Sometimes it's exactly what you need. But the _intended_ way to get it was always to convert to UTC first, or to just use plain old timestamps. Classic arithmetic was very intentionally the default. The only "grudgingly accepted" part is that .astimezone() grew a special case later, to make the absence of an argument "mean something": > The localize/normalize functionality is provided by the .astimezone() > method which when called without arguments will attach an appropriate > fixed offset timezone to a datetime object. You can then add timedeltas > to the result and stay within a "fictitious" fixed offset timezone that > extends > indefinitely in both directions. To get back to the actual civil time - you > call .astimezone() again. This gives you what we call here a "timeline" > arithmetic and occasionally it is preferable to doing arithmetic in UTC. > (Effectively you do arithmetic in local standard time instead of UTC.) > Using a fixed offset timezone other than UTC for timeline arithmetic is > preferable in timezones that are far enough from UTC that business hours > straddle UTC midnight. The distance from UTC can't make any difference to the end result, although if you're working in an interactive shell "it's nice" to see intermediate results near current wall-clock time. "A potential problem" with .astimezone()'s default is that it _does_ create a fixed-offset zone. It's not at all obvious that it should do so. First time I saw it, my initial _expectation_ was that it "obviously" created a hybrid tzinfo reflecting the system zone's actual daylight rules, as various "tzlocal" implementations outside of Python do. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Rustom Mody writes: > On Saturday, September 12, 2015 at 11:26:18 PM UTC+5:30, Akira Li wrote: >> Rustom Mody writes: >> >> > On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton >> > wrote: >> >> In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes: >> >> >How about lay-English ontology in which "point to" and "refer to" are >> >> >fairly >> >> >synonymous? >> >> >> >> This I have found is important in teaching, which is why I favour 'bind' >> >> and 'binding' -- rather than pointer, pointer, refer to, referring. >> > >> > Well we can play humpty dumpty and make any word mean whatever we like. >> > However if you are a teacher you will recognize a need for pictures. >> > And (as far as I can tell) "Random832" finds a need for the box-n-arrow >> > diagrams of classic data-structure books >> >> Speaking of pictures and names in Python >> http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#other-languages-have-variables > > Yeah cute > [I think I will even use these in my classes] > However they dont address the issue that I think random832 is > referring to. The pictures despite their simplicity reflect the actual model that Python language uses i.e., any deviations are an implementation artifact and may be ignored. > viz. I have two variables (or names!) say a and b which look the same a > [[1,2],[1,2]] b > [[1,2],[1,2]] > And yet doing a[0][0] = "Oops!" > gives a data structure one "Oops!" > whereas doing it to b mysteriously gives 2 Sorry, I haven't followed the whole thread. Could your provide a complete code example? Mention what you expect to happen and what happens instead in your case. -- https://mail.python.org/mailman/listinfo/python-list
Re: Random MAC generator error
On Sun, 13 Sep 2015 00:50:24 +0530, Robert Clove wrote: > import random # > > global mac1 > def randomMAC(): > mac = [ 0x00, 0x16, 0x3e, > random.randint(0x00, 0x7f), random.randint(0x00, 0xff), > random.randint(0x00, 0xff) ] > return ':'.join(map(lambda x: "%02x" % x, mac)) > # > print randomMAC() > > for x in range(1,11): > > mac1 = randomMAC() > > print mac1 > > I got the following random mac generator script from the net (simple > google search) > > i want to use random mac in one of mine script.What i need is > mac1=randomMAC() should give mac value to mac1 that i use in a function > and this runs in a loop. And you haven't told us what the "error" you're posting about is? When I ran the code I got the following result: 00:16:3e:21:da:a4 00:16:3e:57:be:d2 00:16:3e:6b:e5:ae 00:16:3e:54:0e:f0 00:16:3e:57:5e:50 00:16:3e:21:99:6b 00:16:3e:12:e6:05 00:16:3e:53:02:6d 00:16:3e:79:17:1b 00:16:3e:02:ff:b8 00:16:3e:4e:ff:0d Observation: No point in declaring mac1 as global in the global scope. Is it possible that you've tried to run python 2.x code on python 3.x and hit an error due to 'print x' -> 'print(x)'? -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Jussi Piitulainen writes: > I think the best way is to say that a[0] and a[1] are the same object, > while b[0] and b[1] are different objects. Sure, you can *say* that. But how do you draw it on a diagram with sticky notes or parcel tags or whatever? -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
On Sat, Sep 12, 2015 at 4:10 PM, Tim Peters wrote: > "A potential problem" with .astimezone()'s default is that it _does_ > create a fixed-offset zone. It's not at all obvious that it should do > so. First time I saw it, my initial _expectation_ was that it > "obviously" created a hybrid tzinfo reflecting the system zone's > actual daylight rules, as various "tzlocal" implementations outside of > Python do. > The clue should have been that .astimezone() is an instance method and you don't need to know time to create a hybrid tzinfo. If a Local tzinfo was available, it could just be passed to the .astimezone() method as an argument. You would not need .astimezone() to both create a tzinfo and convert the datetime instance to it. Still, I agree that this was a hack and a very similar hack to the one implemented by pytz. Hopefully once PEP 495 is implemented we will shortly see "as intended" tzinfos to become more popular. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Akira Li <4kir4...@gmail.com> writes: >Rustom Mody writes: >> viz. I have two variables (or names!) say a and b which look the same > a >> [[1,2],[1,2]] > b >> [[1,2],[1,2]] >> And yet doing > a[0][0] = "Oops!" >> gives a data structure one "Oops!" >> whereas doing it to b mysteriously gives 2 > > Sorry, I haven't followed the whole thread. Could your provide a > complete code example? Mention what you expect to happen and what > happens instead in your case. a0 = a1 = [1, 2] b0 = [1, 2] b1 = [1, 2] a = [a0, a1] b = [b0, b1] del a0, a1, b0, b1 There's nothing about *him* expecting anything wrong to happen. The question is how to draw a diagram that unambiguously shows the resulting structure using the "parcel tags" model shown in the diagrams (and without having a0/a1/etc as actual names) It's easy to draw such a diagram for the "boxes and arrows" model: (@ shows the box named by a[0][0]. Or a[1][0].) a[*]-->[*]v [*]-->[@]->(1) [*]-.^^ `++--. b[*]-->[*]-->[*]--'| | [*]-. [*]---+-.| v | || [*]--' vv [*]--->(2) If the "parcel tags" model can't show it, then the "parcel tag" model clearly is not a correct and complete depiction of how Python actually works. (If I were drawing a picture rather than ASCII I'd add something to make it clear that the pairs shown are list objects Like, it's a circle with the word "list" and two pointer-boxes inside it.) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 12-09-2015 18:09, MRAB wrote: > On 2015-09-12 17:29, Dennis Lee Bieber wrote: >> But no one had tested the algorithm with the rate of change the >> Ariane >> 5 could produce -- so an algorithm that was developed for, and safe with, >> the smaller Ariane suddenly went "something's wrong -- abandon ship" >> >> Nothing inherent in the language... >> > What would C++ have done in the same situation? Would Ariane still have > failed? Probably... > And that's exactly the point. C++, or Ada, for that matter have decades old documented best practices and code patterns to deal with those aspects of the language that can induce in error. Integer overflow is a well documented problem. And relying on it, is documented as a bad idea for several reasons, including the changes in the underlying system that eventually led to Ariane incident. For all that is worth, C++ issues with all sorts of overflows and unchecked memory are documented from the very first beginning of the language. Same with C and same with Ada own particular issues. A safe(r) language just presents different ways of shooting one's foot. We can discuss how much of a bad boy C++ is, but at the end of the day programers will just keep on make mistakes and eventually on those very areas the safer language doesn't provide a safety net. One can argue that by offering more ways to shoot one's foot, C and C++ are more dangerous to use than other considered safer languages. But that doesn't gel with the operative history of C or C++ that are running mission critical systems, from stock markets to nuclear power plants. These languages just demand a different breed of programmers and different methods of testing. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 12/09/2015 17:29, Dennis Lee Bieber wrote: On Sat, 12 Sep 2015 05:11:46 +0100, Mario Figueiredo declaimed the following: On 12-09-2015 03:35, Mark Lawrence wrote: Ada took over from CORAL in the UK, at least in military projects. It was also used in the aircraft industry. My old work mates tell me that its completely died a death, to be replaced by C++. Someone please remind me never to fly again. Alright. But then someone should probably have reminded you that a long time ago. Maybe you missed it when an Ada integer overflow bug produced one of the most expensive software bugs in history by crashing the Ariane 501 rocket and its 4 cluster sattelites payload. As I recall, the software did exactly what it was supposed to do in that situation... But no one had tested the algorithm with the rate of change the Ariane 5 could produce -- so an algorithm that was developed for, and safe with, the smaller Ariane suddenly went "something's wrong -- abandon ship" Nothing inherent in the language... Well if the backup system that took over when the primary system gave up the ghost had used a different algorithm, and had been tested for an appropriate range of inputs, we wouldn't be having this discussion. It didn't. The rest is history, and very expensive history at that. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 12/09/2015 17:24, Dennis Lee Bieber wrote: On Sat, 12 Sep 2015 03:35:00 +0100, Mark Lawrence declaimed the following: Ada took over from CORAL in the UK, at least in military projects. It was also used in the aircraft industry. My old work mates tell me that its completely died a death, to be replaced by C++. Someone please remind me never to fly again. Still used on some of the boxes being made... (I've just spent a month investigating problem reports for a software release). Granted, that's an Ada 83 cross compiler running on VAX/VMS itself running on a Windows server box with an emulator. It would cost way too much money to try to recompile with, say, GNAT Pro -- as the entire suite (including the compiler) would have to be recertified for airworthiness. Having seen the comments on this thread I think some of the participants need to be recertified for programmerworthiness. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote: The question is whether what "pointer" means in languages that use the word is*so* different than its meaning in the Python sense I can't find a single reference to pointer in the python docs outside of ctypes. What is its python sense? Is-there-no-hammer-in-this-toolbox-ly y'rs Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
On Sat, Sep 12, 2015 at 2:24 PM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > > On Sat, Sep 12, 2015 at 4:10 PM, Tim Peters wrote: > >> "A potential problem" with .astimezone()'s default is that it _does_ >> create a fixed-offset zone. It's not at all obvious that it should do >> so. First time I saw it, my initial _expectation_ was that it >> "obviously" created a hybrid tzinfo reflecting the system zone's >> actual daylight rules, as various "tzlocal" implementations outside of >> Python do. >> > > The clue should have been that .astimezone() is an instance method and > you don't need to know time to create a hybrid tzinfo. If a Local tzinfo > was available, it could just be passed to the .astimezone() method as an > argument. You would not need .astimezone() to both create a tzinfo and > convert the datetime instance to it. > > Still, I agree that this was a hack and a very similar hack to the one > implemented by pytz. Hopefully once PEP 495 is implemented we will > shortly see "as intended" tzinfos to become more popular. > The repeated claims (by Alexander?) that astimezone() has the power of pytz's localize() need to stop. Those pytz methods work for any (pytz) timezone -- astimezone() with a default argument only works for the local time zone. (And indeed what it does is surprising, except perhaps to pytz users.) -- --Guido van Rossum (python.org/~guido) -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On 09/12/2015 04:14 PM, Emile van Sebille wrote: > On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote: > >> The question is whether what "pointer" means in languages that use the >> word is*so* different than its meaning in the Python sense > > I can't find a single reference to pointer in the python docs outside > of ctypes. What is its python sense? I should have said "proposed sense" (except I don't really mean proposed as in "let's change all the docs" but as "let's stop the hissy-fits when someone uses the term"), i.e. the way I, I think random832, and others use it re python. Sorry, I see in retrospect my phrasing could be confusing. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On 12/09/2015 23:34, rurpy--- via Python-list wrote: On 09/12/2015 04:14 PM, Emile van Sebille wrote: On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote: The question is whether what "pointer" means in languages that use the word is*so* different than its meaning in the Python sense I can't find a single reference to pointer in the python docs outside of ctypes. What is its python sense? I should have said "proposed sense" (except I don't really mean proposed as in "let's change all the docs" but as "let's stop the hissy-fits when someone uses the term"), i.e. the way I, I think random832, and others use it re python. Sorry, I see in retrospect my phrasing could be confusing. The "hissy-fits" are caused because Python the language does not have pointers, so by definition there is no need to mention them in any way, shape or form in any Python thread. What is so difficult to understand about that? I would say it's not rocket science, but the insurers that paid out over Ariane 5 maybe wouldn't be too happy with that. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Context-aware return
On Thursday, September 10, 2015 at 8:44:01 PM UTC-4, Denis McMahon wrote: > On Fri, 11 Sep 2015 03:54:14 +1000, Steven D'Aprano wrote: > > > If I did this thing, would people follow me down the street booing and > > jeering and throwing things at me? > > Yes > > >>> x = func() > >>> x > >>> func() > >>> print x == func() > >>> assert x == func() > > Would you expect the last two calls to func() to return 999 or "Awesome"? > Why? What is the material difference if any between interpreter (a) > displaying the return value and (b) comparing the return value with > another value. > > Debugging nightmare! I'll add my voice to the rising chorus condemning the very notion of a function that behaves this way! Then, I'll give you an implementation (Python 2): import inspect import opcode def magic_return(): frame = inspect.stack()[1][0] code = frame.f_code next_opcode = opcode.opname[ord(code.co_code[frame.f_lasti+3])] if next_opcode == "PRINT_EXPR": ret = "Used at the prompt" elif next_opcode == "POP_TOP": ret = "Value ignored" else: ret = "Normal call" print ret return ret def try_it(): magic_return() x = magic_return() print magic_return() magic_return() + "" This examines the byte code of the caller to determine the next byte code after the CALL_FUNCTION that called us. The byte code used next shows what will happen to the return value. Try it out: $ python -i detect_caller.py >>> magic_return() Used at the prompt 'Used at the prompt' >>> try_it() Value ignored Normal call Normal call Normal call Normal call >>> I'm sure there are plenty of cases this gets wrong. If you try to pin this on me, I will swear up and down that someone hacked into my account to send this message... --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Sunday, September 13, 2015 at 4:05:21 AM UTC+5:30, ru...@yahoo.com wrote: > On 09/12/2015 04:14 PM, Emile van Sebille wrote: > > On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote: > > > >> The question is whether what "pointer" means in languages that use the > >> word is*so* different than its meaning in the Python sense > > > > I can't find a single reference to pointer in the python docs outside > > of ctypes. What is its python sense? > > I should have said "proposed sense" (except I don't really mean > proposed as in "let's change all the docs" but as "let's stop the > hissy-fits when someone uses the term"), i.e. the way I, I think > random832, and others use it re python. Sorry, I see in retrospect > my phrasing could be confusing. Here is my post a little way up: --- On Saturday, September 12, 2015 at 10:02:40 PM UTC+5:30, Steven D'Aprano wrote: > On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: > > > Anyway, maybe we do need a term to distinguish Python/C#/Java pointers > > from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since > > the key thing about it is you can't do pointer arithmetic on them to get > > the object "next to" the one it points at. > > How about *just don't call them pointers*? You know, since they aren't > pointers in the computer science sense. > > The Free On-line Dictionary of Computing defines "pointer": > >1. An address, from the point of view of a >programming language. A pointer may be typed, with its type >indicating the type of data to which it points. > Insisting that Python has pointers is like insisting that you use a text > editor by flipping bits. "What happens if I press Ctrl-X?" "Well, these > bits on the screen flip from black to white, these bits flip from white to > black, and these stay the same." > This is from the docs https://docs.python.org/3/library/functions.html#id id(object) Return the "identity" of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. Two objects with non-overlapping lifetimes may have the same id() value. CPython implementation detail: This is the address of the object in memory. --- which may be summarized as: 1. Steven (quoting Online dictionary): Pointer = Address 2. Steven: "Python has pointers" is ridiculous 3. Python docs: id returns an address in (C)Python To which we have Chris saying CPython ≠ Python Which reminds me of another definition Fig-Leaf: A device for converting poor porn into high art Even in languages like C with an ISO standard adhering to the standard is academic (gcc's switch is --pedantic) and it is in practice major implementations like gcc and MSC that define and push the standard. In python, CPython is the standard and other implementations can lay claim to being 'python' to the extent that they adhere to the standard. Or have I missed some ISO-ization? -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote: > On 12/09/2015 23:34, rurpy--- via Python-list wrote: > > On 09/12/2015 04:14 PM, Emile van Sebille wrote: > >> On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote: > >> > >>> The question is whether what "pointer" means in languages that use the > >>> word is*so* different than its meaning in the Python sense > >> > >> I can't find a single reference to pointer in the python docs outside > >> of ctypes. What is its python sense? > > > > I should have said "proposed sense" (except I don't really mean > > proposed as in "let's change all the docs" but as "let's stop the > > hissy-fits when someone uses the term"), i.e. the way I, I think > > random832, and others use it re python. Sorry, I see in retrospect > > my phrasing could be confusing. > > > > The "hissy-fits" are caused because Python the language does not have > pointers, so by definition there is no need to mention them in any way, > shape or form in any Python thread. What is so difficult to understand > about that? I would say it's not rocket science, but the insurers that > paid out over Ariane 5 maybe wouldn't be too happy with that. > > -- > My fellow Pythonistas, ask not what our language can do for you, ask > what you can do for our language. > > Mark Lawrence After all the discussion here, it seems a bit disingenuous to flatly say that Python has no pointers, and to dismiss people's debate about it. Pointers are not a simple concept. In a language like C, they have a number of aspects, some of which are apparent in the Python world, and some of which are not. Python names refer to values, and this behavior is clearly related to pointers under the hood. Whatever Python implementation you are talking about, a Python name must have some way to indicate what value it refers to. In CPython, this is implemented with a pointer. This is what people mean when they say that of course Python has pointers. But in C, pointers mean more than that. You can perform arithmetic on them, to access memory as a linearly addressed abstraction. Python has nothing like this. In C, a pointer can refer to another variable. Again, Python has nothing like this. Python names refer to values, but they cannot refer to other names. These last two reasons are why people say that Python does not have pointers. As a language concept, Python has no pointers, because you cannot have names referring to names, and because you cannot perform arithmetic on references. The references from names to values are not things that can be manipulated themselves. In its implementation, CPython uses pointers. But if you say that Python has pointers because CPython uses pointers, then you might as well say that Python is statically typed because the CPython source has type declarations. It's a confusion of implementation and language to conflate these two. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Sun, Sep 13, 2015 at 9:39 AM, Rustom Mody wrote: > To which we have Chris saying CPython ≠ Python > Which reminds me of another definition > Fig-Leaf: A device for converting poor porn into high art > > Even in languages like C with an ISO standard adhering to the standard is > academic (gcc's switch is --pedantic) and it is in practice major > implementations like gcc and MSC that define and push the standard. > > In python, CPython is the standard and other implementations can lay claim to > being 'python' to the extent that they adhere to the standard. > > Or have I missed some ISO-ization? ISO hasn't standardized Python, but the Python developers do distinguish between the language and the various implementations. Yes, CPython does push forward ahead of the others, and thus sometimes another Python will replicate CPython behaviour rather than seeking an official language pronouncement; but other times, the PyPy or Jython or Brython folks come to python-dev with a question. As a general rule, most PEPs are about the language, not the implementation, so you can eyeball those to see what you'd need to implement to write a Python from scratch. CPython does not intrinsically define the standard. Some languages are done this way (Pike, for instance), but Python is not. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On 09/12/2015 05:14 PM, Mark Lawrence wrote: > On 12/09/2015 23:34, rurpy--- via Python-list wrote: >> On 09/12/2015 04:14 PM, Emile van Sebille wrote: >>> On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote: >>> The question is whether what "pointer" means in languages that use the word is*so* different than its meaning in the Python sense >>> >>> I can't find a single reference to pointer in the python docs >>> outside of ctypes. What is its python sense? >> >> I should have said "proposed sense" (except I don't really mean >> proposed as in "let's change all the docs" but as "let's stop the >> hissy-fits when someone uses the term"), i.e. the way I, I think >> random832, and others use it re python. Sorry, I see in retrospect >> my phrasing could be confusing. > > The "hissy-fits" are caused because Python the language does not have > pointers, so by definition there is no need to mention them in any > way, shape or form in any Python thread. Right. "And our country has no social unrest so there is no need for any mention of social unrest on our internet." (a common justification for censorship in some countries.) You can't define away reality, Bucky. But the issue is not one that can be expressed as a binary "has" or "has not". It is about how to best describe how Python works and what descriptions work best for what groups of people (at least in my view). > What is so difficult to understand about that? You'll find my questions about that in my previous posts. You can find them here: https://mail.python.org/pipermail/python-list/2015-September/thread.html If you have any specific serious questions I'll be happy to try to answer them for you. > I would say it's not rocket science, but the > insurers that paid out over Ariane 5 maybe wouldn't be too happy with > that. No clue what the Ariane 5 has to do with Python or how Python works is described. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Sunday, September 13, 2015 at 5:32:44 AM UTC+5:30, Ned Batchelder wrote: > In its implementation, CPython uses pointers. But if you say that Python > has pointers because CPython uses pointers, then you might as well say > that Python is statically typed because the CPython source has type > declarations. It's a confusion of implementation and language to conflate > these two. Yes that "because" can be ridiculous/disingenuous. Good deal of it in this thread itself. Consider int. Say there are 10,000 int something_or_other; in the CPython sources Out of these say 50 are the direct implementation python's int The remaining 9950 C-ints have no direct correlate with python's int. The disingenuous reasoning is some kind of statistical argument of 10,000 vs 50. The reasonable reasoning is that only those 50 are relevant to the discussion. Likewise pointers If one were to trace the semantics of looking up a variable in CPython, one would find some C code doing pointer dereferencing. One would also find zillions of other uses of pointers that have no direct correlate to python's variables. What of it? If I were to be more technically correct than saying "Python's variables are C-pointers" I could say something like: "Python variables are C pointers with much stronger data-structure invariants related to ownership. And implemented with ref-counting, gc etc as scaffolding to ensure them. These stronger invariants make impossible in python common C errors like null-pointer referencing. The corresponding cost of these stronger invariants is that C's pointer type is rendered un-first-class in python" -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On 09/12/2015 05:39 PM, Rustom Mody wrote: > On Sunday, September 13, 2015 at 4:05:21 AM UTC+5:30, ru...@yahoo.com wrote: >> On 09/12/2015 04:14 PM, Emile van Sebille wrote: >>> On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote: >>> The question is whether what "pointer" means in languages that use the word is*so* different than its meaning in the Python sense >>> >>> I can't find a single reference to pointer in the python docs outside >>> of ctypes. What is its python sense? >> >> I should have said "proposed sense" (except I don't really mean >> proposed as in "let's change all the docs" but as "let's stop the >> hissy-fits when someone uses the term"), i.e. the way I, I think >> random832, and others use it re python. Sorry, I see in retrospect >> my phrasing could be confusing. > > Here is my post a little way up: > > --- > On Saturday, September 12, 2015 at 10:02:40 PM UTC+5:30, Steven D'Aprano > wrote: > [...] >> Insisting that Python has pointers is like insisting that you use a text >> editor by flipping bits. "What happens if I press Ctrl-X?" "Well, these >> bits on the screen flip from black to white, these bits flip from white to >> black, and these stay the same." > > This is from the docs > https://docs.python.org/3/library/functions.html#id > > id(object) > > Return the "identity" of an object. This is an integer which is > guaranteed to be unique and constant for this object during its lifetime. Two > objects with non-overlapping lifetimes may have the same id() value. > > CPython implementation detail: This is the address of the object in > memory. > > --- > > which may be summarized as: > 1. Steven (quoting Online dictionary): Pointer = Address > 2. Steven: "Python has pointers" is ridiculous > 3. Python docs: id returns an address in (C)Python > > To which we have Chris saying CPython ≠ Python > Which reminds me of another definition > Fig-Leaf: A device for converting poor porn into high art > > Even in languages like C with an ISO standard adhering to the standard is > academic (gcc's switch is --pedantic) and it is in practice major > implementations like gcc and MSC that define and push the standard. > > In python, CPython is the standard and other implementations can lay claim to > being 'python' to the extent that they adhere to the standard. > > Or have I missed some ISO-ization? I have to agree with Steven and Chris here. Among other reasons because although id() allows you to determine if two objects are the same object, you can't dereference it to get any access to the object. So id() certainly doesn't give you something I would call a pointer. And though you are right about cpython's preeminent position, I don't think one can use that to make an argument about python-the-language unless it can be shown that implementing it in some other way would be very difficult. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On 09/12/2015 06:02 PM, Ned Batchelder wrote: > On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote: > [...] > But in C, pointers mean more than that. You can perform arithmetic on > them, to access memory as a linearly addressed abstraction. Python has > nothing like this. > > In C, a pointer can refer to another variable. Again, Python has > nothing like this. Python names refer to values, but they cannot > refer to other names. > > These last two reasons are why people say that Python does not have > pointers. > > As a language concept, Python has no pointers, because you cannot have > names referring to names, and because you cannot perform arithmetic on > references. The references from names to values are not things that can > be manipulated themselves. The reason python doesn't have pointers is that the majority of developers and documenters chose not to use the term. I don't see that pointer arithmetic is necessary to call something a pointer (and i think someone else said the same earlier). And references to a name I think that is an artifact of C because in C names and values are inextricably welded together at compile time -- a pointer to a name is also necessarily a pointer to a value. Since there are no C pointers to don't point to values they can provide a way to describe Python "things" that also point to values. If one acknowledges that those two properties are not intrinsic requirements for pointerness then describing the things "in" a python object that are used to identify and dereference other objects, as pointers is not at all unreasonable. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Saturday, September 12, 2015 at 6:25:39 PM UTC-6, ru...@yahoo.com wrote: > On 09/12/2015 05:39 PM, Rustom Mody wrote: > [...] > > which may be summarized as: > > 1. Steven (quoting Online dictionary): Pointer = Address > > 2. Steven: "Python has pointers" is ridiculous > > 3. Python docs: id returns an address in (C)Python > > > > To which we have Chris saying CPython ≠ Python > > [...] > I have to agree with Steven and Chris here. > [...] I'm writing too fast. Just to clarify, I don't of course agree that python doesn't have pointers (or something that can be labeled as such), just that the existence of id() and cpython's internal use of pointers are not good arguments that it doesn't. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Rustom Mody writes: > On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote: > > You've clearly committed to some ontology that just doesn't match > > the Python data model. > > How about lay-English ontology in which "point to" and "refer to" are fairly > synonymous? That's important. It's unrelated, though, to the very specific technical programming concepts to which I was responding. -- \ “One bad programmer can easily create two new jobs a year. | `\ Hiring more bad programmers will just increase our perceived | _o__) need for them.” —David Lorge Parnas, 1999-03 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
[Guido]
>> Those pytz methods work for any (pytz) timezone -- astimezone() with a
>> default argument only works for the local time zone.
{Alex]
> That's what os.environ['TZ'] = zonename is for. The astimezone() method
> works for every timezone installed on your system. Try it - you won't even
> need to call time.tzset()!
I tried it. It makes no difference to anything for me. I stay on
Windows to remind people that millions of Python users don't see any
of the horrid nonsense Linuxish systems force on poor users ;-)
> ...
> In any case, there are three approaches to designing a TZ database interface
> in the datetime module: the "as intended" approach, the pytz approach and
> the astimezone(zonename:str) approach.
Portability rules out #3, unless Python bundles its own zoneinfo wrapping.
pytk's approach has many attractions, like no need for `fold` and no
breakage of anything, and blazing fast .utcoffset(). Except at least
arithmetic would have to be patched to do a
`normalize` variant by magic (to attach the now-appropriate
fixed-offset tzinfo, but without changing the clock in the process).
Alas, that would be a huge speed hit for classic arithmetic.
So, as always, the original intent is the only one that makes sense in
the end ;-)
> ...
> That's why I believe PEP 495 followed by the implementation
> of fold-aware "as intended" tzinfos (either within stdlib or by third
> parties) is the right approach.
Me too - except I think acceptance of 495 should be contingent upon
someone first completing a fully functional (if not releasable)
fold-aware zoneinfo wrapping. Details have a way of surprising, and
we should learn from the last time we released a tzinfo spec in the
absence of any industrial-strength wrappings using it.
--
https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
On Sat, Sep 12, 2015 at 5:46 PM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > > On Sat, Sep 12, 2015 at 6:24 PM, Guido van Rossum > wrote: > >> The repeated claims (by Alexander?) that astimezone() has the power of >> pytz's localize() need to stop. > > > Prove me wrong! :-) > > >> Those pytz methods work for any (pytz) timezone -- astimezone() with a >> default argument only works for the local time zone. > > > That's what os.environ['TZ'] = zonename is for. The astimezone() method > works for every timezone installed on your system. Try it - you won't even > need to call time.tzset()! > That's global state. Doesn't count. > (And indeed what it does is surprising, except perhaps to pytz users.) > > > That I agree with. Which makes it even more surprising that I often find > myself and pytz advocates on the opposite sides of the fence. > > Granted, setting TZ is a silly trick, but one simple way to bring a full > TZ database to Python is to allow .astimezone() take a zonename string like > 'Europe/Amsterdam' or 'America/Montevideo' as an argument and act as > os.environ['TZ'] = zonename; t.astimezone() does now, but without messing > with global state. > It might as well be a different method then though. > I made this suggestion before, but I find it inferior to "as intended" > tzinfos. > > The only real claim that I am making is that fictitious fixed offset > timezones are useful and we already have some support for them in stdlib. > The datetime.timezone instances that .astimezone() attaches as tzinfo are > not that different from the instances that are attached by pytz's localize > and normalize methods. > And it has the same defect. > In fact, the only major differences between datetime.timezone instances > and those used by pytz is that pytz's EST and EDT instances know that they > come from America/New_York, while datetime.timezone instances don't. > That's why once you specify America/New_York in localize, your > tzinfo.normalize knows it implicitely, while in the extended .astimezone() > solution you will have to specify it again. This is not a problem when you > only support one local timezone, but comes with a different set of > tradeoffs when you have multiple timezones. > > One advantage of not carrying the memory of the parent zoneinfo in the > fixed offset tzinfo instance is that pickling of datetime objects and their > interchange between different systems becomes simpler. A pickle of a > datetime.timezone instance is trivial - same as that of a tuple of > timedelta and a short string, but if your fixed offset tzinfo carries a > reference to a potentially large zoneinfo structure, you get all kinds of > interesting problems when you share them between systems that have > different TZ databases. > The pickling should be careful to pickle by reference (on the timezone name). That its meaning depends on the tz database is a feature. > In any case, there are three approaches to designing a TZ database > interface in the datetime module: the "as intended" approach, the pytz > approach and the astimezone(zonename:str) approach. The last two don't > require a fold attribute to disambiguate end-of-dst times and the first one > does. With respect to arithmetic, the last two approaches are equivalent: > both timeline and classic arithmetics are possible, but neither is > painless. The "as intended" approach comes with classic arithmetic that > "just works" and encourages the best practice for timeline arithmetic: do > it in UTC. That's why I believe PEP 495 followed by the implementation of > fold-aware "as intended" tzinfos (either within stdlib or by third parties) > is the right approach. > Right. So please focus on this path and don't try to pretend to pytz users that hacks around astimezone() make pytz redundant, because they don't. There are other ways to fix the damage that pytz has done. -- --Guido van Rossum (python.org/~guido) -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On 13/09/2015 01:44, rurpy--- via Python-list wrote: On 09/12/2015 06:02 PM, Ned Batchelder wrote: On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote: [...] But in C, pointers mean more than that. You can perform arithmetic on them, to access memory as a linearly addressed abstraction. Python has nothing like this. In C, a pointer can refer to another variable. Again, Python has nothing like this. Python names refer to values, but they cannot refer to other names. These last two reasons are why people say that Python does not have pointers. As a language concept, Python has no pointers, because you cannot have names referring to names, and because you cannot perform arithmetic on references. The references from names to values are not things that can be manipulated themselves. The reason python doesn't have pointers is that the majority of developers and documenters chose not to use the term. Nonsense. I don't see that pointer arithmetic is necessary to call something a pointer (and i think someone else said the same earlier). And references to a name I think that is an artifact of C because in C names and values are inextricably welded together at compile time -- a pointer to a name is also necessarily a pointer to a value. Since there are no C pointers to don't point to values they can provide a way to describe Python "things" that also point to values. There are certainly no C pointers in Jython or IronPython but please don't let that stop you. If one acknowledges that those two properties are not intrinsic requirements for pointerness then describing the things "in" a python object that are used to identify and dereference other objects, as pointers is not at all unreasonable. You appear to have the same level of knowledge of Python internals as the RUE has of the Python 3.3+ FSR unicode implementation. Let's have some fun, is Python pass by value or pass by reference? It has to be more interesting debating that than the drivel that's gone before in this thread. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
[Tim] >> Me too - except I think acceptance of 495 should be contingent upon >> someone first completing a fully functional (if not releasable) >> fold-aware zoneinfo wrapping. [Alex] > Good idea. How far are you from completing that? In my head, it was done last week ;-) In real life, I'm running out of spare time for much of anything anymore. I don't expect to be able to resume zoneinfo fiddling for at least 2 weeks. >> Details have a way of surprising, and >> we should learn from the last time we released a tzinfo spec in the >> absence of any industrial-strength wrappings using it. > I completely agree. That's why I am adding test cases like Lord Hope Island > and Vilnius to datetimetester. That helps a lot, but "industrial-strength" implies "by algorithm". There are far too many zones to deal with by crafting a hand-written class for each. > I will try to create a zoneinfo wrapping prototype as well, but I will > probably "cheat" and build it on top of pytz. It would be crazy not to ;-) Note that Stuart got to punt on "the hard part": .utcoffset(), since pytz only uses fixed-offset classes. For a prototype - and possibly forever after - I'd be inclined to create an exhaustive list of transition times in local time, parallel to the list of such times already there in UTC. An index into either list then gives an index into the other, and into the list of information about the transition (total offset, is_dst, etc). -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Saturday, September 12, 2015 at 10:23:24 PM UTC-4, Mark Lawrence wrote: > On 13/09/2015 01:44, rurpy--- via Python-list wrote: > > On 09/12/2015 06:02 PM, Ned Batchelder wrote: > >> On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote: > >> [...] > >> But in C, pointers mean more than that. You can perform arithmetic on > >> them, to access memory as a linearly addressed abstraction. Python has > >> nothing like this. > >> > >> In C, a pointer can refer to another variable. Again, Python has > >> nothing like this. Python names refer to values, but they cannot > >> refer to other names. > >> > >> These last two reasons are why people say that Python does not have > >> pointers. > >> > >> As a language concept, Python has no pointers, because you cannot have > >> names referring to names, and because you cannot perform arithmetic on > >> references. The references from names to values are not things that can > >> be manipulated themselves. > > > > The reason python doesn't have pointers is that the majority of developers > > and documenters chose not to use the term. > > Nonsense. > > > You appear to have the same level of knowledge of Python internals as > the RUE has of the Python 3.3+ FSR unicode implementation. Let's have > some fun, is Python pass by value or pass by reference? It has to be > more interesting debating that than the drivel that's gone before in > this thread. Mark, I'm sure you can be more respectful than this. And let's please not start down the "PBV or PBR" road... :( --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 09/11/2015 11:22 PM, Skybuck Flying wrote: > I didn't learn anything from this posting, sorry ! ;) I too am not surprised. You're not here to learn, either about programming language theory, or about Python apparently. I would refer you to a good programming language theory class, but I suspect you're not interested in learning formal definitions and theory. The terms I used here are all from formal programming language theory, particularly the term "binding." If you're interested in it, this topic makes for a fascinating class. I loved my programming language theory class at uni. We used scheme to explore language construction and to build our own programming language. Cool stuff. I'm truly sorry you aren't interested in learning the underlying theories of things, or the reasons for certain aspects of the language. To me Python's ability to enable so many different programming paradigms, and to bring some of the coolest parts of LISP and Scheme to a language for the masses is really cool. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Sun, 13 Sep 2015 07:10 am, Random832 wrote: > Jussi Piitulainen writes: >> I think the best way is to say that a[0] and a[1] are the same object, >> while b[0] and b[1] are different objects. > > Sure, you can *say* that. But how do you draw it on a diagram with > sticky notes or parcel tags or whatever? However you like. Invent your own notation. A few suggestions: Colour coding: Have a convention that objects drawn in black imply that object identity is not important. That is, if you have two boxes drawn in black with the same value, you are making no claim one way or the other whether they are the same object or not. If, and only if, identity is important, then you give each object a unique colour. So if the user sees five boxes containing the value "foo", two in red, two in green, and one in black, they know that there are at least two, and possibly three, but no more than three, individual objects. Shapes: Likewise, except instead of colour, use the shape of the box to indicate identity. A rectangular box means you say nothing about identity. Other shapes (circle, oval, rhombus, trapezium, parallelogram, cloud-shape, etc.) uniquely represents the individual objects. IDs: Write the object ID on each box, or at least the boxes where identity is important. A good convention is that IDs start at 1. Or, rather than show a numeric ID, use a symbolic ID: a, b, c, d, e would reference five distinct objects. Or, use non-alphabetical symbolic IDs: *†‡ would let you identify three distinct objects. Add extra symbols as needed. Astral travel: According to those who believe in the astral plane, when you travel through the astral plane, a silver thread connects your physical body to your astral body. Or your earthly soul to your astral soul. Or whatever it is that they believe. Use the same symbolism: if you have two or more boxes representing the same object in different places, join them with a silver thread. Or other colour of your choice. Perhaps a dotted or dashed line. Hatch marks: There is a convention in geometry to indicate lines of equal length with a hatch mark (a small line perpendicular to the line itself). You can mark the boxes which refer to identical objects using a similar convention. Here is a crappy ASCII-art representation of various hatch marks on a horizontal line: ||||||///\\\XXX>< That is, reading from left to right: - 1 to 3 vertical lines; - 1 or 2 lines slanted up to the right; - 1 or 2 lines slanted down from the left; - 1 or 2 crossed lines; - single right-pointing arrow; - single left-pointing arrow. If you limit yourself to no more than four hatch marks, taken from the set of "|/\X<>", that gives you 1554 distinct markers. If you need to identify more than 1554 distinct objects on one diagram, I suggest your diagram is a tad too complex. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On 09/12/2015 08:22 PM, Mark Lawrence wrote: > You appear to have the same level of knowledge of Python internals as > the RUE has of the Python 3.3+ FSR unicode implementation. Let's have > some fun, is Python pass by value or pass by reference? It has to be > more interesting debating that than the drivel that's gone before in > this thread. Oh you are a devious one there! This should get good. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Michael Torrie writes: > On 09/12/2015 08:22 PM, Mark Lawrence wrote: > > You appear to have the same level of knowledge of Python internals as > > the RUE has of the Python 3.3+ FSR unicode implementation. Let's have > > some fun, is Python pass by value or pass by reference? It has to be > > more interesting debating that than the drivel that's gone before in > > this thread. > > Oh you are a devious one there! This should get good. No, it should stop there. Taunting trolls is no more welcome here than trolling. -- \ “I have always wished for my computer to be as easy to use as | `\ my telephone; my wish has come true because I can no longer | _o__) figure out how to use my telephone.” —Bjarne Stroustrup | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
[Alex]
>>> I will try to create a zoneinfo wrapping prototype as well, but I will
>>> probably "cheat" and build it on top of pytz.
[Tim]
>> It would be crazy not to ;-) Note that Stuart got to punt on "the
>> hard part": .utcoffset(), since pytz only uses fixed-offset classes.
>> For a prototype - and possibly forever after - I'd be inclined to
>> create an exhaustive list of transition times in local time, parallel
>> to the list of such times already there in UTC.
[Alex]
> Yes. The only complication is that you need four transition points instead
> of two per year in a regular DST case: (1) start of gap; (2) end of gap; (3)
> start of fold; and (4) end of fold. Once you know where you are with
> respect to those points, figuring out utcoffset(), dst() and tzname() for
> either value of fold is trivial.
I wouldn't call those extras transitions - they're just warts hanging
off of actual transitions. Earlier I showed Stuart how to determine
everything about a possible fold from a UTC time using pytz's internal
info, in
PEP-431/495
Fri, 28 Aug 2015 01:01:06 -0500
He didn't reply that I saw, so it was either obvious or
incomprehensible to him ;-) In any case, it just takes some very
simple code once the transition record the UTC time belongs in is
found. I'd be surprised if it weren't similarly easy to determine
everything about a possible gap.
At least in a zoneinfo wrapping, a hybrid tzinfo's .utcoffset() has to
(at least internally) find "the transition record the UTC time belongs
in" regardless.
> ...
> It's a shame though to work from a transitions in UTC list
But that's what tzfiles store. It would be insane for a zoneinfo
wrapping not to take advantage of that. For which reason, I do
consider dateutil's zoneinfo wrapping to be insane ;-) (It inherits
the default .fromutc())
Ah, BTW, I think dateutil's zoneinfo's wrapping also misunderstood
some of what's actually in a tzfile. Specifically, a tzfile's "
UTC/local indicators" and " standard/wall indicators" are 100% useless
for anything we need, and shouldn't even be read from the file(*)
(seek over 'em).
> because most of DST rules are expressed in local times and then
> laboriously converted into UTC.
It's just a few lines of code in zoneinfo's zic.c. Nobody is doing it
"by hand" there.
> I think I should also implement the POSIX TZ spec tzinfo.
For that you really should grab dateutil. It has a full
implementation of POSIX TZ rules, as hybrid tzinfos; here from its
docs:
>>> tz1 = tzstr('EST+05EDT,M4.1.0,M10.5.0')
>>> tz2 = tzstr('AEST-10AEDT-11,M10.5.0,M3.5.0')
>>> dt = datetime(2003, 5, 8, 2, 7, 36, tzinfo=tz1)
>>> dt.strftime('%X %x %Z')
'02:07:36 05/08/03 EDT'
>>> dt.astimezone(tz2).strftime('%X %x %Z')
'16:07:36 05/08/03 AEST'
Of course this implementation is tied into dateutil's rich supply of
"calendar operations" too.
> This is where the advantage of the "as intended" approach will be obvious.
? "As intended" is all about (to me) using hybrid tzinfos. And those
are far richer in tzfiles than from POSIX rules. The latter only
present us with simplest-possible DST transitions; tzfiles present us
with every absurd political manipulation yet inflicted on humankind
;-)
---
(*) Long boring story. Short course: those indicators are only
needed, on some systems, if a POSIZ TZ rule specifies a zone offset
but gives no rules at all for daylight transitions, _and_ the system
has a "posixrules" tzfile. Then an insane scheme is used to make up
daylight rules "as if" the source file from which the posixrules
tzfile was created had been for a zone with the TZ-specified standard
offset instead, and these absurd indicators are used to figure out
whether the posixrules source file specified _its_ daylight rules
using UTC or local times, and if the later case then whether using
standard time or wall-clock time instead. It's completely nuts.
--
https://mail.python.org/mailman/listinfo/python-list
Re: RPI.GPIO Help
Hello, there.
MRAB, thank you for teaching me proper Python syntax for how I tried to
use the or operator.
Dennis, I must have learned allot recently as I believe I understood 99%
of that code. I see how it is not just more advanced, but actually better
than what I had. However, line 47 (cumTime[colour] += now - changeTime)
had an error I could not figure out what to do about. Considering my time
line I decided not to leave it to latter. Will be using these electronic
flags at next year's game and for then I intend to just be better about
everything. Will use your code to learn to get there.
Hakugin, thank you you as well. I took the basic ideas you showed me for
improvement and used them. The pulse settings variable was not liked by
the interpreter, so I simplified it. I turned it into a hex value for
each button press, then in the main loop I inserted the whole line for
the LED pulse command, but put "pulse_settings" after "hex=" in the
arguments. This worked.
I added a few green blinks of the LED to indicate the starting and
stopping of the script. Also, I got the log files score print outs upon
exit working. Very important, and also importantly, I have it so it stops
after a certain amount of time. For testing, I have it at 60 seconds, but
games will be 3600 seconds on average when really being used.
The stopping after a certain amount of time was done in a way that
apparently technically works, but seems very weird and probably wrong to
me. You may freak out when you see it. I used an else statement inside a
while loop and it just feels so strange. At least it works.
Hoping I might be able to make it so I boot the Pi, it loads the script,
script waits for the user to tell it how long to make a game, game
starts, scripts ends game at appropriate time, saves dated log file with
scores, then waits for user to enter new game length to start new game.
This is probably way to much to hope to accomplish in time. For next year
for sure though. It would be better for the referees to operate that way.
Next I will try and integrate wireless communications. If anyone here
knows Synapse RF modules well, or at all, PLEASE contact me.
Here is the code I did up most recently. Again, thanks for all the
suggestions, code examples, and general help.
import atexit
import sys
import time
from blinkstick import blinkstick
import RPi.GPIO as GPIO
gamestart = time.time()
gamelength = 60
led = blinkstick.find_first()
colour = 0
time_red = 0
time_yellow = 0
time_blue = 0
timestamp = time.strftime("%H:%M:%S")
pulse_settings = []
led.blink(name="green", repeats=2)
GPIO.setmode(GPIO.BCM)
GPIO.setup(22, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(23, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(24, GPIO.IN, pull_up_down=GPIO.PUD_UP)
def red_button(channel):
global colour
global pulse_settings
if colour != 1:
colour = 1
pulse_settings = "#FF"
def yellow_button(channel):
global colour
global pulse_settings
if colour != 2:
colour = 2
pulse_settings = "#FF8900" # Corrected yellow for cheap LED strip.
def blue_button(channel):
global colour
global pulse_settings
if colour != 3:
colour = 3
pulse_settings = "#FF"
GPIO.add_event_detect(22, GPIO.FALLING, callback=red_button,
bouncetime=200)
GPIO.add_event_detect(23, GPIO.FALLING, callback=yellow_button,
bouncetime=200)
GPIO.add_event_detect(24, GPIO.FALLING, callback=blue_button,
bouncetime=200)
def exit_handler():
print "\033[0;41;37mRed Team:\033[0m ", time_red
print "\033[0;103;30mYellow Team:\033[0m ", time_yellow
print "\033[0;44;37mBlue Team:\033[0m ", time_blue
flog = open("flag1.log", "a")
flog.write("\n" + timestamp + "\n" + "Red Team: " + str(time_red) +
"\n" + "Yellow Team: " + str(time_yellow) + "\n" + "Blue Team: " + str
(time_blue) + "\n")
flog.close()
led.blink(name="green", repeats=4)
led.set_color(name="black")
atexit.register(exit_handler)
while time.time() < gamestart + gamelength:
if colour == 1:
time_red += 1
elif colour == 2:
time_yellow += 1
elif colour == 3:
time_blue += 1
led.pulse(hex=pulse_settings, repeats=1, duration=2000, steps=50)
time.sleep(0.1)
else:
sys.exit()
GPIO.cleanup()
--
https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Random832 writes: > Jussi Piitulainen writes: >> I think the best way is to say that a[0] and a[1] are the same >> object, while b[0] and b[1] are different objects. > > Sure, you can *say* that. But how do you draw it on a diagram with > sticky notes or parcel tags or whatever? I prefer to outline my code as code, with comments where needed, without irrelevant details. Those pointers and tags are usually irrelevant, best omitted altogether. -- https://mail.python.org/mailman/listinfo/python-list
