Why an object changes its "address" between adjacent calls?
C:\Python34\Doc>py
Python 3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 19:28:18) [MSC v.1600 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter as tk
>>> root = tk.Tk()
>>> tk.Label(root, text='label one', font='TkDefaultFont').pack()
>>> from tkinter import font
>>> font.nametofont('TkDefaultFont')
>>> font.nametofont('TkDefaultFont')
>>>
The "address" of the Font object 'TkDefaultFont' changes, why?
Best Regards,
Jach Fong
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
Chris Angelico writes: > Also: I would call that a "note", not a "warning". Please stop > spreading the FUD that there's somehow something "wrong" with using > what is a well-known convention for a format mini-language. If I say there's something “wrong” with it (is that different from saying there's something wrong with it? I am not sure the function of the quotes you use there), I'm not aware. I haven't stated the printf-style formatting is especially prone to official deprecation. As for a clear *preference*, as presented in the Python documentation, for ‘str.format’ rather than printf-style, I'll continue to spread that implication which seems a pretty uncontroversial reading of the Python documentation. -- \“Beware of bugs in the above code; I have only proved it | `\ correct, not tried it.” —Donald Knuth, 1977-03-29 | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Why an object changes its "address" between adjacent calls?
On 06/17/2018 12:08 AM, Jach Fong wrote:
C:\Python34\Doc>py
Python 3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 19:28:18) [MSC v.1600
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter as tk
>>> root = tk.Tk()
>>> tk.Label(root, text='label one', font='TkDefaultFont').pack()
>>> from tkinter import font
>>> font.nametofont('TkDefaultFont')
>>> font.nametofont('TkDefaultFont')
>>>
The "address" of the Font object 'TkDefaultFont' changes, why?
Best Regards,
Jach Fong
def nametofont(name):
"""Given the name of a tk named font, returns a Font representation.
"""
return Font(name=name, exists=True)
Every time you call nametofont(), you're creating a new instance of the
Font class.
-Jim
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why an object changes its "address" between adjacent calls?
On Sun, 17 Jun 2018 15:08:27 +0800, Jach Fong wrote: > The "address" of the Font object 'TkDefaultFont' changes, why? Its not an address, it is an ID number. The ID number changes because you get a different object each time you call the function. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Sat, 16 Jun 2018 23:11:41 -0700, Jim Lee wrote: > Python is not like other languages. Python is not like languages like C, Pascal, Algol, Fortran, D, Java (unboxed native values only) and those like that. However, Python *is* like other languages like Javascript, Ruby, Java (objects only), PHP, and others. > For one thing, there are no > "variables" in Python (in the way you think of them). Indeed -- there are no variables in Python, if you think of a variable as meaning a virtual box at a fixed memory address, containing a value, and associated with a type, like in C or Pascal. > There are only > objects and names. Names can be thought of like void pointers in C, for > example. They don't have a "type" themselves - they only refer to > objects, and the type of object they refer to can change at will. Very true. > Also, there are no integers in Python. Scalar values are actually > objects. The number 35 is not an integer, it is an object that has an > integer type. I would put it another way. Python certainly has integers, but there are no integers in C, there are only fixed-width collections of one or more bytes. They don't have any integer methods, or methods at all. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Metasyntactic thingies
We know the placeholder names used for generic variables: foo bar baz foobar ... and the Pythonic equivalents: spam eggs cheese aardvark ... But what placeholder names do you use for functions, methods or other actions? As in, placeholder verbs rather than nouns? Aside from such boring ones as "do_work" and similar, the only placeholder verb I can think of is frobnicate. Does anyone else have any? "Why do you keep saying wossname?" said Rincewind. "Limited wossname. Doodah. Thingy. You know, it's got words in it," said the parrot. "Dictionary?" said Rincewind. -- Terry Pratchett, "Eric" -- Steven D'Aprano -- https://mail.python.org/mailman/listinfo/python-list
Does inspect.getstack work on other Python implementations?
Anyone here use IronPython, Jython or PyPy? Does inspect.getstack always work? Is it considered an implementation detail for CPython or something promised to work on any compliant Python interpreter? I see that it doesn't even exist on Jython 2.5, does anyone know whether it exists in later versions? -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Does inspect.getstack work on other Python implementations?
On 2018-06-17 10:19, Steven D'Aprano wrote: > Anyone here use IronPython, Jython or PyPy? > > Does inspect.getstack always work? Is it considered an implementation > detail for CPython or something promised to work on any compliant > Python interpreter? > > I see that it doesn't even exist on Jython 2.5, does anyone know > whether it exists in later versions? Well, inspect.currentframe says: > CPython implementation detail: This function relies on Python stack > frame support in the interpreter, which isn’t guaranteed to exist in > all implementations of Python. If running in an implementation > without Python stack frame support this function returns None. and presumably if stack frame support isn't guaranteed to exist for one inspect function it's similarly un-guaranteed in others. signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Understanding memory location of Python variables
On 17/06/2018 03:28, Grant Edwards wrote: On 2018-06-16, ip.b...@gmail.com wrote: I'm intrigued by the output of the following code, which was totally contrary to my expectations. Can someone tell me what is happening? myName = "Kevin" id(myName) 47406848 id(myName[0]) 36308576 id(myName[1]) 2476000 What's happening is that you're paying attention to the values returned by id(), when you should not. The fact that CPython returns a VM address when you call id() is just an "accident" of that particular implimentation. You shouldn't assume that id() returns anything other than a number that is unique to each object. Any time you spend worrying about how that number is calculated is proably wasted. I expected myName[0] to be located at the same memory location as the myName variable itself. Python is not C. I also expected myName[1] to be located immediately after myName[0]. Python is not C. Just in case you missed that... Python is not C. So, how /do/ you obtain the memory address of those values are located? For example, in order to pass it to some foreign C function that takes a void* parameter. I assume there is a memory address at least for the "Kevin" value, as the other two might yield temporary objects for "K" and "e" rather the in-place strings which are the first and second characters of the name. -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Metasyntactic thingies
Steven D'Aprano writes: > But what placeholder names do you use for functions, methods or other > actions? As in, placeholder verbs rather than nouns? I find Lewis Carroll's canon to be a rich source of pronounceable nonsense words. The poem Jabberwocky is particularly valuable https://en.wikipedia.org/wiki/Jabberwocky#Lexicon>. The trouble with doesn't-mean-anything words is that they quickly *acquire* meaning. Many of the words that were unknown before Jabberwocky have since entered the English language as accepted standard words. This is going on all the time. The term “widget” was once a deliberately abstract unit of manufacture, a metasyntactic word for discussion of economics deliberately chosen because it had no concrete meaning. It has since gained concrete meaning, and would be too confusing to use it today without disambiguating https://en.wikipedia.org/wiki/Widget>. Another good example is the word “goon”. In the early 20th century, the word was not widespread enough to have a fixed, determined meaning https://en.wiktionary.org/wiki/goon>, and the Popeye cartoon used it as a name for a strange grotesque giant in 1933. That word, perhaps more than the character, inspired the title of The Goon Show in the 1950s https://en.wikipedia.org/wiki/The_Goon_Show>. Simultaneously, the word was *also* used to mean a hired thug. Words were so freely appropriated and gleefully mangled to surreal effect in The Goon Show that it, too, is a rich source of such semi-comprehensible words, good for use as metasyntactic tokens. So all told, English is particularly prone to have seeming nonsense words enter common use and people *apply* one or more meanings; the metasyntactic usage is thus undermined. So it goes. > Aside from such boring ones as "do_work" and similar, the only > placeholder verb I can think of is frobnicate. > > Does anyone else have any? I tend to riff on Latinate word constructions in the same vein as “frobnicate”. I also try to channel The Goon Show when I need a metasyntactic word. Some recent ones include “spunge”, “nardle”, “crun”, etc. -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\ Brain, but where are we going to find a duck and a hose at this | _o__)hour?” —_Pinky and The Brain_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Why an object changes its "address" between adjacent calls?
Jim Lee at 2018/6/17 PM 04:10 wrote:
On 06/17/2018 12:08 AM, Jach Fong wrote:
C:\Python34\Doc>py
Python 3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 19:28:18) [MSC v.1600
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter as tk
>>> root = tk.Tk()
>>> tk.Label(root, text='label one', font='TkDefaultFont').pack()
>>> from tkinter import font
>>> font.nametofont('TkDefaultFont')
>>> font.nametofont('TkDefaultFont')
>>>
The "address" of the Font object 'TkDefaultFont' changes, why?
Best Regards,
Jach Fong
def nametofont(name):
"""Given the name of a tk named font, returns a Font representation.
"""
return Font(name=name, exists=True)
Every time you call nametofont(), you're creating a new instance of the
Font class.
hmm... It means every time I set a widget's font to
"TkDefaultFont", a new object was created. Why python do things this
way? Can't it use
this same object again and again?
--Jach
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
https://mail.python.org/mailman/listinfo/python-list
Re: Understanding memory location of Python variables
On Sun, Jun 17, 2018 at 8:01 PM, Bart wrote: > On 17/06/2018 03:28, Grant Edwards wrote: >> >> On 2018-06-16, ip.b...@gmail.com wrote: >> >>> I'm intrigued by the output of the following code, which was totally >>> contrary to my expectations. Can someone tell me what is happening? >>> >> myName = "Kevin" >> id(myName) >>> >>> 47406848 >> >> id(myName[0]) >>> >>> 36308576 >> >> id(myName[1]) >>> >>> 2476000 >> >> >> What's happening is that you're paying attention to the values >> returned by id(), when you should not. The fact that CPython returns >> a VM address when you call id() is just an "accident" of that >> particular implimentation. You shouldn't assume that id() returns >> anything other than a number that is unique to each object. Any time >> you spend worrying about how that number is calculated is proably >> wasted. >> >>> I expected myName[0] to be located at the same memory location as the >>> myName variable itself. >> >> >> Python is not C. >> >>> I also expected myName[1] to be located immediately after myName[0]. >> >> >> Python is not C. >> >> Just in case you missed that... >> >> Python is not C. >> > > So, how /do/ you obtain the memory address of those values are located? For > example, in order to pass it to some foreign C function that takes a void* > parameter. For strings? You don't. > I assume there is a memory address at least for the "Kevin" value, as the > other two might yield temporary objects for "K" and "e" rather the in-place > strings which are the first and second characters of the name. > You assume wrong. Now, if you're talking about a data type that DOES have a concrete in-memory representation (such as memoryview), then the answer may be different. But in Python, no, you cannot find out where the data is located, because it quite probably isn't stored in any way that would be useful to you. If you're implementing a function *in C* that needs to accept a Python string as a parameter, you can take that string object and say "hey Python, can you give me a UTF-8 buffer with the contents of this string pls thx?", and you'll get one. But that's a conversion - albeit one that may be cached. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why an object changes its "address" between adjacent calls?
On Sun, Jun 17, 2018 at 7:39 PM, sa...@caprilion.com.tw
wrote:
> Jim Lee at 2018/6/17 PM 04:10 wrote:
>>
>>
>>
>> On 06/17/2018 12:08 AM, Jach Fong wrote:
>>>
>>> C:\Python34\Doc>py
>>> Python 3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 19:28:18) [MSC v.1600 32
>>> bit (Intel)] on win32
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import tkinter as tk
>>> >>> root = tk.Tk()
>>> >>> tk.Label(root, text='label one', font='TkDefaultFont').pack()
>>> >>> from tkinter import font
>>> >>> font.nametofont('TkDefaultFont')
>>>
>>> >>> font.nametofont('TkDefaultFont')
>>>
>>> >>>
>>>
>>> The "address" of the Font object 'TkDefaultFont' changes, why?
>>>
>>> Best Regards,
>>> Jach Fong
>>>
>>>
>>
>> def nametofont(name):
>> """Given the name of a tk named font, returns a Font representation.
>> """
>> return Font(name=name, exists=True)
>>
>> Every time you call nametofont(), you're creating a new instance of the
>> Font class.
>
>
> hmm... It means every time I set a widget's font to "TkDefaultFont", a
> new object was created. Why python do things this way? Can't it use
> this same object again and again?
>
That would imply keeping the object around until it's needed again.
Sometimes that's worth doing; other times it isn't, or isn't worth the
hassle. As soon as you stop using the previous one, Python is free to
dispose of it.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Understanding memory location of Python variables
On Sun, 17 Jun 2018 11:01:41 +0100, Bart wrote: > So, how /do/ you obtain the memory address of those values are located? You don't. There is no implementation-independent Python function to get the memory address of an object. The concept of a fixed memory address for objects is not even a sensible one. In Python, all objects conceptually live in the heap, but there is no concept that they must have a fixed address, or any address at all. Depending on the memory management used by the Python virtual machine, the objects can move about as needed to free up blocks of unused memory. That's what IronPython and Jython do. Or, they could be like PyPy, where objects can conceptually disappear from existence and reappear when you look for them, a bit like quantum mechanics. PyPy can replace objects with low-level native data structures like ints, perform a bunch of calculations, and then recreate any needed objects. So long as none of this has any visible semantic differences from CPython (it is allowed to be faster :-) the PyPy interpreter is allowed to do almost anything it likes: move objects, destroy them and reallocate them, convert them to native data and back, push them onto the call stack, whatever it takes. > For example, in order to pass it to some foreign C function that > takes a void* parameter. That's up to the implementation. Jython and IronPython have little or no facility for calling C functions, hardly surprising since they are built on the JVM and .Net framework respectively. In CPython, there is probably a ctypes interface to do this, but ctypes is implementation-dependent and not portable (PyPy supports it, but other implementations probably won't). https://docs.python.org/3/library/ctypes.html Or you can use the CPython C API to write an extension class. https://docs.python.org/3/c-api/index.html -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Why an object changes its "address" between adjacent calls?
On Sun, 17 Jun 2018 17:39:42 +0800, sa...@caprilion.com.tw wrote:
[...]
>> Every time you call nametofont(), you're creating a new instance of the
>> Font class.
>
> hmm... It means every time I set a widget's font to
> "TkDefaultFont", a new object was created.
Correct.
> Why python do things this way? Can't it use
> this same object again and again?
So if you create a font object, and then delete it, do you expect the
interpreter to secretly hold onto that object forever just in case you
need it again? If Python did that for everything, you would quickly run
out of memory.
The Python interpreter may cache certain objects. CPython caches some
integers and small strings that look like they could be identifiers. PyPy
caches floats. Other implementations may or may not cache anything.
The interpreter may re-use immutable objects if doing so is a pure
optimization with no effect on semantics, but it is unpredictable when it
does this unless you study the interpreter source code.
But caching *everything* would be a terrible idea. You cannot cache or re-
use mutable objects like lists and dicts, and in general the interpreter
cannot know which objects are immutable or not.
So don't expect Python to magically optimize the number of objects you
create. If you want to use the same object over and over again, use the
same object, don't create a new one:
# creates multiple font objects
from tkinter import font
a = font.nametofont('TkDefaultFont')
b = font.nametofont('TkDefaultFont')
# creates only one font object
from tkinter import font
a = font.nametofont('TkDefaultFont')
b = a
You can write your own cache function like this:
_fontcache = {}
def cached_font(name):
try:
return _fontcache[name]
except KeyError:
obj = font.nametofont(name)
_fontcache[name] = obj
return obj
Or this might be better:
https://docs.python.org/3/library/functools.html#functools.lru_cache
But 95% of the time, the right answer is, don't worry about it.
Memory is cheap, and chances are that you won't even notice that you
saved a few bytes by using a cache. Sometimes, the extra time and memory
used by the cache code will be greater than the memory you save.
Python is designed to be used when memory is cheap, programmer's time is
expensive, and it is better to throw extra memory at a problem than to
try to solve it in the smallest amount of memory possible. If you think
about programming in terms of saving bytes, you will probably hate
Python. If you remember than even a cheap, bottom of the range computer
these days has approximately two BILLION bytes of memory, and most
machines have much more than that, you won't stress so much about reusing
objects.
The Rules of Optimization are simple. Rule 1: Don’t do it.
Rule 2 (for experts only): Don’t do it yet.
-- Michael A. Jackson, "Principles of Program Design"
--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why an object changes its "address" between adjacent calls?
Steven D'Aprano at 2018/6/17 PM 04:19 wrote: On Sun, 17 Jun 2018 15:08:27 +0800, Jach Fong wrote: The "address" of the Font object 'TkDefaultFont' changes, why? Its not an address, it is an ID number. The ID number changes because you get a different object each time you call the function. Thanks for remind me again. I had read the subject "Understanding memory location of Python variables" recently in the forum and noticed that ID is implementation dependent, not necessary an "address". Just didn't get rid of my old habit:-) --Jach --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- https://mail.python.org/mailman/listinfo/python-list
Re: Understanding memory location of Python variables
Bart : > So, how /do/ you obtain the memory address of those values are > located? For example, in order to pass it to some foreign C function > that takes a void* parameter. That is dependent on the Python implementation. CPython supports native C and C++ extensions: https://docs.python.org/3/extending/index.html> Here's the C API for extracting data out of strings: https://docs.python.org/3/c-api/unicode.html#unicode-objects> Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Sunday, 17 June 2018 11:00:50 UTC+5:30, Ben Finney wrote: > Sharan Basappa writes: > > > I think I am now confused with format options in Python. > > You should refer to the documentation for string formatting > https://docs.python.org/3/library/stdtypes.html#str.format> > https://docs.python.org/3/library/string.html#formatstrings> > > (or, if you want to continue with the older less-flexible style, > ) > > > I tried an example as below and both print proper value: > > > > age = 35 > > > > print "age is %s" % age > > The ‘s’ format specifier says “Ask the object for its text > representation, and put that text here”. > > Every object has a text representation, so ‘s’ works with any object. > > > print "age is %d" % age > > The ‘d’ format specifier says “Format the integer as a decimal text > representation, and put that text here”. > > Only objects that are integers (or that implement the format-as-decimal > API) will work with ‘d’. > > > I other languages I know the format specifier should be same as the > > variable type. For example, in the above case, it has to be %d and not > > %s > > Because you are explicitly specifying which formatting to use, there's > no ambiguity. With an object that is an integer, either of the above > makes sense in different use cases. > > -- > \“A right is not what someone gives you; it's what no one can | > `\ take from you.” —Ramsey Clark | > _o__) | > Ben Finney Thanks a lot. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Sunday, 17 June 2018 11:42:03 UTC+5:30, Jim Lee wrote: > On 06/16/2018 10:13 PM, Sharan Basappa wrote: > > I think I am now confused with format options in Python. > > I tried an example as below and both print proper value: > > > > age = 35 > > > > print "age is %s" % age > > print "age is %d" % age > > > > %run "D:/Projects/Initiatives/machine learning/programs/six.py" > > age is 35 > > age is 35 > > > > I other languages I know the format specifier should be same as the > > variable type. For example, in the above case, it has to be %d and not %s > > Python is not like other languages. For one thing, there are no > "variables" in Python (in the way you think of them). There are only > objects and names. Names can be thought of like void pointers in C, for > example. They don't have a "type" themselves - they only refer to > objects, and the type of object they refer to can change at will. Also, > there are no integers in Python. Scalar values are actually objects. > The number 35 is not an integer, it is an object that has an integer > type. If you do a "dir(35)" in Python, you'll see that the object "35" > has more than 70 methods associated with it. I'll stop there to avoid > information overload, but these are some of the key things a Python > newcomer needs to wrap their head around > > -Jim Jim, thanks a lot. Somehow, not one book I referred to brought out very clearly that everything in Python is an object including basic data types. Probably, they did and not so explicitly. -- https://mail.python.org/mailman/listinfo/python-list
Re: For specific keys , extract non empty values in a dictionary
> >>> {k: o_num[k] for k in wanted & o_num.keys() if o_num[k] is not None}
Thanks peter this looks better , except that I will need to use the
logial 'and' operator or else I will get a TypeError
>>> {k: o_num[k] for k in wanted & o_num.keys() if o_num[k] is not None}
TypeError: unsupported operand type(s) for &: 'set' and 'list'
Example :
>>>print {k: o_num[k] for k in wanted and o_num.keys() if o_num[k] is not
None}
{'nine': 9, 'five': 5, 'three': 3, 'one': 1}
On Sat, Jun 16, 2018 at 11:12 PM, Peter Otten <__pete...@web.de> wrote:
> Ganesh Pal wrote:
>
> > *How do I check few specific/selected keys in a dictionary and extract
> > their values if they are not empty*
>
> You mean not None.
>
> > o_num = {'one': 1,
> > 'three': 3,
> > 'bar': None,
> > 'five' : 5,
> > 'rum' : None,
> > 'seven' : None,
> > 'brandy': None,
> > 'nine' : 9,
> > 'gin': None}
>
> > args_list = ["one","three","seven","nine"]
>
> > *Output:*
> >
> > *1 3 9*
>
> >>> wanted = {"one", "three", "seven", "nine"}
> >>> {k: o_num[k] for k in wanted & o_num.keys() if o_num[k] is not None}
> {'one': 1, 'nine': 9, 'three': 3}
>
> > I am a Python 2.7 user and on Linux box
>
> You have to replace keys() with viewkeys() in Python 2.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 17/06/2018 09:43, Steven D'Aprano wrote: On Sat, 16 Jun 2018 23:11:41 -0700, Jim Lee wrote: Python is not like other languages. Python is not like languages like C, Pascal, Algol, Fortran, D, Java (unboxed native values only) and those like that. However, Python *is* like other languages like Javascript, Ruby, Java (objects only), PHP, and others. For one thing, there are no "variables" in Python (in the way you think of them). Indeed -- there are no variables in Python, if you think of a variable as meaning a virtual box at a fixed memory address, containing a value, and associated with a type, like in C or Pascal. So what's a Type Hint associated with in Python? -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: For specific keys , extract non empty values in a dictionary
On 2018-06-17 15:47, Ganesh Pal wrote:
>>> {k: o_num[k] for k in wanted & o_num.keys() if o_num[k] is not None}
Thanks peter this looks better , except that I will need to use the
logial 'and' operator or else I will get a TypeError
{k: o_num[k] for k in wanted & o_num.keys() if o_num[k] is not None}
TypeError: unsupported operand type(s) for &: 'set' and 'list'
Peter said that you need to use viewkeys() instead of keys() in Python 2:
>>> {k: o_num[k] for k in wanted & o_num.viewkeys() if o_num[k] is not
None}
Using 'and' instead won't give the correct result.
Example :
print {k: o_num[k] for k in wanted and o_num.keys() if o_num[k] is not
None}
{'nine': 9, 'five': 5, 'three': 3, 'one': 1}
On Sat, Jun 16, 2018 at 11:12 PM, Peter Otten <__pete...@web.de> wrote:
Ganesh Pal wrote:
> *How do I check few specific/selected keys in a dictionary and extract
> their values if they are not empty*
You mean not None.
> o_num = {'one': 1,
> 'three': 3,
> 'bar': None,
> 'five' : 5,
> 'rum' : None,
> 'seven' : None,
> 'brandy': None,
> 'nine' : 9,
> 'gin': None}
> args_list = ["one","three","seven","nine"]
> *Output:*
>
> *1 3 9*
>>> wanted = {"one", "three", "seven", "nine"}
>>> {k: o_num[k] for k in wanted & o_num.keys() if o_num[k] is not None}
{'one': 1, 'nine': 9, 'three': 3}
> I am a Python 2.7 user and on Linux box
You have to replace keys() with viewkeys() in Python 2.
--
https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Sun, 17 Jun 2018 17:19:38 +0100, Bart wrote:
>> Indeed -- there are no variables in Python, if you think of a variable
>> as meaning a virtual box at a fixed memory address, containing a value,
>> and associated with a type, like in C or Pascal.
>
> So what's a Type Hint associated with in Python?
By the interpreter itself? Pretty much nothing at all. Aside from
recording the annotation in the function object, the interpreter
completely ignores it.
py> def func(x: float) -> list:
... pass
...
py> func.__annotations__
{'x': , 'return': }
(Aside: in more recent versions of Python, the annotations are treated as
strings, not objects, and you will get {'x': 'float', 'return': 'list'}
instead.)
Since it is a type *hint*, not a type *declaration*, the interpreter can
and does ignore it. It makes no change at all to the execution model of
the language.
But the human reader, linters, IDEs and editors can associate it with the
name it annotates, and use it as a hint as to what is intended to happen,
and flag any discrepancies.
--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson
--
https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
Chris Angelico wrote: [...] > For the record, there's nothing at all wrong with printf-style > formatting; its flexibility and brevity make it extremely useful in > many situations. Except that it's old, not elegant, error prone, feature poor, and not Pythonic! But besides all _that_ (and possibly more) it's slightly amusing, i suppose. Cling to the past much? What's wrong Chris, is the syntax of the new format method too difficult for you? Or do you have a personal disliking for anything OOP? Personally, i would suggest the OP should learn the new Python formatting methods and disregard the legacy printf style crap that has been copy/pasted from countless other languages. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
Steven D'Aprano wrote: > Bart Wrote: > > So what's a Type Hint associated with in Python? > Since it is a type *hint*, not a type *declaration*, the > interpreter can and does ignore it. But yet, the _programmer_ cannot ignore it. Does that make any sense to you, or anyone else with half a brain? > It makes no change at all to the execution model of the > language. Then why the *HELL* are type-hints an official part of the Python language syntax? Had type hints been implemented as comments (for instance: a special class of comment in the same way that doc-strings are a special class of strings), then a programmer could ignore them! Heck, i have even have a feature in my editor that will hide all comments and doc- strings! And the code to perform this task is fairly simple. But it's gonna one hell of a _nightmare_ to remove type- hints from source code when they are _interleaved_ with the damn source code, and considered by the interpreter to be syntax. > But the human reader, linters, IDEs and editors can > associate it with the name it annotates, and use it as a > hint as to what is intended to happen, and flag any > discrepancies. And each of these could have done the same with a "type-hint comment". But oh no, that would be too easy! And the whole point here is to cause a big fat ruckus? Isn't it, Mr. D'Aprano? -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 06/17/2018 11:10 AM, Rick Johnson wrote: Steven D'Aprano wrote: Bart Wrote: So what's a Type Hint associated with in Python? Since it is a type *hint*, not a type *declaration*, the interpreter can and does ignore it. But yet, the _programmer_ cannot ignore it. Does that make any sense to you, or anyone else with half a brain? It makes no change at all to the execution model of the language. Then why the *HELL* are type-hints an official part of the Python language syntax? Had type hints been implemented as comments (for instance: a special class of comment in the same way that doc-strings are a special class of strings), then a programmer could ignore them! Heck, i have even have a feature in my editor that will hide all comments and doc- strings! And the code to perform this task is fairly simple. But it's gonna one hell of a _nightmare_ to remove type- hints from source code when they are _interleaved_ with the damn source code, and considered by the interpreter to be syntax. But the human reader, linters, IDEs and editors can associate it with the name it annotates, and use it as a hint as to what is intended to happen, and flag any discrepancies. And each of these could have done the same with a "type-hint comment". But oh no, that would be too easy! And the whole point here is to cause a big fat ruckus? Isn't it, Mr. D'Aprano? IMHO, trying to shoehorn static type checking on top of a dynamically typed language shows that the wrong language was chosen for the job. -Jim -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Mon, Jun 18, 2018 at 3:52 AM, Rick Johnson wrote: > Chris Angelico wrote: > [...] >> For the record, there's nothing at all wrong with printf-style >> formatting; its flexibility and brevity make it extremely useful in >> many situations. > > Except that it's old, not elegant, error prone, feature poor, and not > Pythonic! [citation needed] > But besides all _that_ (and possibly more) it's slightly amusing, i suppose. > > Cling to the past much? > > What's wrong Chris, is the syntax of the new format method too difficult for > you? Or do you have a personal disliking for anything OOP? What does "OOP" mean, exactly? Operators aren't, methods are? > Personally, i would suggest the OP should learn the new Python formatting > methods and disregard the legacy printf style crap that has been copy/pasted > from countless other languages. > And that's the exact same FUD. Thank you for proving that a known troll supports the FUD, which is a strong indication that it should be ignored. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
Jim Lee : > IMHO, trying to shoehorn static type checking on top of a dynamically > typed language shows that the wrong language was chosen for the job. I'm also saddened by the type hinting initiative. When you try to be best for everybody, you end up being best for nobody. The niche Python has successfully occupied is huge. Why risk it all by trying to take the whole cake? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Mon, Jun 18, 2018 at 4:10 AM, Rick Johnson wrote: > Steven D'Aprano wrote: >> Bart Wrote: >> > So what's a Type Hint associated with in Python? >> Since it is a type *hint*, not a type *declaration*, the >> interpreter can and does ignore it. > > But yet, the _programmer_ cannot ignore it. Does that make > any sense to you, or anyone else with half a brain? You're absolutely right. We should eliminate the 'assert' keyword (since the interpreter can and does ignore assertions in optimized mode), comments, and blank lines. Anyone with half a brain will see at once that they should obviously be removed. Anyone with an entire brain, of course, will appreciate them. >> It makes no change at all to the execution model of the >> language. > > Then why the *HELL* are type-hints an official part of the > Python language syntax? Had type hints been implemented as > comments (for instance: a special class of comment in the > same way that doc-strings are a special class of strings), > then a programmer could ignore them! Huh. Funny you should say that. https://www.python.org/dev/peps/pep-0484/#type-comments ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa wrote: > Jim Lee : >> IMHO, trying to shoehorn static type checking on top of a dynamically >> typed language shows that the wrong language was chosen for the job. > > I'm also saddened by the type hinting initiative. When you try to be > best for everybody, you end up being best for nobody. The niche Python > has successfully occupied is huge. Why risk it all by trying to take the > whole cake? Did you complain when function annotations were introduced back in 2006? https://www.python.org/dev/peps/pep-3107/ That's TWELVE YEARS ago. Over in the Node.js world, that's ... uhh, actually that's longer ago than Node.js has even been around. Another trendy language is Go... oh wait, that wasn't around in 2006 either. Type annotations have been in Python for nearly twelve years; ten if you count the actual release of Python 3.0. The thing that changed more recently was that *non-type* annotations were deprecated, since very few use-cases were found. When did the shoehorning happen, exactly? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 06/17/2018 01:35 PM, Chris Angelico wrote: On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa wrote: Jim Lee : IMHO, trying to shoehorn static type checking on top of a dynamically typed language shows that the wrong language was chosen for the job. I'm also saddened by the type hinting initiative. When you try to be best for everybody, you end up being best for nobody. The niche Python has successfully occupied is huge. Why risk it all by trying to take the whole cake? Did you complain when function annotations were introduced back in 2006? https://www.python.org/dev/peps/pep-3107/ That's TWELVE YEARS ago. Over in the Node.js world, that's ... uhh, actually that's longer ago than Node.js has even been around. Another trendy language is Go... oh wait, that wasn't around in 2006 either. Type annotations have been in Python for nearly twelve years; ten if you count the actual release of Python 3.0. The thing that changed more recently was that *non-type* annotations were deprecated, since very few use-cases were found. When did the shoehorning happen, exactly? ChrisA What does time have to do with anything? I wasn't using Python in 2006. A bad idea is a bad idea, regardless of *when* it was conceived. -Jim -Jim -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
Chris Angelico : > On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa wrote: >> I'm also saddened by the type hinting initiative. When you try to be >> best for everybody, you end up being best for nobody. The niche Python >> has successfully occupied is huge. Why risk it all by trying to take the >> whole cake? > > Did you complain when function annotations were introduced back in 2006? No. I have yet to see them in the wild. I hope never to see them. Do you mean you must like them by now? > That's TWELVE YEARS ago. Over in the Node.js world, that's ... uhh, > actually that's longer ago than Node.js has even been around. Another > trendy language is Go... oh wait, that wasn't around in 2006 either. What are you talking about? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Mon, Jun 18, 2018 at 6:50 AM, Jim Lee wrote: > > > On 06/17/2018 01:35 PM, Chris Angelico wrote: >> >> On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa wrote: >>> >>> Jim Lee : IMHO, trying to shoehorn static type checking on top of a dynamically typed language shows that the wrong language was chosen for the job. >>> >>> I'm also saddened by the type hinting initiative. When you try to be >>> best for everybody, you end up being best for nobody. The niche Python >>> has successfully occupied is huge. Why risk it all by trying to take the >>> whole cake? >> >> Did you complain when function annotations were introduced back in 2006? >> >> https://www.python.org/dev/peps/pep-3107/ >> >> That's TWELVE YEARS ago. Over in the Node.js world, that's ... uhh, >> actually that's longer ago than Node.js has even been around. Another >> trendy language is Go... oh wait, that wasn't around in 2006 either. >> >> Type annotations have been in Python for nearly twelve years; ten if >> you count the actual release of Python 3.0. The thing that changed >> more recently was that *non-type* annotations were deprecated, since >> very few use-cases were found. When did the shoehorning happen, >> exactly? >> >> ChrisA > > What does time have to do with anything? I wasn't using Python in 2006. A > bad idea is a bad idea, regardless of *when* it was conceived. > You talk about "risk it all by trying to take the whole cake" as if annotations are a change. But if they were already around before you first met the language, then they're just part of the language. You might as well argue against the += operator or list comprehensions. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Sun, Jun 17, 2018 at 1:23 PM, Marko Rauhamaa wrote: > Jim Lee : > > IMHO, trying to shoehorn static type checking on top of a dynamically > > typed language shows that the wrong language was chosen for the job. > > I'm also saddened by the type hinting initiative. When you try to be > best for everybody, you end up being best for nobody. The niche Python > has successfully occupied is huge. Why risk it all by trying to take the > whole cake? I actually really like Python's type hinting, which I've recently started using. I've now used it on 10 projects, and I imagine I'll be using it in many more. Don't like them? I guess you don't have to use them. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 06/17/2018 01:56 PM, Chris Angelico wrote: On Mon, Jun 18, 2018 at 6:50 AM, Jim Lee wrote: On 06/17/2018 01:35 PM, Chris Angelico wrote: On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa wrote: Jim Lee : IMHO, trying to shoehorn static type checking on top of a dynamically typed language shows that the wrong language was chosen for the job. I'm also saddened by the type hinting initiative. When you try to be best for everybody, you end up being best for nobody. The niche Python has successfully occupied is huge. Why risk it all by trying to take the whole cake? Did you complain when function annotations were introduced back in 2006? https://www.python.org/dev/peps/pep-3107/ That's TWELVE YEARS ago. Over in the Node.js world, that's ... uhh, actually that's longer ago than Node.js has even been around. Another trendy language is Go... oh wait, that wasn't around in 2006 either. Type annotations have been in Python for nearly twelve years; ten if you count the actual release of Python 3.0. The thing that changed more recently was that *non-type* annotations were deprecated, since very few use-cases were found. When did the shoehorning happen, exactly? ChrisA What does time have to do with anything? I wasn't using Python in 2006. A bad idea is a bad idea, regardless of *when* it was conceived. You talk about "risk it all by trying to take the whole cake" as if annotations are a change. But if they were already around before you first met the language, then they're just part of the language. You might as well argue against the += operator or list comprehensions. ChrisA You seem to have lost the attribution to those comments in your reply. I wasn't the one who talked about "risk it all by trying to take the whole cake". -Jim -- https://mail.python.org/mailman/listinfo/python-list
Re: Understanding memory location of Python variables
On Sun, Jun 17, 2018 at 5:05 AM, Marko Rauhamaa wrote: > Bart : > > So, how /do/ you obtain the memory address of those values are > > located? For example, in order to pass it to some foreign C function > > that takes a void* parameter. > > That is dependent on the Python implementation. CPython supports native > C and C++ extensions: > >https://docs.python.org/3/extending/index.html> > > Here's the C API for extracting data out of strings: > >https://docs.python.org/3/c-api/unicode.html#unicode-objects> > I'd actually recommend, in order from greatest preference to least: 1) Cython (but probably only for CPython) 2) CFFI (for CPython and Pypy, but perhaps not for others) 3) ctypes (but only for quick little projects with CPython or PyPy) 4) The new stable C extension type ABI (for CPython... and PyPy?) 5) The old, common C extension type ABI (for CPython, and if you don't get too fancy, for PyPy) Cython is almost like Python, except it allows you to intermix C and Python datatypes. And it gets a lot of the silly fiddly bits right, so you don't have to. But you can still do byte-level stuff with it, if you actually need to. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Mon, Jun 18, 2018 at 7:10 AM, Jim Lee wrote: > > > On 06/17/2018 01:56 PM, Chris Angelico wrote: >> >> On Mon, Jun 18, 2018 at 6:50 AM, Jim Lee wrote: >>> >>> >>> On 06/17/2018 01:35 PM, Chris Angelico wrote: On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa wrote: > > Jim Lee : >> >> IMHO, trying to shoehorn static type checking on top of a dynamically >> typed language shows that the wrong language was chosen for the job. > > I'm also saddened by the type hinting initiative. When you try to be > best for everybody, you end up being best for nobody. The niche Python > has successfully occupied is huge. Why risk it all by trying to take > the > whole cake? Did you complain when function annotations were introduced back in 2006? https://www.python.org/dev/peps/pep-3107/ That's TWELVE YEARS ago. Over in the Node.js world, that's ... uhh, actually that's longer ago than Node.js has even been around. Another trendy language is Go... oh wait, that wasn't around in 2006 either. Type annotations have been in Python for nearly twelve years; ten if you count the actual release of Python 3.0. The thing that changed more recently was that *non-type* annotations were deprecated, since very few use-cases were found. When did the shoehorning happen, exactly? ChrisA >>> >>> What does time have to do with anything? I wasn't using Python in 2006. >>> A >>> bad idea is a bad idea, regardless of *when* it was conceived. >>> >> You talk about "risk it all by trying to take the whole cake" as if >> annotations are a change. But if they were already around before you >> first met the language, then they're just part of the language. You >> might as well argue against the += operator or list comprehensions. >> >> ChrisA > > You seem to have lost the attribution to those comments in your reply. I > wasn't the one who talked about > > "risk it all by trying to take the whole cake". > My apologies, stuff wrapped and I misread as I skimmed back. You were the one who used the word "shoehorned". In the same way, that sounds like you already knew the language, and then someone added extra features that don't fit. It's not shoehorning if the feature was already there before you met the language. The point is the same, the citation incorrect. Mea culpa. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
Dan Stromberg : > On Sun, Jun 17, 2018 at 1:23 PM, Marko Rauhamaa wrote: >> I'm also saddened by the type hinting initiative. When you try to be >> best for everybody, you end up being best for nobody. The niche >> Python has successfully occupied is huge. Why risk it all by trying >> to take the whole cake? > > I actually really like Python's type hinting, which I've recently started > using. I've now used it on 10 projects, and I imagine I'll be using it in > many more. > > Don't like them? I guess you don't have to use them. I that were true, fine. I'm most afraid of it becoming an all-encompassing fad that can't be avoided. So far so good. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: For specific keys , extract non empty values in a dictionary
Dennis Lee Bieber wrote:
> On Sun, 17 Jun 2018 17:37:25 +0100, MRAB
> declaimed the following:
>
>>On 2018-06-17 15:47, Ganesh Pal wrote:
>>> {k: o_num[k] for k in wanted & o_num.keys() if o_num[k] is not
>>> {None}
>>>
>>> Thanks peter this looks better , except that I will need to use the
>>> logial 'and' operator or else I will get a TypeError
>>>
>> {k: o_num[k] for k in wanted & o_num.keys() if o_num[k] is not None}
>>>
>>> TypeError: unsupported operand type(s) for &: 'set' and 'list'
>>>
>>Peter said that you need to use viewkeys() instead of keys() in Python 2:
>>
>> >>> {k: o_num[k] for k in wanted & o_num.viewkeys() if o_num[k] is not
>>None}
>>
>
> What's wrong with the simple
>
o_num = { "one" : 1,
> ... "three" : 3,
> ... "bar" : None,
> ... "five" : 5,
> ... "rum" : None,
> ... "seven" : None,
> ... "brandy" : None,
> ... "nine" : 9,
> ... "gin" : None}
args_list = [ "one", "three", "seven", "nine" ]
{ k : o_num[k] for k in args_list if o_num.get(k, None) is not None }
> {'nine': 9, 'three': 3, 'one': 1}
It's hidden here because of the removal of None values, but in the generic
case when you say
"give me all x in a that are also in b"
instead of
"give me the intersection of a and b"
you are overspecifying the problem.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Understanding memory location of Python variables
On Sat, 16 Jun 2018 09:38:07 -0700 (PDT), ip.b...@gmail.com wrote: > Hi everyone, > > I'm intrigued by the output of the following code, which was totally > contrary to my expectations. Can someone tell me what is happening? > myName = "Kevin" id(myName) > 47406848 id(myName[0]) > 36308576 id(myName[1]) > 2476000 You left out one of the more interesting (and possibly informative) angles: >>> myName = "Kevin" >>> x0 = myName[0] >>> x1 = myName[1] >>> x01 = myName[0:2] >>> y0 = "K" >>> y1 = "e" >>> y01 = "Ke" >>> id(x0) == id(y0) True >>> id(x1) == id(y1) True >>> id(x01) == id(y01) False >>> x01 == y01 True myName[0] is the string "K", and this Python implementation happens to economize by having only a single object "K". This economy measure probably only applies to single-character strings. -- To email me, substitute nowhere->runbox, invalid->com. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 17Jun2018 11:10, Rick Johnson wrote: Steven D'Aprano wrote: But the human reader, linters, IDEs and editors can associate it with the name it annotates, and use it as a hint as to what is intended to happen, and flag any discrepancies. And each of these could have done the same with a "type-hint comment". But oh no, that would be too easy! And the whole point here is to cause a big fat ruckus? Isn't it, Mr. D'Aprano? No, it is so that there can be an agreed syntax for this stuff rather than a billion funky special comments, and also so that _compiled_ python can be inspected for type hints because they survive that step. This makes for machine inspectable hints very easily, and that is a boon for linters. Another advantage of type hints being part of the syntax is that invalid/mistyped type hints can be caught by the parser. If they're just special comments then linters _might_ see them and complain, or equally they might say "this comment isn't a valid type hint, so it is an ordinary comment", silently ignoring it. Thus weakening the lint. As for the runtime ignoring them: they can't accomodate all situations in a dynamic language, and type checking would impose a performance penalty for no semantic effect. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Sunday, June 17, 2018 at 2:07:40 PM UTC-5, Jim Lee wrote: > IMHO, trying to shoehorn static type checking on top of a dynamically > typed language shows that the wrong language was chosen for the job. Exactly. I'm not against the idea of Python growing a new feature. Features are great. My objection is concerned merely with the "how" it is implemented, not the "why" it was implemented. "Type-hint comments" would allow: (1) those who need them, to use them. (2) those who don't care about them, to totally ignore them. (3) and those who utterly *HATE* them, to write a simply little function which will strip them from any and all source code they might be forced to maintain. Personally, i would never put type-hints in my Python code. I write a large portion of my overall code in Python specifically because i do not wish to be distracted by type declarations. Of course, regardless of how much i try to avoid type-hints, the problem will come, when one day in the future, i am forced to maintain another Python programmer's code that is littered with these declarations. And removing them won't be easy. But that's the real danger of this feature. The Python community will not see the real effect of type-hints (at least, as they are currently implemented) for a long time. But as more and more type-hints are spread in the wild, more and more people, and more and more organizations, are going to look for "cleaner language" to solve their R&D and general purpose high-level problems. What's the point of eye-ball-parsing through miles of type- hints which demand all the burdens of static typing whilst giving none of the real benefits. The Python interpreter ignores these hints. But as programmers -- as, human beings, and not machines! -- ignoring the syntactical noise of type- hints will be impossible. So either the Python devs need to release a "3ToTypeHintFree.py", or they need to re-implement this so- called feature as a special class of comment. And here is an example of how that might be done, using Steven's example from above: ## Steven's Example ## #(Current implementation of type-hints) py> def func(x: float) -> list: """Ello, ime-uh lit-al doc-string, yes i am.""" ... pass ## Prposed solution v1 ## py> def func(x): """Ello, ime-uh lit-al doc-string, yes i am.""" # x:float -> list ... pass -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Sunday, June 17, 2018 at 3:58:26 PM UTC-5, Dan Stromberg wrote: [...] > I actually really like Python's type hinting, which I've recently started > using. I've now used it on 10 projects, and I imagine I'll be using it in > many more. > > Don't like them? I guess you don't have to use them. Go ahead an be cocky if you want to. But just remember this: People like myself will outright refuse to maintain your code. And do you know what that means Dan? It means your code will _die_! And then we will get paid to rewrite your code. Code that will be far more maintainable than the syntactical mess you wrote. And if we want static typing -- no problem! -- we'll convince out clients to switch to a language that has *REAL* static typing. Okay? Howdya like that? (shills gonna do what shills gonna do, i guess @_@) -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Sunday, June 17, 2018 at 4:17:33 PM UTC-5, Chris Angelico wrote: > On Mon, Jun 18, 2018 at 7:10 AM, Jim Lee wrote: > > > > > > On 06/17/2018 01:56 PM, Chris Angelico wrote: > >> > >> On Mon, Jun 18, 2018 at 6:50 AM, Jim Lee wrote: > >>> > >>> > >>> On 06/17/2018 01:35 PM, Chris Angelico wrote: > > On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa > wrote: > > > > Jim Lee : > >> > >> IMHO, trying to shoehorn static type checking on top of a dynamically > >> typed language shows that the wrong language was chosen for the job. > > > > I'm also saddened by the type hinting initiative. When you try to be > > best for everybody, you end up being best for nobody. The niche Python > > has successfully occupied is huge. Why risk it all by trying to take > > the > > whole cake? > > Did you complain when function annotations were introduced back in 2006? > > https://www.python.org/dev/peps/pep-3107/ > > That's TWELVE YEARS ago. Over in the Node.js world, that's ... uhh, > actually that's longer ago than Node.js has even been around. Another > trendy language is Go... oh wait, that wasn't around in 2006 either. > > Type annotations have been in Python for nearly twelve years; ten if > you count the actual release of Python 3.0. The thing that changed > more recently was that *non-type* annotations were deprecated, since > very few use-cases were found. When did the shoehorning happen, > exactly? > > ChrisA > >>> > >>> What does time have to do with anything? I wasn't using Python in 2006. > >>> A > >>> bad idea is a bad idea, regardless of *when* it was conceived. > >>> > >> You talk about "risk it all by trying to take the whole cake" as if > >> annotations are a change. But if they were already around before you > >> first met the language, then they're just part of the language. You > >> might as well argue against the += operator or list comprehensions. > >> > >> ChrisA > > > > You seem to have lost the attribution to those comments in your reply. I > > wasn't the one who talked about > > > > "risk it all by trying to take the whole cake". > > > > My apologies, stuff wrapped and I misread as I skimmed back. You were > the one who used the word "shoehorned". In the same way, that sounds > like you already knew the language, and then someone added extra > features that don't fit. It's not shoehorning if the feature was > already there before you met the language. Red herring! -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Mon, Jun 18, 2018 at 9:30 AM, Rick Johnson wrote: > On Sunday, June 17, 2018 at 2:07:40 PM UTC-5, Jim Lee wrote: > >> IMHO, trying to shoehorn static type checking on top of a dynamically >> typed language shows that the wrong language was chosen for the job. > > Exactly. > > I'm not against the idea of Python growing a new feature. > Features are great. My objection is concerned merely with > the "how" it is implemented, not the "why" it was > implemented. > > "Type-hint comments" would allow: > > (1) those who need them, to use them. > > (2) those who don't care about them, to totally ignore > them. > > (3) and those who utterly *HATE* them, to write a simply > little function which will strip them from any and all > source code they might be forced to maintain. A. Isn't it cute, how he thinks that comments are easier to remove than other elements equally well defined in the grammar? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 06/17/2018 02:17 PM, Chris Angelico wrote: [snip] My apologies, stuff wrapped and I misread as I skimmed back. You were the one who used the word "shoehorned". In the same way, that sounds like you already knew the language, and then someone added extra features that don't fit. It's not shoehorning if the feature was already there before you met the language. The point is the same, the citation incorrect. Mea culpa. ChrisA Of course it is "shoehorning". Why do you care when I started using the language? Shoehorning implies an attempt to add a feature that didn't exist in the original design - a feature that is a difficult, awkward, or ill-fitting complement to the original design. Whether it happened yesterday or 12 years ago is immaterial. When I personally met the language is also immaterial. Microsoft "shoehorned" a Linux subsystem into Windows. I don't even use Windows, yet by your logic, I can't call it "shoehorning". -Jim -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Mon, Jun 18, 2018 at 10:22 AM, Jim Lee wrote: > > > On 06/17/2018 02:17 PM, Chris Angelico wrote: >> >> [snip] >> My apologies, stuff wrapped and I misread as I skimmed back. You were >> the one who used the word "shoehorned". In the same way, that sounds >> like you already knew the language, and then someone added extra >> features that don't fit. It's not shoehorning if the feature was >> already there before you met the language. >> >> The point is the same, the citation incorrect. Mea culpa. >> >> ChrisA > > > Of course it is "shoehorning". Why do you care when I started using the > language? Shoehorning implies an attempt to add a feature that didn't exist > in the original design - a feature that is a difficult, awkward, or > ill-fitting complement to the original design. Whether it happened > yesterday or 12 years ago is immaterial. When I personally met the language > is also immaterial. > > Microsoft "shoehorned" a Linux subsystem into Windows. I don't even use > Windows, yet by your logic, I can't call it "shoehorning". Or maybe that's an indication of a change in design goals. Python's original goal was to be very similar to C, and thus had a lot of behaviours copied from C; up until Python 2.2, the default 'int' type would overflow if it exceeded a machine word. Were long integers shoehorned into the design, or does it indicate that the design was modified to welcome them? Personally, I think the Linux subsystem is (a) no different from (but converse to) Wine, and (b) a good stepping-stone towards a Windows release using a Unix kernel. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
Chris Angelico wrote: [...] > A. Isn't it cute, how he thinks that comments are easier to remove > than other elements equally well defined in the grammar? And may we see your code that will remove all instances of type-hints error free? Hmm? I look forward to scraping the internet for source code i can try it on, and then posting the tracebacks here for all to see. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Mon, Jun 18, 2018 at 12:12 PM, Rick Johnson wrote: > Chris Angelico wrote: > [...] >> A. Isn't it cute, how he thinks that comments are easier to remove >> than other elements equally well defined in the grammar? > > And may we see your code that will remove all instances of type-hints error > free? > > Hmm? > > I look forward to scraping the internet for source code i can try it on, and > then posting the tracebacks here for all to see. First, show me your perfect comment removal code. Don't forget to correctly handle different source code encodings, backslashes escaping newlines, and triple-quoted strings. Then if that is proven easy, I'll show you how a small tweak will remove any other syntactic element you like. And yes, I know exactly what tool I would use for the job. If I ever had to do something so stupid. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Sunday, June 17, 2018 at 9:22:57 PM UTC-5, Chris Angelico wrote: > First, No. You're not squirming your way out this one Chris. _You_ leveled the assertion that removing interleaved type- hints from the executable code would be easier than removing my proposed "type-hint comments". What was the quote??? Oh, i remember: "A. Isn't it cute, how he thinks that comments are easier to remove than other elements equally well defined in the grammar?" Now. Put up, or shut up. > [...] -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Mon, Jun 18, 2018 at 1:20 PM, Rick Johnson wrote: > On Sunday, June 17, 2018 at 9:22:57 PM UTC-5, Chris Angelico wrote: >> First, > > No. > > You're not squirming your way out this one Chris. > > _You_ leveled the assertion that removing interleaved type- > hints from the executable code would be easier than removing > my proposed "type-hint comments". > > What was the quote??? > > Oh, i remember: > > "A. Isn't it cute, how he thinks that comments are > easier to remove than other elements equally well defined > in the grammar?" > > Now. Put up, or shut up. What was the quote before that? > "Type-hint comments" would allow: > (3) and those who utterly *HATE* them, to write a simply > little function which will strip them from any and all > source code they might be forced to maintain. Put up or shut up. Write something that strips all type hint comments. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: XSD data mapper lib
Nagy László Zsolt writes: > I wonder what kind of XSD <-> Python class mapper should I use for my > project. I am using "PyXB" for this kind of tasks. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 06/17/2018 05:39 PM, Chris Angelico wrote: On Mon, Jun 18, 2018 at 10:22 AM, Jim Lee wrote: On 06/17/2018 02:17 PM, Chris Angelico wrote: [snip] My apologies, stuff wrapped and I misread as I skimmed back. You were the one who used the word "shoehorned". In the same way, that sounds like you already knew the language, and then someone added extra features that don't fit. It's not shoehorning if the feature was already there before you met the language. The point is the same, the citation incorrect. Mea culpa. ChrisA Of course it is "shoehorning". Why do you care when I started using the language? Shoehorning implies an attempt to add a feature that didn't exist in the original design - a feature that is a difficult, awkward, or ill-fitting complement to the original design. Whether it happened yesterday or 12 years ago is immaterial. When I personally met the language is also immaterial. Microsoft "shoehorned" a Linux subsystem into Windows. I don't even use Windows, yet by your logic, I can't call it "shoehorning". Or maybe that's an indication of a change in design goals. Python's original goal was to be very similar to C, and thus had a lot of behaviours copied from C; up until Python 2.2, the default 'int' type would overflow if it exceeded a machine word. Were long integers shoehorned into the design, or does it indicate that the design was modified to welcome them? Personally, I think the Linux subsystem is (a) no different from (but converse to) Wine, and (b) a good stepping-stone towards a Windows release using a Unix kernel. ChrisA I say: "frobnitz was broken". You say: "you can't call frobnitz broken because it was broken before you found out it was broken". I say: "foo is bad". You say: "foo is no different than bar (except it's the opposite), and might eventually be like baz (which doesn't exist)." Hard to argue with that kind of...umm...logic. :) -Jim -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Mon, Jun 18, 2018 at 2:59 PM, Jim Lee wrote: > > > On 06/17/2018 05:39 PM, Chris Angelico wrote: >> >> On Mon, Jun 18, 2018 at 10:22 AM, Jim Lee wrote: >>> >>> >>> On 06/17/2018 02:17 PM, Chris Angelico wrote: [snip] My apologies, stuff wrapped and I misread as I skimmed back. You were the one who used the word "shoehorned". In the same way, that sounds like you already knew the language, and then someone added extra features that don't fit. It's not shoehorning if the feature was already there before you met the language. The point is the same, the citation incorrect. Mea culpa. ChrisA >>> >>> >>> Of course it is "shoehorning". Why do you care when I started using the >>> language? Shoehorning implies an attempt to add a feature that didn't >>> exist >>> in the original design - a feature that is a difficult, awkward, or >>> ill-fitting complement to the original design. Whether it happened >>> yesterday or 12 years ago is immaterial. When I personally met the >>> language >>> is also immaterial. >>> >>> Microsoft "shoehorned" a Linux subsystem into Windows. I don't even use >>> Windows, yet by your logic, I can't call it "shoehorning". >> >> Or maybe that's an indication of a change in design goals. Python's >> original goal was to be very similar to C, and thus had a lot of >> behaviours copied from C; up until Python 2.2, the default 'int' type >> would overflow if it exceeded a machine word. Were long integers >> shoehorned into the design, or does it indicate that the design was >> modified to welcome them? >> >> Personally, I think the Linux subsystem is (a) no different from (but >> converse to) Wine, and (b) a good stepping-stone towards a Windows >> release using a Unix kernel. >> >> ChrisA > > I say: "frobnitz was broken". > > You say: "you can't call frobnitz broken because it was broken before you > found out it was broken". > > > I say: "foo is bad". > > You say: "foo is no different than bar (except it's the opposite), and might > eventually be like baz (which doesn't exist)." > > > Hard to argue with that kind of...umm...logic. :) That isn't what I said, and you know it. I said that you can't decry changes that were before your time (they're simply the way things are). My comments about the Linux subsystem are parenthetical. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 06/17/2018 10:04 PM, Chris Angelico wrote: On Mon, Jun 18, 2018 at 2:59 PM, Jim Lee wrote: On 06/17/2018 05:39 PM, Chris Angelico wrote: On Mon, Jun 18, 2018 at 10:22 AM, Jim Lee wrote: On 06/17/2018 02:17 PM, Chris Angelico wrote: [snip] My apologies, stuff wrapped and I misread as I skimmed back. You were the one who used the word "shoehorned". In the same way, that sounds like you already knew the language, and then someone added extra features that don't fit. It's not shoehorning if the feature was already there before you met the language. The point is the same, the citation incorrect. Mea culpa. ChrisA Of course it is "shoehorning". Why do you care when I started using the language? Shoehorning implies an attempt to add a feature that didn't exist in the original design - a feature that is a difficult, awkward, or ill-fitting complement to the original design. Whether it happened yesterday or 12 years ago is immaterial. When I personally met the language is also immaterial. Microsoft "shoehorned" a Linux subsystem into Windows. I don't even use Windows, yet by your logic, I can't call it "shoehorning". Or maybe that's an indication of a change in design goals. Python's original goal was to be very similar to C, and thus had a lot of behaviours copied from C; up until Python 2.2, the default 'int' type would overflow if it exceeded a machine word. Were long integers shoehorned into the design, or does it indicate that the design was modified to welcome them? Personally, I think the Linux subsystem is (a) no different from (but converse to) Wine, and (b) a good stepping-stone towards a Windows release using a Unix kernel. ChrisA I say: "frobnitz was broken". You say: "you can't call frobnitz broken because it was broken before you found out it was broken". I say: "foo is bad". You say: "foo is no different than bar (except it's the opposite), and might eventually be like baz (which doesn't exist)." Hard to argue with that kind of...umm...logic. :) That isn't what I said, and you know it. I said that you can't decry changes that were before your time (they're simply the way things are). My comments about the Linux subsystem are parenthetical. ChrisA Really? Wow. I'd hate to live in your world! Just because something exists, it can't be challenged or questioned. Got it! -Jim -- https://mail.python.org/mailman/listinfo/python-list
Is it possible to call a class but without a new instance created?
After looking into the \tkiniter\font.py source file, triggered by Jim's hint on my previous subject "Why an object changes its "address" between adjacent calls?", I get more confused. Below was quoted from the font.py: def nametofont(name): """Given the name of a tk named font, returns a Font representation. """ return Font(name=name, exists=True) class Font: """Represents a named font. Constructor options are: ... exists -- does a named font by this name already exist? Creates a new named font if False, points to the existing font if True. ... """ def __init__(self, root=None, font=None, name=None, exists=False, **options): ... -- From my understanding, the __init__ method was called after the instance was created, that's why the __init__ has a self parameter, right? Then, how is it possible "...points to the existing font if True"? I didn't see any clue in __init__ doing this. I also make a test of my own and it fails too. >>> class A: ... objs = [] ... def __init__(self, exists=False): ... if exists: self = self.objs[0] ... else: self.objs.append(self) ... >>> a0 = A() >>> id(a0) 35569968 >>> a1 = A(exists=True) >>> id(a1) 35572336 What I expect is that id(a0) and id(a1) has the same value. They should points to the same object. Best Regards, Jach Fong --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- https://mail.python.org/mailman/listinfo/python-list
