Re: rdflib subclass problem
duncan smith writes:
> I'm just getting to grips with RDF and rdflib, and I've hit
> something I can't figure out.
>
> I have a graph with information on two people. (I haven't shown the
> imports below because they're scattered around my interactive session
> and I might reconstruct them incorrectly. Anyone familiar with rdflib
> will probably know what they are.)
>
>
G = Graph()
mark = BNode()
nat = BNode()
G.add((mark, RDF.type, FOAF.Person))
G.add((mark, FOAF.firstName, Literal('mark')))
G.add((nat, RDF.type, URIRef('Professor')))
G.add((nat, FOAF.firstName, Literal('natalie')))
G.add((URIRef('Professor'), RDFS.subClassOf, FOAF.Person))
>
>
> So I have specified that mark is a Person, natalie is a Professor, and
> that Professor is a subclass of Person. (I know that Professor is really
> a FOAF.title, but I'm just tinkering ATM.)
>
>
qres = G.query(
> """SELECT DISTINCT ?aname
>WHERE {
> ?a rdf:type foaf:Person .
> ?a foaf:firstName ?aname .
>}""", initNs = {"rdf": RDF,"foaf": FOAF})
for row in qres:
> print "%s is a person" % row
>
>
> mark is a person
qres = G.query(
> """SELECT DISTINCT ?aname
>WHERE {
> ?a rdf:type ?prof .
> ?a foaf:firstName ?aname .
>}""", initNs = {"rdf": RDF,"foaf": FOAF, "prof":
> URIRef('Professor')})
for row in qres:
> print "%s is a Prof" % row
>
>
> natalie is a Prof
> mark is a Prof
>
>
> But according to the above queries only mark is a Person, and each is a
> Professor. I would have thought that both would be Persons and only
> natalie would be a Professor. Can anyone spot where I'm going wrong
> here? Thanks.
What you observe would be consistent with "RDFS.subClassOf" working
in the other direction than the one you expect; i.e. that
URIRef('Professor'), RDFS.subClassOf, FOAF.Person
means that "Person" is a subclass of "Professor" (not what
you expect, that "Professor" is a subclass of "Person").
Carefully check whether "A rel B" means that "B" is in relation "rel" to "A"
(I think that is the case) or that "A" is in relation "rel" to "B".
--
https://mail.python.org/mailman/listinfo/python-list
Re: Everything good about Python except GUI IDE?
Chris Angelico :
> On Wed, Mar 2, 2016 at 4:41 PM, Marko Rauhamaa wrote:
>> I was talking about JSON for the standard I/O, not the command-line
>> arguments, as in:
>>
>>ps -ef | awk '/httpd/ { print $2 }'
>>
>> where "ps -ef" emits SPC-separated fields and LF-separated records, and
>> awk parses and processes them.
>
> If you want to change that, you have to change the entire ecosystem,
> not just the shell. You would have to teach every single program to
> use a different structure.
Correct. There could be translation utilities in the interim.
> A lot of programs already do support NUL-separation - usually with a
> -z parameter or something. But you won't be able to magically get them
> all to use JSON. And I doubt it would be advantageous anyway.
The advantages are obvious. Barely any programs do proper escaping, and
security problems abound.
Maybe a starting point would be a Python Toybox (https://en.wikipedia.org/wiki/Toybox>).
Ecosystem intertia aside, key to the success of such an endeavor would
be to find a Python equivalent for
ps -ef | awk '/httpd/ { print $2 }'
that would be at least as convenient for the fingers and the eye.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Explaining names vs variables in Python
Hello, I know Python does not have variables, but names. Multiple names cant then be bound to the same objects. So this behavior >>> b = 234 >>> v = 234 >>> b is v True according to the above that is ok But where is the consistency ? if I try : >>> v = 890 >>> w = 890 >>> v is w False It is a little difficult to explain this behavior to a newcommer in Python Can someone give me the right argument to expose ? Regards -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
Den 02-03-2016 kl. 09:32 skrev Salvatore DI DIO: Hello, I know Python does not have variables, but names. Multiple names cant then be bound to the same objects. So this behavior b = 234 v = 234 b is v True according to the above that is ok But where is the consistency ? if I try : v = 890 w = 890 v is w False It is a little difficult to explain this behavior to a newcommer in Python Can someone give me the right argument to expose ? Regards You may get an answer to your question here: http://stackoverflow.com/questions/2419701/python-object-identity-question As I understand it, when you use 'is', you are comparing addresses to objects, not the values contained in the objects. Use '==' instead. Take a look here as well: https://docs.python.org/3.5/reference/datamodel.html -- Venlig hilsen / Best regards Jesper K. Brogaard (remove upper case letters in my e-mail address) -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
On 02/03/2016 09:32, Salvatore DI DIO wrote: > Hello, > > I know Python does not have variables, but names. > Multiple names cant then be bound to the same objects. > > So this behavior Python has variables. They are just not the kind of variables you find in C and variations but more like variables in lisp, scheme and smalltalk. b = 234 v = 234 b is v > True > > according to the above that is ok No that is just a coincidence. A consequent of the particular implimentation, that has prepared a number of number objects beforehand. There is no guarantee in the language that the third statement above will produce True. > But where is the consistency ? if I try : > v = 890 w = 890 v is w > False > > It is a little difficult to explain this behavior to a newcommer in Python. This behaviour is undefined in the language. So there is nothing to explain except that it depends on implementation details. Any program that depends on two variable being the same or not the after similar code is wrong. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Effects of caching frequently used objects, was Re: Explaining names vs variables in Python
Salvatore DI DIO wrote: > Hello, > > I know Python does not have variables, but names. > Multiple names cant then be bound to the same objects. > > So this behavior > b = 234 v = 234 b is v > True > > according to the above that is ok > > > > But where is the consistency ? if I try : > v = 890 w = 890 v is w > False > > It is a little difficult to explain this behavior to a newcommer in Python > > Can someone give me the right argument to expose ? You should not bother with object identity for objects other than None. Some small integers are used a lot, e. g. Python 3.4.3 (default, Oct 14 2015, 20:28:29) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.getrefcount(0) 606 >>> sys.getrefcount(1) 918 >>> sys.getrefcount(256) 31 >>> sys.getrefcount(-1) 51 therefore as an optimization the Python developers decided to put -5...256 (actual range may vary across interpreter versions) into a cache and reuse them rather than build a new object for every instance. This may save both time and memory, but is otherwise irrelevant. Something similar is done for strings: >>> a = "hello" >>> b = "hello" >>> a is b True >>> a = "hello, world" >>> b = "hello, world" >>> a is b False But: >>> a = "hello, world"; b = "hello, world" >>> a is b True Again this is an optimization (mostly targeted at attribute names) which should not affect the behaviour of a properly written Python program. -- https://mail.python.org/mailman/listinfo/python-list
Re: What arguments are passed to the __new__ method ?
"ast" a écrit dans le message de news:56d5d043$0$632$426a7...@news.free.fr... ty for the détailed explanations. An other question: What is the very first method launched when an instantiation is done ? e.g obj = MyClass(0, 5, 'xyz') is it __call__ (from object or MyClass if overriden) ? then _call__ launches __new__ and then __init__ This would be coherent with the language or is it __new__ then __init__ as said on courses I read ? -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
Salvatore DI DIO writes: [- -] > But where is the consistency ? if I try : > v = 890 w = 890 v is w > False I think it goes as follows. Python keeps a cached pool of some numbers that may occur relatively often. When a numerical expression evaluates to a cached value, it returns the cached object instead. >>> 1 + 1 is 2 True >>> 800 + 90 + 0 is 890 False This way programs don't fill the memory with a large number of copies of frequently occurring numbers like 2, and also don't keep rare numbers like 890 around in the cache unnecessarily. Python doesn't keep track of how often numbers actually occur. I think it considers 0, 1, 2, ..., n, up to some rather small n, heuristically frequent, and that's it. Also, this is an implementation detail. Hm, -5, -4, -3, -2, -1 also seem cached when I try them, but -6 not. The following are too delicate for me. I suppose the answers could have been different, but I can't guess what mechanism actually leads to these results. Just idle curiosity on my part. >>> 890 is 890 True >>> id(890) == id(890) True >>> 890 is 891 False >>> id(890) == id(891) False Python 3.4.3 (default, Oct 14 2015, 20:33:09) [GCC 4.8.4] on linux -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything good about Python except GUI IDE?
Marko Rauhamaa wrote: >Gordon Levi : > >> Nobody likes filling in forms but how do you suggest converting a form >> based app into something loveable. > >Straight HTML does forms just fine without CSS or JavaScript, yet few >can resist. > >> What interface would make you love adding a new contact to your >> address book? > >In my case, the address book is a ~/.mailrc file, which I edit using >emacs. I find it difficult to believe that you _love_ updating your contacts using Emacs even if it gives you an excuse to get some therapy from Eliza. It seems equally unlikely that you can do without phone numbers and addresses for your contacts. -- https://mail.python.org/mailman/listinfo/python-list
Re: Reason for not allowing import twice but allowing reload()
On Wednesday, March 2, 2016 at 7:53:10 AM UTC+5:30, Ian wrote: > On Tue, Mar 1, 2016 at 6:19 PM, Steven D'Aprano wrote: > > On Wed, 2 Mar 2016 09:29 am, Ian Kelly wrote: > > > >> There's a big difference between > >> that and clocking a year of uptime just because you can, though. > > > > What other reason is there for having a year of uptime? > > > > It's not like it is difficult. My laptop doesn't actually go anywhere: for > > historical reasons, it's a laptop but it is (mostly) used as a desktop. It > > sits on my desk. If there's a power outage, the handy built-in UPS > > (battery) keeps it alive for an hour or two. I come in, I nudge the mouse > > to wake xscreensaver and authenticate; I do my work; then I run > > xscreensaver to lock the screen and leave. > > > > If I need access to something from home, I can SSH into the office network, > > and from there into the laptop. > > > > The OS is as stable as the surface of the moon, and simply doesn't crash or > > go down ever. (If only Firefox was as good, alas, but when it does crash it > > is nearly always because I've allowed Javascript to run on some popular, > > multimedia-rich, information-free website.) I don't reboot because I don't > > need to reboot. Why would you reboot just for the sake of rebooting? > > Software updates? The nice thing about *nix systems is that *most* > updates don't require a reboot. I'm still going to reboot any time > there's a kernel update though, and those are fairly frequent. I could > read the patch notes to determine whether this new kernel version is > actually important, but it takes less of my time just to go ahead and > reboot. Dunno what systems you folks use... My ubuntu(s) 15.10 seem to (my estimates not hard data) - update every couple of days - kernel/security updates every 2-3 weeks "Stable as the surface of the moon"?? Well thats strong The other day I - aptitude purge-d the kernel I was running on [I was trying to show off to someone that ubuntu would not allow that!] - machine kept running merrily but thereafter aptitude crashed - Until I rebooted an older kernel; installed the one I had removed and rebooted to that -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
On Wed, 2 Mar 2016 07:32 pm, Salvatore DI DIO wrote:
> Hello,
>
> I know Python does not have variables, but names.
> Multiple names cant then be bound to the same objects.
Multiple names CAN be bound to the same object:
py> x = y = []
py> x is y
True
py> z = x
py> y.append("Hello world!")
py> z
['Hello world!']
So that is *three* names bound to the same list object.
> So this behavior
>
b = 234
v = 234
b is v
> True
>
> according to the above that is ok
When I try that in different versions of Python, I get different results:
# Python 2.4
py> b = 234
py> v = 234
py> b is v
False
What you are seeing is a version-dependent optimization. Not all versions of
Python will behave the same way. The reason you can do that is that
integers are immutable objects and cannot be modified. So the Python
interpreter will cache some integers, and avoid creating new objects. So:
py> a, b = 50,
py> c, d = 50,
py> a is c # the same object is reused for 50 each time
True
py> c is d # new int objects are created for each time
False
In Python 2.7, I think that the interpreter caches small ints from -1 to
255. But do not rely on this, because it is just an optimization and can
and will change from version to version.
You should never use `is` to test for equality. Use == to test for equality.
Use `is` *only* to test for object identity ("the same object").
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Reason for not allowing import twice but allowing reload()
On Wednesday, March 2, 2016 at 3:45:28 PM UTC+5:30, Rustom Mody wrote: > On Wednesday, March 2, 2016 at 7:53:10 AM UTC+5:30, Ian wrote: > > On Tue, Mar 1, 2016 at 6:19 PM, Steven D'Aprano wrote: > > > On Wed, 2 Mar 2016 09:29 am, Ian Kelly wrote: > > > > > >> There's a big difference between > > >> that and clocking a year of uptime just because you can, though. > > > > > > What other reason is there for having a year of uptime? > > > > > > It's not like it is difficult. My laptop doesn't actually go anywhere: for > > > historical reasons, it's a laptop but it is (mostly) used as a desktop. It > > > sits on my desk. If there's a power outage, the handy built-in UPS > > > (battery) keeps it alive for an hour or two. I come in, I nudge the mouse > > > to wake xscreensaver and authenticate; I do my work; then I run > > > xscreensaver to lock the screen and leave. > > > > > > If I need access to something from home, I can SSH into the office > > > network, > > > and from there into the laptop. > > > > > > The OS is as stable as the surface of the moon, and simply doesn't crash > > > or > > > go down ever. (If only Firefox was as good, alas, but when it does crash > > > it > > > is nearly always because I've allowed Javascript to run on some popular, > > > multimedia-rich, information-free website.) I don't reboot because I don't > > > need to reboot. Why would you reboot just for the sake of rebooting? > > > > Software updates? The nice thing about *nix systems is that *most* > > updates don't require a reboot. I'm still going to reboot any time > > there's a kernel update though, and those are fairly frequent. I could > > read the patch notes to determine whether this new kernel version is > > actually important, but it takes less of my time just to go ahead and > > reboot. > > Dunno what systems you folks use... > My ubuntu(s) 15.10 seem to (my estimates not hard data) > - update every couple of days > - kernel/security updates every 2-3 weeks > > "Stable as the surface of the moon"?? > Well thats strong > The other day I > - aptitude purge-d the kernel I was running on > [I was trying to show off to someone that ubuntu would not allow that!] > - machine kept running merrily but thereafter aptitude crashed > - Until I rebooted an older kernel; installed the one I had removed and > rebooted to that Right now as I write this a libssl security update. No suggested reboot But I should be rebooting if I were paranoid about security -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
On Wed, 2 Mar 2016 08:03 pm, Jesper K Brogaard wrote: > As I understand it, when you use 'is', you are comparing addresses to > objects, not the values contained in the objects. Use '==' instead. You should not think about addresses, because the location of objects is not part of the language. It is implementation-dependent. In CPython, objects are fixed to a single location in the heap, and will never move. But in Jython and IronPython, objects in the python layer are based on JVM (Java Virtual Machine) and CLR (Common Language Runtime) objects, which can move around in memory. Both the JVM and the CLR can move objects, so the location is not constant. Likewise for PyPy, which can delete and re-create objects behind the scenes, possibly in different memory locations. This is why the id() function is NOT documented as returning the address of an object, but of returning an ID number. Let's look at IDs in IronPython: >>> a, b, c = [], 1, "Hello world!" >>> print id(a), id(b), id(c), id(None) 43 44 45 0 And in Jython: >>> a, b, c = [], 1, "Hello world!" >>> print id(a), id(b), id(c), id(None) 1 2 3 4 -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Explaining names vs variables in Python (follow)
Thank you very much all of you. I better understand now Regards -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
"Salvatore DI DIO" a écrit dans le message de news:a894d5ed-d906-4ff7-a537-32bf0187e...@googlegroups.com... It is a little difficult to explain this behavior to a newcommer in Python Can someone give me the right argument to expose ? It is explained with many details here: http://blog.lerner.co.il/why-you-should-almost-never-use-is-in-python/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
Thank you very much ast and all of you. I better understant now Regards -- https://mail.python.org/mailman/listinfo/python-list
Re: What arguments are passed to the __new__ method ?
On Wed, 2 Mar 2016 08:23 pm, ast wrote:
> An other question:
>
> What is the very first method launched when an instantiation is done ?
> e.g obj = MyClass(0, 5, 'xyz')
>
> is it __call__ (from object or MyClass if overriden) ?
No, not object or MyClass. The *metaclass* __call__ is called.
For most objects, the metaclass is `type`.
The metaclass is the type of the class: classes are objects too, which means
that like all objects, they have a class. That is the metaclass.
*** WARNING ***
Metaclasses are a very advanced technique. You are not expected to
understand this.
> then _call__ launches __new__ and then __init__
> This would be coherent with the language
>
> or is it __new__ then __init__ as said on courses I read ?
Let us create a metaclass that inherits from `type`:
class Meta(type):
def __new__(meta, name, bases, namespace):
print "**Creating new Meta instance"
print "Metaclass:", meta
print "New class name:", name
print "Base classes used:", bases
print "Namespace used as class dict:", namespace
return type.__new__(meta, name, bases, namespace)
def __init__(cls, *args):
print "**Initialising Meta instance %s" % cls
def __call__(cls):
print "**Calling Meta instance %s" % cls
return super(Meta, cls).__call__()
Now let me use that metaclass to create a new class:
class MyClass(object):
__metaclass__ = Meta
def __new__(cls):
print "^^Creating new instance of %s" % cls
return super(MyClass, cls).__new__(cls)
def __init__(self):
print "^^Initialising MyClass instance %s" % self
def __call__(self):
print "^^Calling MyClass instance %s" % self
return "Hello World!"
which prints:
**Creating new Meta instance
Metaclass:
New class name: MyClass
Base classes used: (,)
Namespace used as class dict: {'__call__': , '__module__': '__main__', '__metaclass__':
, '__new__': , '__init__': }
**Initialising Meta instance
Now let me create a new MyClass instance:
instance = MyClass()
which prints:
**Calling Meta instance
^^Creating new instance of
^^Initialising MyClass instance <__main__.MyClass object at 0xb7cf2bec>
Finally, let me call the instance:
print instance()
which prints:
^^Calling MyClass instance <__main__.MyClass object at 0xb7cf2bec>
Hello World!
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to know if an object is still be referenced?
Terry Reedy at 2016/3/2 UTC+8 3:04:10PM wrote：
> On 3/1/2016 9:35 PM, jf...@ms4.hinet.net wrote:
> > Recently I was puzzled by a tkinter problem. The codes below (from a book)
> > can display the picture correctly.
> >
> > gifdir = "../gifs/"
> > from tkinter import *
> > win = Tk()
> > photo = PhotoImage(file=gifdir + "ora-pp.gif")
> > Button(win, image=photo).pack()
> > win.mainloop()
>
> Since photo is a global name, the binding remain until you explicitly
> delete it or exit the app.
>
> > And the codes below (from another book) will also work.
> >
> > class DrumMachine:
> >
> >
> > def create_play_bar(self):
> >
> >
> > photo = PhotoImage(file='images/signature.gif')
> > label = Label(playbar_frame, image=photo)
> > label.image = photo
> > label.grid(row=start_row, column=50, padx=1, sticky='w')
> >
> >
>
> Here photo is a local name and the binding disappears when the function
> exits. I would rewrite it to follow pattern 1.
>
> self.photo = PhotoImage(file='images/signature.gif')
> label = Label(playbar_frame, image=self.photo)
>
> To me, saving an attribute reference is not worth the extra line.
>
> > In the second example, I noticed that the "photo" was referenced two times
> > and I think it might be a redundancy so I remove the line "label.image =
> > photo". But it fails then.
>
> On another question, I made the same suggestion. Oops.
>
> --
> Terry Jan Reedy
Thanks, Terry. After reading your reply I noticed that I had make a mistake.
The "image" is not an attribute of the Button. It's an option. The
"label.image=photo" does a different thing. But it didn't help on solving my
puzzle.
If the problem was caused by the "photo" is a local, then binding the "photo"
to an local attribute ("label" is a local too) seems no meaning at all. But it
did make difference! No idea how the underneath mechanism works.
I run this example under the pdb and it can display the picture correctly even
without the "label.image=photo" statement. Why it fails on running at real
time? tk event scheduling? I don't know.
--Jach
--
https://mail.python.org/mailman/listinfo/python-list
Re: Everything good about Python except GUI IDE?
Gordon Levi : > I find it difficult to believe that you _love_ updating your contacts > using Emacs even if it gives you an excuse to get some therapy from > Eliza. It seems equally unlikely that you can do without phone numbers > and addresses for your contacts. WP8 doesn't allow me to modify the contacts using emacs. And to my knowledge, emacs still doesn't have a phone-call-mode. I *love* using emacs for everything I can because the whole gamut of emacs' typing machinery is at my disposal. I readily admit that reading Wikipedia articles still works better with Firefox than emacs. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
Steven D'Aprano : > On Wed, 2 Mar 2016 08:03 pm, Jesper K Brogaard wrote: > >> As I understand it, when you use 'is', you are comparing addresses to >> objects, not the values contained in the objects. Use '==' instead. > > You should not think about addresses, because the location of objects > is not part of the language. It is implementation-dependent. The ontological question is, can two *distinct* objects with *identical* characteristics exist? The fermionic answer is, no. The bosonic answer is, sure. Set theory has fermionic ontology (it's called extensionality). Python sits on the fence on that one, allowing either ontology. > This is why the id() function is NOT documented as returning the > address of an object, but of returning an ID number. Let's look at IDs > in IronPython: > a, b, c = [], 1, "Hello world!" print id(a), id(b), id(c), id(None) > 43 44 45 0 > > > And in Jython: > a, b, c = [], 1, "Hello world!" print id(a), id(b), id(c), id(None) > 1 2 3 4 Python doesn't define or use the concept of an "address." Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
On Wed, Mar 2, 2016 at 11:34 PM, Marko Rauhamaa wrote: > The ontological question is, can two *distinct* objects with *identical* > characteristics exist? > > The fermionic answer is, no. > > The bosonic answer is, sure. > > Set theory has fermionic ontology (it's called extensionality). > > Python sits on the fence on that one, allowing either ontology. Python defines that every object has an identity, which can be represented as an integer. Since this is an intrinsic part of the object, no two distinct objects can truly have identical characteristics. Python's objects are like rifles - there are many like it, but this one is mine. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
Chris Angelico writes: > Python defines that every object has an identity, which can be > represented as an integer. Since this is an intrinsic part of the > object, no two distinct objects can truly have identical > characteristics. Python's objects are like rifles - there are many > like it, but this one is mine. Rifles are not mines. A rifle hurts you from a distance. A mine hurts you when you step on it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
Chris Angelico : > Python defines that every object has an identity, which can be > represented as an integer. Since this is an intrinsic part of the > object, no two distinct objects can truly have identical > characteristics. Python's objects are like rifles - there are many > like it, but this one is mine. How can you be sure Python isn't returning the same id value for two distinct objects? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
On Thu, Mar 3, 2016 at 12:39 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> Python defines that every object has an identity, which can be >> represented as an integer. Since this is an intrinsic part of the >> object, no two distinct objects can truly have identical >> characteristics. Python's objects are like rifles - there are many >> like it, but this one is mine. > > How can you be sure Python isn't returning the same id value for two > distinct objects? The same way I can be sure about anything else in Python. It's a language guarantee. If you're bothered by that, you should also be concerned that str(x) might not actually call x.__str__(), or that a+b*c might evaluate the addition before the multiplication. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
urlopen, six, and py2
Hi,
it seems that urlopen had no context manager for versions < 3. The
following code therefore will crash on py2 but not on py3.
from six.moves.urllib.request import urlopen
with urlopen('http://www.google.com') as resp:
_ = resp.read()
Error:
AttributeError: addinfourl instance has no attribute '__exit__'
I actually wonder if this is not something that the six library should
take care of upstream, but in the meantime I could simply do what is
suggested on this stackoverflow post:
http://stackoverflow.com/questions/30627937/tracebaclk-attributeerroraddinfourl-instance-has-no-attribute-exit
My question is: why does the python3 version need a "with" block while
the python2 version doesn't? Can I skip the "with" entirely, or should I
rather do the following:
from six.moves.urllib.request import urlopen
try:
with urlopen('http://www.google.com') as resp:
_ = resp.read()
except AttributeError:
# python 2
resp = urlopen('http://www.google.com')
_ = resp.read()
(which is quite ugly).
Thanks!
Fabien
--
https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
Chris Angelico : > On Thu, Mar 3, 2016 at 12:39 AM, Marko Rauhamaa wrote: >> Chris Angelico : >> >>> Python defines that every object has an identity, which can be >>> represented as an integer. Since this is an intrinsic part of the >>> object, no two distinct objects can truly have identical >>> characteristics. Python's objects are like rifles - there are many >>> like it, but this one is mine. >> >> How can you be sure Python isn't returning the same id value for two >> distinct objects? > > The same way I can be sure about anything else in Python. It's a > language guarantee. Actually, my question is (intentionally) nonsensical. The sameness or distinctness of two objects is not directly defined in Python. The definition is simply: Two objects X and Y are called identical if X is Y evaluates to a true value. Additionally, we have: If objects X and Y are identical, it is guaranteed that id(X) == id(Y) evaluates to a true value. Even more strongly, we have: For any objects X and Y, id(X) == id(Y) if X is Y else id(X) != id(Y) evaluates to a true value. What is missing is the rules that are obeyed by the "is" operator. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: urlopen, six, and py2
On 2 March 2016 at 14:05, Fabien wrote:
> [snip]
> My question is: why does the python3 version need a "with" block while the
> python2 version doesn't? Can I skip the "with" entirely, or should I rather
> do the following:
It's not a case of "need", using the "with" construction is an added
feature, not a burden!
> from six.moves.urllib.request import urlopen
>
> try:
> with urlopen('http://www.google.com') as resp:
> _ = resp.read()
> except AttributeError:
> # python 2
> resp = urlopen('http://www.google.com')
> _ = resp.read()
This is poor practise as you aren't closing "resp".
This leaves state lying around that you don't need anymore, which is
the whole purpose of the context manager that 3 provides.
It will *usually* be cleaned up when leaving the current scope, but
won't if there is an exception thrown. Using the context manager
ensures resp is *always* cleaned up properly even if an exception is
thrown.
I agree that six should probably handle this, but in the meantime you
could use contextlib.closing ([1]) rather than rolling your own. It
even uses urlopen as an example.
If you absolutely want to roll your own then don't bother with the
context manager provided by 3 at all, just use:
resp = urlopen('http://www.google.com')
try:
_ = resp.read()
finally:
resp.close()
But as this is wordier and more fragile than using a context manager
to clean up for you, I expect you won't bother :).
[1] https://docs.python.org/2/library/contextlib.html#contextlib.closing
--
Matt Wheeler
http://funkyh.at
--
https://mail.python.org/mailman/listinfo/python-list
Re: urlopen, six, and py2
On Thu, Mar 3, 2016 at 1:35 AM, Matt Wheeler wrote:
>> from six.moves.urllib.request import urlopen
>>
>> try:
>> with urlopen('http://www.google.com') as resp:
>> _ = resp.read()
>> except AttributeError:
>> # python 2
>> resp = urlopen('http://www.google.com')
>> _ = resp.read()
>
> This is poor practise as you aren't closing "resp".
> This leaves state lying around that you don't need anymore, which is
> the whole purpose of the context manager that 3 provides.
> It will *usually* be cleaned up when leaving the current scope, but
> won't if there is an exception thrown. Using the context manager
> ensures resp is *always* cleaned up properly even if an exception is
> thrown.
Not sure why you say it won't if there's an exception thrown. This
code will do the same thing on both versions:
def get_data():
resp = urlopen('http://www.google.com')
return resp.read()
Absent the context manager, this depends on object disposal for its
cleanup. But whether this function returns normally or raises an
exception, the response object goes out of scope at the same time.
There's no guarantee that it'll be cleaned up immediately when the
function exits, but it's the same for the exceptional and
non-exceptional cases.
Agreed that try/finally is the best way to do cross-platform code here:
def get_data():
resp = urlopen('http://www.google.com')
try:
return resp.read()
finally:
resp.close()
It's reasonably compact, and fairly clear. And it has the exact
guarantee that the context manager has (before the function exits, the
'finally' block will be performed, and resources will be properly
released).
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
On Wednesday, March 2, 2016 at 7:42:09 PM UTC+5:30, Marko Rauhamaa wrote: > Chris Angelico : > > > On Thu, Mar 3, 2016 at 12:39 AM, Marko Rauhamaa wrote: > >> Chris Angelico : > >> > >>> Python defines that every object has an identity, which can be > >>> represented as an integer. Since this is an intrinsic part of the > >>> object, no two distinct objects can truly have identical > >>> characteristics. Python's objects are like rifles - there are many > >>> like it, but this one is mine. > >> > >> How can you be sure Python isn't returning the same id value for two > >> distinct objects? > > > > The same way I can be sure about anything else in Python. It's a > > language guarantee. > > Actually, my question is (intentionally) nonsensical. > > The sameness or distinctness of two objects is not directly defined in > Python. The definition is simply: > >Two objects X and Y are called identical if > >X is Y > >evaluates to a true value. > > Additionally, we have: > >If objects X and Y are identical, it is guaranteed that > > id(X) == id(Y) > >evaluates to a true value. > > Even more strongly, we have: > >For any objects X and Y, > > id(X) == id(Y) if X is Y else id(X) != id(Y) > >evaluates to a true value. > > What is missing is the rules that are obeyed by the "is" operator. is is not is is is was [fermionic or bosonic?] -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
On Wed, Mar 2, 2016 at 2:35 AM, Jussi Piitulainen
wrote:
> The following are too delicate for me. I suppose the answers could have
> been different, but I can't guess what mechanism actually leads to these
> results. Just idle curiosity on my part.
>
890 is 890
> True
id(890) == id(890)
> True
This has to do with the way code blocks are compiled. In the
interactive interpreter, a single line like '890 is 890' is compiled
to a single code object. The constant 890 appears twice in the same
code block, so the optimizer uses the same constant for both. Note in
the following that the same index appears for both, so they're
actually the same object reference.
>>> import dis
>>> dis.dis('890 is 890')
1 0 LOAD_CONST 0 (890)
3 LOAD_CONST 0 (890)
6 COMPARE_OP 8 (is)
9 RETURN_VALUE
>>> compile('890 is 890', '', 'exec').co_consts
(890, None)
As for the earlier example of:
1 + 1 is 2
> True
800 + 90 + 0 is 890
> False
This one actually surprises me a little, because the optimizer is also
smart enough to evaluate '800 + 90 + 0' and just store a constant of
890:
>>> dis.dis('800 + 90 + 0 is 890')
1 0 LOAD_CONST 5 (890)
3 LOAD_CONST 3 (890)
6 COMPARE_OP 8 (is)
9 RETURN_VALUE
>>> compile('800 + 90 + 0 is 890', '', 'exec').co_consts
(800, 90, 0, 890, None, 890, 890)
Not smart enough to reuse the existing reference in this case
apparently, or even to prune out the original constants that are no
longer used in the code.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Reason for not allowing import twice but allowing reload()
On 2016-03-02, Ian Kelly wrote: > Software updates? The nice thing about *nix systems is that *most* > updates don't require a reboot. I'm still going to reboot any time > there's a kernel update though, and those are fairly frequent. I could > read the patch notes to determine whether this new kernel version is > actually important, but it takes less of my time just to go ahead and > reboot. I try to remember to reboot every couple weeks or so even without a kernel update. There sometimes updates to things like the "rc" stuff or udev or whatnot which occasionally cause boot-time problems. If you let too much time go by between reboots, and something that happend several months ago is going to cause a problem at boot time, that reboot is guaranteed to happen when it's the most inconvenient. And it's a lot easier to figure out the problem when it's due to a recent update. > With my company-owned Macbook Air, the security policy will > eventually schedule a *forced* reboot when there are "critical" > updates to be installed. Thankfully the scheduler is pretty good > about making sure it's not catching the user at an inopportune > moment. -- Grant Edwards grant.b.edwardsYow! Let's all show human at CONCERN for REVERAND MOON's gmail.comlegal difficulties!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload())
On Tuesday, March 1, 2016 at 12:23:02 PM UTC+5:30, Terry Reedy wrote: > On 2/29/2016 7:42 AM, Rustom Mody wrote: > > > Is import needed at all when trying out in Idle? > ... > > So it does appear that > > 1. import not necessary with(in) idle > > 2. However import and f5 (ie is run as main) are different > > > > May some idle experts elaborate on this? Whats the idle idiom of import-ing? > > Rustom, since I know that you are not a rank beginner, I have trouble > understanding what you are asking. Heh! I know some things; dont know many things > F5 when editing foo.py is equivalent > to running "python -i foo.py" on a command line while 'in' the directory > containing foo.py. In both cases, foo.py is run as a main module, with > __name__ == '__main__'. The difference is that F5 runs foo.py under > IDLE supervision, with results going into and interactive inputs coming > from IDLE shell instead of the console interpreter. > > Imports are used in a module to access objects within the imported module. Let me try to explain again There is import and import. There is the formal meaning of the import keyword in python -- call it import-f There is the informal expectation and need of programmers to 'pull something into python' -- call it import-i That there is some cognitive dissonance between import-f and import-i is seen in the OP's question itself; also Chris' "I dont believe the language should be changed" So the question is around: What is the best practice for doing import-i in python? As the OP finds import-f works once and fails thereafter In idle one can get the desired result of import-i with F5 Is that right? Also in general is there good usecases for import-f at that interpreter prompt in idle? I think not but not sure of it -- https://mail.python.org/mailman/listinfo/python-list
Re: urlopen, six, and py2
On 03/02/2016 03:35 PM, Matt Wheeler wrote: I agree that six should probably handle this, Thank you Matt and Chris for your answers. Do you think I should open an issue on six? It sounds unlikely that I am the first one having this problem... (until this difference with urlopen I have found six to be extremely good at helping not caring about python versions at all) -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
Ian Kelly writes:
> On Wed, Mar 2, 2016 at 2:35 AM, Jussi Piitulainen wrote:
>> The following are too delicate for me. I suppose the answers could have
>> been different, but I can't guess what mechanism actually leads to these
>> results. Just idle curiosity on my part.
>>
> 890 is 890
>> True
> id(890) == id(890)
>> True
>
> This has to do with the way code blocks are compiled. In the
> interactive interpreter, a single line like '890 is 890' is compiled
> to a single code object. The constant 890 appears twice in the same
> code block, so the optimizer uses the same constant for both. Note in
> the following that the same index appears for both, so they're
> actually the same object reference.
No wonder my guesses failed. This is different.
import dis
dis.dis('890 is 890')
> 1 0 LOAD_CONST 0 (890)
> 3 LOAD_CONST 0 (890)
> 6 COMPARE_OP 8 (is)
> 9 RETURN_VALUE
compile('890 is 890', '', 'exec').co_consts
> (890, None)
>
>
> As for the earlier example of:
>
> 1 + 1 is 2
>> True
> 800 + 90 + 0 is 890
>> False
>
> This one actually surprises me a little, because the optimizer is also
> smart enough to evaluate '800 + 90 + 0' and just store a constant of
> 890:
>
dis.dis('800 + 90 + 0 is 890')
> 1 0 LOAD_CONST 5 (890)
> 3 LOAD_CONST 3 (890)
> 6 COMPARE_OP 8 (is)
> 9 RETURN_VALUE
compile('800 + 90 + 0 is 890', '', 'exec').co_consts
> (800, 90, 0, 890, None, 890, 890)
>
> Not smart enough to reuse the existing reference in this case
> apparently, or even to prune out the original constants that are no
> longer used in the code.
So it has access to three 890-objects and compares two of them :)
Thanks.
--
https://mail.python.org/mailman/listinfo/python-list
Re: urlopen, six, and py2
On Thu, Mar 3, 2016 at 2:36 AM, Fabien wrote: > On 03/02/2016 03:35 PM, Matt Wheeler wrote: >> >> I agree that six should probably handle this, > > > Thank you Matt and Chris for your answers. Do you think I should open an > issue on six? It sounds unlikely that I am the first one having this > problem... > > (until this difference with urlopen I have found six to be extremely good at > helping not caring about python versions at all) What happens if you use 'requests' rather than urlopen? My guess is that requests will already have dealt with this. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: rdflib subclass problem
On 02/03/16 08:16, dieter wrote:
> duncan smith writes:
>
>> I'm just getting to grips with RDF and rdflib, and I've hit
>> something I can't figure out.
>>
>> I have a graph with information on two people. (I haven't shown the
>> imports below because they're scattered around my interactive session
>> and I might reconstruct them incorrectly. Anyone familiar with rdflib
>> will probably know what they are.)
>>
>>
> G = Graph()
> mark = BNode()
> nat = BNode()
> G.add((mark, RDF.type, FOAF.Person))
> G.add((mark, FOAF.firstName, Literal('mark')))
> G.add((nat, RDF.type, URIRef('Professor')))
> G.add((nat, FOAF.firstName, Literal('natalie')))
> G.add((URIRef('Professor'), RDFS.subClassOf, FOAF.Person))
>
>>
>>
>> So I have specified that mark is a Person, natalie is a Professor, and
>> that Professor is a subclass of Person. (I know that Professor is really
>> a FOAF.title, but I'm just tinkering ATM.)
>>
>>
> qres = G.query(
>> """SELECT DISTINCT ?aname
>>WHERE {
>> ?a rdf:type foaf:Person .
>> ?a foaf:firstName ?aname .
>>}""", initNs = {"rdf": RDF,"foaf": FOAF})
> for row in qres:
>> print "%s is a person" % row
>>
>>
>> mark is a person
> qres = G.query(
>> """SELECT DISTINCT ?aname
>>WHERE {
>> ?a rdf:type ?prof .
>> ?a foaf:firstName ?aname .
>>}""", initNs = {"rdf": RDF,"foaf": FOAF, "prof":
>> URIRef('Professor')})
> for row in qres:
>> print "%s is a Prof" % row
>>
>>
>> natalie is a Prof
>> mark is a Prof
>
>>
>>
>> But according to the above queries only mark is a Person, and each is a
>> Professor. I would have thought that both would be Persons and only
>> natalie would be a Professor. Can anyone spot where I'm going wrong
>> here? Thanks.
>
> What you observe would be consistent with "RDFS.subClassOf" working
> in the other direction than the one you expect; i.e. that
>
>URIRef('Professor'), RDFS.subClassOf, FOAF.Person
>
> means that "Person" is a subclass of "Professor" (not what
> you expect, that "Professor" is a subclass of "Person").
>
> Carefully check whether "A rel B" means that "B" is in relation "rel" to "A"
> (I think that is the case) or that "A" is in relation "rel" to "B".
>
According to https://www.w3.org/TR/rdf-schema/#ch_class -
A triple of the form:
C1 rdfs:subClassOf C2
states that C1 is an instance of rdfs:Class, C2 is an instance of
rdfs:Class and C1 is a subclass of C2.
I might report it as a bug, but I'm not yet 100% convinced I haven't got
something wrong. Cheers.
Duncan
--
https://mail.python.org/mailman/listinfo/python-list
Re: [Off-topic] Requests author discusses MentalHealthError exception
On Tuesday, March 1, 2016 at 10:36:02 PM UTC+5:30, Steven D'Aprano wrote: > On Tue, 1 Mar 2016 04:08 am, Rustom Mody wrote: > > > And who is the last arbiter on that 'reality'? > > I'll give you the benefit of the doubt that this is a genuine question, and > not just an attempt to ask a rhetorical question to demonstrate your > profundity. > > You should not assume that there is any such thing as "the last arbiter" of > reality. There is no arbiter at all, let alone a final one. But what we > have are various ways of managing and uncertainty and error. One of which > is consensus. For instance, there are seven billion people on earth who > think they are people, and one who thinks he may be a butterfly. Which is > more likely to be correct? > > https://en.wikiquote.org/wiki/Zhuangzi > > To quote Terry Pratchett: > > 'The poet Hoha once dreamed he was a butterfly, and then he > awoke and said, "Am I a man who dreamed he was a butterfly or > am I a butterfly dreaming he is a man?"' said Lobsang, trying > to join in. > 'Really?' said Susan briskly. 'And which was he?' > 'What? Well...who knows?' > 'How did he write his poems?' said Susan. > 'With a brush, of course.' > 'He didn't flap around making information-rich patterns in > the air or laying eggs on cabbage leaves?' > 'No one ever mentioned it.' > 'Then he was probably a man,' said Susan. > > > Because there are limitations on how we observe reality, there are limits to > how objective we can be. We have an imperfect ability to observe the world > around us (including our own mental states) and are prone to errors. But, > over a wide range of conditions (although not *all* conditions) we can > eliminate many classes of error by comparing notes with our fellows, so to > speak. If I think I am a butterfly, and my wife thinks I'm a man, and my > co-workers think I'm a man, and my neighbours think I'm a man, chances are > good that it is me who is mistaken, not them. > > Consequently reality is a shared construct -- or rather, our understanding > of reality is at least partly a shared construct. > > In principle, at least, *everything* is subject to disproof. But in practice > some things are more certain than others. I wouldn't bet $100 on quarks > still being considered the fundamental building block of matter in 200 > years, but I would bet a million dollars on the sun still seeming to rise > in the east every 24 hours. > > As Isaac Asimov put it: > > When people thought the earth was flat, they were wrong. > When people thought the earth was spherical, they were > wrong. But if you think that thinking the earth is > spherical is just as wrong as thinking the earth is flat, > then your view is wronger than both of them put together. > > > https://en.wikipedia.org/wiki/Wronger_than_wrong > > http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm > > It's not that reality itself is subject to change (except in the trivial > sense that we can take actions that modify the state of the world: I can > pick this cup up and move it over there, you can eat that apple) but that > our understanding of reality is subject to change. Sometimes our > understanding is full of uncertainty and doubt, sometimes it is subject to > re-interpretation, and sometimes our understanding is almost certainly > correct: it is difficult to imagine any credible or believable > reinterpretation that would change the facts as we know them. A thousand > years from now, the sun will still appear to be rising in the east. Consensus? Um lets see... Here are two writings: [1] http://www.poetryloverspage.com/poets/blake/to_see_world.html [2] http://www.bartleby.com/101/536.html If you see [2] around line 75 it almost verbatim echoes Larry's complaint of what 'they' did to Kennneth And how is [1]'s starting different from Kenneth's finding his weight to be the weight of the universe? Maybe the authors of these need the services of a psychiatrist? If not you may find some appeal in this modernized version: http://blog.languager.org/2011/10/vagaries-of-intelligence.html As for Asimov, yeah he's right perhaps in distinguishing wrong wronger and wrongest Not so much in underestimating the time for humans to autocorrect their errors A collection [inspired by earlier comments of yours :-) ]: http://blog.languager.org/2016/01/how-long.html -- https://mail.python.org/mailman/listinfo/python-list
Speaking of Javascript [was Re: Everything good about Python except GUI IDE?]
Speaking of Javascript exploits: http://thedailywtf.com/articles/bidding-on-security This is a real exploit, and Ebay have refused to fix it. Yay them! More here: http://blog.checkpoint.com/2016/02/02/ebay-platform-exposed-to-severe-vulnerability/ -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
On Thu, 3 Mar 2016 12:48 am, Chris Angelico wrote: > On Thu, Mar 3, 2016 at 12:39 AM, Marko Rauhamaa wrote: >> Chris Angelico : >> >>> Python defines that every object has an identity, which can be >>> represented as an integer. Since this is an intrinsic part of the >>> object, no two distinct objects can truly have identical >>> characteristics. Python's objects are like rifles - there are many >>> like it, but this one is mine. >> >> How can you be sure Python isn't returning the same id value for two >> distinct objects? The language is entitled to re-use IDs provided the objects do not exist at the same time. So there certainly will be times that Python will return the same ID for different objects: py> id([1]) 3083419340L py> id([2]) 3083419340L > The same way I can be sure about anything else in Python. It's a > language guarantee. If you're bothered by that, you should also be > concerned that str(x) might not actually call x.__str__(), Technically, it doesn't, it calls type(x).__str__() (at least in Python 3 and new-style classes in 2) :-) But your point is broadly correct: you trust the language to do what it promises, or you look for evidence that it doesn't and report a bug if you find it. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
On Thu, 3 Mar 2016 01:11 am, Marko Rauhamaa wrote: > What is missing is the rules that are obeyed by the "is" operator. I think what is actually missing is some common bloody sense. The Python docs are written in English, and don't define *hundreds*, possible *thousands* of words because they are using their normal English meaning. The docs for `is` say: 6.10.3. Identity comparisons The operators is and is not test for object identity: x is y is true if and only if x and y are the same object. x is not y yields the inverse truth value. https://docs.python.org/3/reference/expressions.html#is-not In this case, "same object" carries the normal English meaning of "same" and the normal computer science meaning of "object" in the sense of "Object Oriented Programming". There's no mystery here, no circular definition. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
On Wednesday, March 2, 2016 at 10:53:40 PM UTC+5:30, Steven D'Aprano wrote: > On Thu, 3 Mar 2016 01:11 am, Marko Rauhamaa wrote: > > > What is missing is the rules that are obeyed by the "is" operator. > > I think what is actually missing is some common bloody sense. The Python > docs are written in English, and don't define *hundreds*, possible > *thousands* of words because they are using their normal English meaning. > > The docs for `is` say: > > 6.10.3. Identity comparisons > > The operators is and is not test for object identity: x is y is true if and > only if x and y are the same object. x is not y yields the inverse truth > value. > > https://docs.python.org/3/reference/expressions.html#is-not > > > In this case, "same object" carries the normal English meaning of "same" and > the normal computer science meaning of "object" in the sense of "Object > Oriented Programming". There's no mystery here, no circular definition. > http://plato.stanford.edu/entries/identity/ -- https://mail.python.org/mailman/listinfo/python-list
Re: What arguments are passed to the __new__ method ?
On Tue, 1 Mar 2016 18:24:12 +0100, ast wrote: > > It's not clear to me what arguments are passed to the > __new__ method. Here is a piece of code: > > > class Premiere: > > def __new__(cls, price): > return object.__new__(cls) > > def __init__(self, price): > pass [snip] Of course, maybe you don't need to define a __new__ method at all. Personally, I find that __init__ suffices for my simple needs. -- To email me, substitute nowhere->runbox, invalid->com. -- https://mail.python.org/mailman/listinfo/python-list
Re: Speaking of Javascript [was Re: Everything good about Python except GUI IDE?]
On Thu, Mar 3, 2016 at 4:05 AM, Steven D'Aprano wrote: > Speaking of Javascript exploits: > > http://thedailywtf.com/articles/bidding-on-security > > > This is a real exploit, and Ebay have refused to fix it. Yay them! > > More here: > > http://blog.checkpoint.com/2016/02/02/ebay-platform-exposed-to-severe-vulnerability/ To be fair, this isn't a JS exploit; it's a trusting-of-trust issue - eBay has declared that you can trust them to sanitize their sellers' listings, and so you trust eBay, but this exploit gets past the filter. You're no more vulnerable looking at one of those listings than you would be going to a web site entirely controlled by the attacker, save that (particularly on mobile devices) there are a lot of people out there who'll say "Oh, it'e eBay, I'm safe". ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
Salvatore DI DIO writes: > I know Python does not have variables, but names. In addition to the other food answers in this thread, you will want to watch http://nedbatchelder.com/text/names.html> Ned Batchelder's presentation on “Facts and myths about Python names and values”. -- \“Members of the general public commonly find copyright rules | `\implausible, and simply disbelieve them.” —Jessica Litman, | _o__) _Digital Copyright_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: What arguments are passed to the __new__ method ?
Peter Pearson wrote: > On Tue, 1 Mar 2016 18:24:12 +0100, ast wrote: >> >> It's not clear to me what arguments are passed to the >> __new__ method. Here is a piece of code: >> >> >> class Premiere: >> >> def __new__(cls, price): >> return object.__new__(cls) >> >> def __init__(self, price): >> pass > [snip] > > Of course, maybe you don't need to define a __new__ method at all. > Personally, I find that __init__ suffices for my simple needs. > I tend to need __init__ on about half of the classes I write. I think I've needed __new__ all of twice in the years I've been writing Python. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
Steven D'Aprano :
> In this case, "same object" carries the normal English meaning of
> "same" and the normal computer science meaning of "object" in the
> sense of "Object Oriented Programming". There's no mystery here, no
> circular definition.
I see three possible ways of defining "is" / object identity (and other
concepts):
1. hand waving ("normal English")
2. reduction to an underlying model (a real / conceptual computer)
3. formal semantics
All methods are in use. Experienced programmers have #2 in mind but are
embarrassed to admit they understand Python through C. Thus, they offer
explanation #1 to newbies, who are too embarrassed to admit they don't
get the explanation.
I think #3 could be tried more often. It is analogous to providing the
BNF of Python's syntax (which *is* done: https://docs.python.org/3/reference/grammar.html>).
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: What arguments are passed to the __new__ method ?
On Wed, Mar 2, 2016 at 10:57 AM, Rob Gaddi wrote: > Peter Pearson wrote: > >> On Tue, 1 Mar 2016 18:24:12 +0100, ast wrote: >>> >>> It's not clear to me what arguments are passed to the >>> __new__ method. Here is a piece of code: >>> >>> >>> class Premiere: >>> >>> def __new__(cls, price): >>> return object.__new__(cls) >>> >>> def __init__(self, price): >>> pass >> [snip] >> >> Of course, maybe you don't need to define a __new__ method at all. >> Personally, I find that __init__ suffices for my simple needs. >> > > I tend to need __init__ on about half of the classes I write. I think > I've needed __new__ all of twice in the years I've been writing Python. Typically there are only two reasons to override __new__: you potentially want to return an object of a different class than the class that was called, or you're subclassing an immutable type and need to handle the superclass arguments before they get passed to the constructor. -- https://mail.python.org/mailman/listinfo/python-list
Re: Speaking of Javascript [was Re: Everything good about Python except GUI IDE?]
On 2016-03-02, Chris Angelico wrote: > To be fair, this isn't a JS exploit; it's a trusting-of-trust issue - > eBay has declared that you can trust them to sanitize their sellers' > listings, and so you trust eBay, but this exploit gets past the > filter. This is true. It sounds like their filter is frankly bizarre, I can't imagine why it works the way that has been described. > You're no more vulnerable looking at one of those listings > than you would be going to a web site entirely controlled by the > attacker, save that (particularly on mobile devices) there are a lot > of people out there who'll say "Oh, it'e eBay, I'm safe". This however I don't think is true at all. eBay already has a great deal of data about its customers, if an attacker can hijack sessions and steal this data just from a user visiting a listings page then that isn't anything like visiting a random malicious site. -- https://mail.python.org/mailman/listinfo/python-list
Continuing indentation
Running flake8 over some code which has if statements with multiple conditions like this: if (some_condition and some_other_condition and some_final_condition): play_bingo() the tool complains that the indentation of the conditions is the same as the next block. In this particular case, the overall conditions are too long to string together on a single line. I tried placing a second space after the if keyword: if (some_condition and some_other_condition and some_final_condition): play_bingo() which solves the matching indentation problem, but creates a multiple spaces after keyword problem. My guess is that adding a space after the open paren would provoke a message as well. I use GNU Emacs as my text editor, and its python mode. I'm pretty happy with everything (been using it in its current state for several years). Aside from manually or configure-ologically suppressing E129, is there a better way to break lines I'm missing which will make flake8 happy? Thx, Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
Skip Montanaro : > Running flake8 over some code which has if statements with multiple > conditions like this: > > if (some_condition and > some_other_condition and > some_final_condition): > play_bingo() > [...] > > is there a better way to break lines I'm missing which will make > flake8 happy? This is the idiomatic way: if some_condition and \ some_other_condition and \ some_final_condition: play_bingo() Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Speaking of Javascript [was Re: Everything good about Python except GUI IDE?]
On Thu, Mar 3, 2016 at 5:29 AM, Jon Ribbens wrote: > On 2016-03-02, Chris Angelico wrote: >> To be fair, this isn't a JS exploit; it's a trusting-of-trust issue - >> eBay has declared that you can trust them to sanitize their sellers' >> listings, and so you trust eBay, but this exploit gets past the >> filter. > > This is true. It sounds like their filter is frankly bizarre, > I can't imagine why it works the way that has been described. Agreed. I also don't understand why they can't simply say "no
Re: Continuing indentation
On 3/2/2016 21:43, Skip Montanaro wrote: Running flake8 over some code which has if statements with multiple conditions like this: if (some_condition and some_other_condition and some_final_condition): play_bingo() the tool complains that the indentation of the conditions is the same as the next block. In this particular case, the overall conditions are too long to string together on a single line. I tried placing a second space after the if keyword: if (some_condition and some_other_condition and some_final_condition): play_bingo() which solves the matching indentation problem, but creates a multiple spaces after keyword problem. My guess is that adding a space after the open paren would provoke a message as well. I use GNU Emacs as my text editor, and its python mode. I'm pretty happy with everything (been using it in its current state for several years). Aside from manually or configure-ologically suppressing E129, is there a better way to break lines I'm missing which will make flake8 happy? I don't know about flake8, but pep8 says all these are acceptable though the first version (like yours) has the readability problem flake8 complains about: # No extra indentation. if (this_is_one_thing and that_is_another_thing): do_something() # Add a comment, which will provide some distinction in editors # supporting syntax highlighting. if (this_is_one_thing and that_is_another_thing): # Since both conditions are true, we can frobnicate. do_something() # Add some extra indentation on the conditional continuation line. if (this_is_one_thing and that_is_another_thing): do_something() Maybe version 2 would make the tool happy? -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
Skip Montanaro wrote: > Running flake8 over some code which has if statements with multiple > conditions like this: > > if (some_condition and > some_other_condition and > some_final_condition): > play_bingo() > > the tool complains that the indentation of the conditions is the same > as the next block. In this particular case, the overall conditions > are too long to string together on a single line. I tried placing a > second space after the if keyword: > > if (some_condition and > some_other_condition and > some_final_condition): > play_bingo() > > which solves the matching indentation problem, but creates a multiple > spaces after keyword problem. My guess is that adding a space after > the open paren would provoke a message as well. > > I use GNU Emacs as my text editor, and its python mode. I'm pretty > happy with everything (been using it in its current state for several > years). Aside from manually or configure-ologically suppressing E129, > is there a better way to break lines I'm missing which will make > flake8 happy? Manually inspecting the output of $ cd /usr/lib/python3.4 $ find . -name \*.py -print0 | xargs -0 egrep 'if \([^:]+$' --color -A3 [...] gives the impression that those who do care are a minority and that the most common workaround is an extra indent of four spaces. -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
Skip Montanaro writes: > Running flake8 over some code which has if statements with multiple > conditions like this: > > if (some_condition and > some_other_condition and > some_final_condition): > play_bingo() > > the tool complains that the indentation of the conditions is the same > as the next block. For this reason I prefer to indent all continuation lines 8 spaces:: if ( some_condition and some_other_condition and some_final_condition): play_bingo() > I use GNU Emacs as my text editor, and its python mode. I'm pretty > happy with everything (been using it in its current state for several > years). Aside from manually or configure-ologically suppressing E129, > is there a better way to break lines I'm missing which will make > flake8 happy? The style I recommend above is PEP 8 compliant, easy to read, remember, and apply. -- \ “This [Bush] Administration is not sinking. This Administration | `\ is soaring. If anything they are rearranging the deck chairs on | _o__) the Hindenburg.” —Steven Colbert, 2006-04-29 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
On 02/03/2016 17:23, Steven D'Aprano wrote: On Thu, 3 Mar 2016 01:11 am, Marko Rauhamaa wrote: What is missing is the rules that are obeyed by the "is" operator. I think what is actually missing is some common bloody sense. The Python docs are written in English, and don't define *hundreds*, possible *thousands* of words because they are using their normal English meaning. The docs for `is` say: 6.10.3. Identity comparisons The operators is and is not test for object identity: x is y is true if and only if x and y are the same object. x is not y yields the inverse truth value. https://docs.python.org/3/reference/expressions.html#is-not In this case, "same object" carries the normal English meaning of "same" and the normal computer science meaning of "object" in the sense of "Object Oriented Programming". There's no mystery here, no circular definition. Are we discussing UK (highly generalised), Geordie, Glaswegian, US, Canadian, South African, Australian, New Zealand, or some other form of English? -- 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: Explaining names vs variables in Python
On Thu, Mar 3, 2016 at 8:49 AM, Mark Lawrence wrote: > Are we discussing UK (highly generalised), Geordie, Glaswegian, US, > Canadian, South African, Australian, New Zealand, or some other form of > English? Is there any disagreement among them about the word "same"? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
On 03/02/2016 12:50 PM, Marko Rauhamaa wrote: Skip Montanaro queried: Running flake8 over some code which has if statements with multiple conditions like this: if (some_condition and some_other_condition and some_final_condition): play_bingo() [...] is there a better way to break lines I'm missing which will make flake8 happy? This is the idiomatic way: if some_condition and \ some_other_condition and \ some_final_condition: play_bingo() No, it isn't. Using '\' for line continuation is strongly discouraged. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
looking into python...
"Python code can be packaged into stand-alone executable programs for some of the most popular operating systems, allowing the distribution of Python-based software for use on those environments without requiring the installation of a Python interpreter." (wikipedia) How correct is that? Which "most popular operating systems" are those? Is there a good site to read for a quick overview of how one would use python with a qt binding to write some GUI utilities? Thanks. -- http://totally-portable-software.blogspot.com [Mon Feb 29: "Addresses - What Good Are They?"] -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything good about Python except GUI IDE?
Am 02.03.16 um 09:20 schrieb Marko Rauhamaa:
Chris Angelico :
On Wed, Mar 2, 2016 at 4:41 PM, Marko Rauhamaa wrote:
I was talking about JSON for the standard I/O, not the command-line
arguments, as in:
ps -ef | awk '/httpd/ { print $2 }'
where "ps -ef" emits SPC-separated fields and LF-separated records, and
awk parses and processes them.
If you want to change that, you have to change the entire ecosystem,
not just the shell. You would have to teach every single program to
use a different structure.
Correct. There could be translation utilities in the interim.
A lot of programs already do support NUL-separation - usually with a
-z parameter or something. But you won't be able to magically get them
all to use JSON. And I doubt it would be advantageous anyway.
The advantages are obvious. Barely any programs do proper escaping, and
security problems abound.
Have a look at PowerShell. It's not Python, and it is from MS - but it
works along those lines, passing .NET objects through the pipe. Owing to
that, instead of $2=="something" in the awk progra, you can address the
field(attribute) $2 by the correct name instead of a positional argument.
Christian
Caveat emptor: never used it myself
--
https://mail.python.org/mailman/listinfo/python-list
Re: Speaking of Javascript [was Re: Everything good about Python except GUI IDE?]
On 2016-03-02, Chris Angelico wrote: > On Thu, Mar 3, 2016 at 5:29 AM, Jon Ribbens > wrote: >> On 2016-03-02, Chris Angelico wrote: >>> You're no more vulnerable looking at one of those listings >>> than you would be going to a web site entirely controlled by the >>> attacker, save that (particularly on mobile devices) there are a lot >>> of people out there who'll say "Oh, it'e eBay, I'm safe". >> >> This however I don't think is true at all. eBay already has a great >> deal of data about its customers, if an attacker can hijack sessions >> and steal this data just from a user visiting a listings page then >> that isn't anything like visiting a random malicious site. > > Hmm, maybe. But the description of the exploit talks of getting people > to click a button to install an app, which is something anyone could > do with full control of a web site; I think that's just a proof-of-concept sort of thing. There's much more interesting things you can do than put up "download this exe and run it" pop-ups if you can run arbitrary javascript in someone else's domain. > the value (to the attacker) of exploiting the eBay filter limitation > is that it slips it into an otherwise-trusted web site (both from > the human's point of view -"this is eBay, it's fine" - and from a > machine filter's - "yes, this is the same site you thought you were > on"). You can of course just register egay.com (or whatever) and hope for the best (including putting an SSL cert on it). -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
Ethan Furman : > No, it isn't. Using '\' for line continuation is strongly discouraged. Why would you discourage valid syntax? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: looking into python...
crankypuss writes: > "Python code can be packaged into stand-alone executable programs for > some of the most popular operating systems, allowing the distribution of > Python-based software for use on those environments without requiring > the installation of a Python interpreter." (wikipedia) > > How correct is that? Which "most popular operating systems" are > those? Python's web site covers this. The Python environment is available for download https://www.python.org/downloads/> for all major operating systems. Python is used in a huge range of fields, in organisations large and small https://www.python.org/about/success/>. > Is there a good site to read for a quick overview of how one would use > python with a qt binding to write some GUI utilities? GUI programming is covered at the Python wiki https://wiki.python.org/moin/GUI%20Programming%20in%20Python>. -- \ “I prayed for twenty years but received no answer until I | `\ prayed with my legs.” —Frederick Douglass, escaped slave | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything good about Python except GUI IDE?
Christian Gollwitzer : > Have a look at PowerShell. It's not Python, and it is from MS - but it > works along those lines, passing .NET objects through the pipe. Owing > to that, instead of $2=="something" in the awk progra, you can address > the field(attribute) $2 by the correct name instead of a positional > argument. Requirements for what I have in mind: 1. It would have to be and feel like real Python. 2. External commands should be available as callable Python functions. 3. Functions/commands should return streams. (Generators, maybe?) 4. Pipelines should have an intuitive syntax (but still be valid Python). Requirements 3 and 4 apply to regular Python code as well. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
Thanks for the replies, folks. I'll provide a single response: 1. Using backslash to continue... When I first started using Python in the mid-90s I don't recall that parenthesized expressions could be continued across lines (at least, not in all contexts), so the backslash was required. I believe the parser change necessary to support ( ... \n ... ) in all contexts was added precisely to minimize the need for backslashes as continuation. 2. Changing the indentation of the continued lines... My brain thinks the right thing to do is to what it currently does (line up continued lines inside the indentation in the column following the left paren, so I'm really not interested in using (\n or other variations which allow me to fool the Python mode auto-indent feature. I'm pretty sure the XEmacs python-mode.el did things the same way. A quick peek at python.el didn't indicate an obvious way to change that offset to something other than the default indentation. This is Emacs though. No doubt there is a way. Since I like the current behavior, I'm not inclined to go out of my way to figure it out. 3. Adding a comment... I do that where a comment is necessary, but it doesn't suppress the error message. I don't know. Maybe I need to ask the flake8 author about his rationale for this message. It seems to me from my experience with the language that this particular message is going against pretty common practice. Does vim's Python mode exhibit similar behavior by default? What about other editors/IDEs? Thx, Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
On 03/02/2016 02:10 PM, Marko Rauhamaa wrote: Ethan Furman : No, it isn't. Using '\' for line continuation is strongly discouraged. Why would you discourage valid syntax? 1) It's ugly 2) Any non-newline whitespace after the '\' and you don't have line continuation any more, and no visible way to notice. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
On 02/03/2016 21:52, Chris Angelico wrote: On Thu, Mar 3, 2016 at 8:49 AM, Mark Lawrence wrote: Are we discussing UK (highly generalised), Geordie, Glaswegian, US, Canadian, South African, Australian, New Zealand, or some other form of English? Is there any disagreement among them about the word "same"? ChrisA How the hell would I know? Have you ever tried speaking to a Glaswegian or a Geordie? -- 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: Continuing indentation
On 03/02/2016 02:44 PM, Skip Montanaro wrote: I don't know. Maybe I need to ask the flake8 author about his rationale for this message. It seems to me from my experience with the language that this particular message is going against pretty common practice. Does vim's Python mode exhibit similar behavior by default? What about other editors/IDEs? My vim mode indents an extra four spaces when continuing lines (so eight total), and dedents back four after the ): (which does line up with the extra-indented conditions, but with the original condition). I find the different indentation levels for conditions version body to be very helpful. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
tkFileDialog Question
Is there a way to prevent the dialog from displaying hidden directories? My research has not found anything relating to hidden files or directories. -- GNU/Linux user #557453 "Philosophy is common sense with big words." -James Madison -- https://mail.python.org/mailman/listinfo/python-list
Re: How to know if an object is still be referenced?
On Wednesday, March 2, 2016 at 3:35:32 AM UTC-8, jf...@ms4.hinet.net wrote:
> Terry Reedy at 2016/3/2 UTC+8 3:04:10PM wrote：
> > On 3/1/2016 9:35 PM, jf...@ms4.hinet.net wrote:
> > > Recently I was puzzled by a tkinter problem. The codes below (from a
> > > book) can display the picture correctly.
> > >
> > > gifdir = "../gifs/"
> > > from tkinter import *
> > > win = Tk()
> > > photo = PhotoImage(file=gifdir + "ora-pp.gif")
> > > Button(win, image=photo).pack()
> > > win.mainloop()
> >
> > Since photo is a global name, the binding remain until you explicitly
> > delete it or exit the app.
> >
> > > And the codes below (from another book) will also work.
> > >
> > > class DrumMachine:
> > >
> > >
> > > def create_play_bar(self):
> > >
> > >
> > > photo = PhotoImage(file='images/signature.gif')
> > > label = Label(playbar_frame, image=photo)
> > > label.image = photo
> > > label.grid(row=start_row, column=50, padx=1, sticky='w')
> > >
> > >
> >
> > Here photo is a local name and the binding disappears when the function
> > exits. I would rewrite it to follow pattern 1.
> >
> > self.photo = PhotoImage(file='images/signature.gif')
> > label = Label(playbar_frame, image=self.photo)
> >
> > To me, saving an attribute reference is not worth the extra line.
> >
> > > In the second example, I noticed that the "photo" was referenced two times
> > > and I think it might be a redundancy so I remove the line "label.image =
> > > photo". But it fails then.
> >
> > On another question, I made the same suggestion. Oops.
> >
> > --
> > Terry Jan Reedy
>
> Thanks, Terry. After reading your reply I noticed that I had make a mistake.
> The "image" is not an attribute of the Button. It's an option. The
> "label.image=photo" does a different thing. But it didn't help on solving my
> puzzle.
>
> If the problem was caused by the "photo" is a local, then binding the "photo"
> to an local attribute ("label" is a local too) seems no meaning at all. But
> it did make difference! No idea how the underneath mechanism works.
>
> I run this example under the pdb and it can display the picture correctly
> even without the "label.image=photo" statement. Why it fails on running at
> real time? tk event scheduling? I don't know.
>
> --Jach
"label" might be a local variable, but it's constructor includes a reference to
the frame in which it is going. The frame object will create a reference to
the newly-created Label object. At that point, there will be two references to
the new Label object. When the function exits and "label" goes out of scope,
the object still exists because the frame still has a reference.
If you're a C/C++ programmer, another way of thinking of it is imagining EVERY
variable is created on the heap, not the stack, and so it is safe to pass
around references to "local" variables, even when the function that creates it
exits.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
On Thu, Mar 3, 2016 at 9:10 AM, Marko Rauhamaa wrote: > Ethan Furman : > >> No, it isn't. Using '\' for line continuation is strongly discouraged. > > Why would you discourage valid syntax? > Isn't that exactly the point of style guides? They stipulate/encourage a particular subset of valid syntax, and decry/discourage another subset. If ugly code were not syntactically valid, the style guide wouldn't need to say anything. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote: > > if (some_condition and > some_other_condition and > some_final_condition): > play_bingo() How about: continue_playing = ( some_condition and some_other_condition and some_final_condition ) if continue_playing: play_bingo() or: play_conditions = [ some_condition, some_other_condition, some_final_condition, ] if all(play_conditions): play_bingo() Regards, Igor. -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
On Thu, Mar 3, 2016 at 10:46 AM, wrote: > On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote: >> >> if (some_condition and >> some_other_condition and >> some_final_condition): >> play_bingo() > > How about: > > continue_playing = ( > some_condition and > some_other_condition and > some_final_condition > ) > > if continue_playing: > play_bingo() > > or: > > play_conditions = [ > some_condition, > some_other_condition, > some_final_condition, > ] > > if all(play_conditions): > play_bingo() Those feel like warping your code around the letter of the law, without really improving anything. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
On 03/02/2016 04:54 PM, Chris Angelico wrote: > On Thu, Mar 3, 2016 at 10:46 AM, wrote: >> On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote: >>> >>> if (some_condition and >>> some_other_condition and >>> some_final_condition): >>> play_bingo() >> >> How about: >> >> continue_playing = ( >> some_condition and >> some_other_condition and >> some_final_condition >> ) >> >> if continue_playing: >> play_bingo() >> >> or: >> >> play_conditions = [ >> some_condition, >> some_other_condition, >> some_final_condition, >> ] >> >> if all(play_conditions): >> play_bingo() > > Those feel like warping your code around the letter of the law, > without really improving anything. Not at all! Taking a series of boolean-joined conditions and giving the combined condition a single name is often a major improvement in readability. Not primarily for code-layout reasons, but because it forces you to name the concept (e.g. "continue_playing" here.) I often find that the best answer to "how do I wrap this long line?" is "don't, instead extract a piece of it and give that its own name on its own line(s)." The extracted piece might be a new variable or even a new function. The pressure to do this type of refactor more frequently is one reason I continue to prefer relatively short (80 char) line length limits. This is closely related to the XP guideline "when you're tempted to add a comment, instead extract that bit of code into a function or variable and give it a name that clarifies the same thing the comment would have." Names are important! Carl signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
Chris Angelico writes: > On Thu, Mar 3, 2016 at 10:46 AM, wrote: >> On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote: >>> >>> if (some_condition and >>> some_other_condition and >>> some_final_condition): >>> play_bingo() >> >> How about: >> >> continue_playing = ( >> some_condition and >> some_other_condition and >> some_final_condition >> ) >> >> if continue_playing: >> play_bingo() >> >> or: >> >> play_conditions = [ >> some_condition, >> some_other_condition, >> some_final_condition, >> ] >> >> if all(play_conditions): >> play_bingo() > > Those feel like warping your code around the letter of the law, > without really improving anything. I beg to differ. If an expression is long or complex then splitting it up and, importantly, giving good names to the intermediates makes the code clearer. That advice is not restricted to if statements. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
(Igor, your “From” field doesn't contain a name for you. Can you put your name, e.g. “Igor Whateverisyoursurname”, in the “From” field?) codewiz...@gmail.com writes: > How about: > > continue_playing = ( > some_condition and > some_other_condition and > some_final_condition > ) > > if continue_playing: > play_bingo() > > or: > > play_conditions = [ > some_condition, > some_other_condition, > some_final_condition, > ] > > if all(play_conditions): > play_bingo() Yes, these are good. When a condition is too complex, it makes sense to assign a name to it. It can even help to pull out a coherent part of the complex condition and assign a name to that:: play_conditions = [ some_other_condition, some_extra_condition, (some and compound and condition)] if some_condition and all(play_conditions): play_bingo() -- \“Perchance you who pronounce my sentence are in greater fear | `\ than I who receive it.” —Giordano Bruno, burned at the stake by | _o__) the Catholic church for the heresy of heliocentrism, 1600-02-16 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
On Thursday, March 3, 2016 at 3:22:42 AM UTC+5:30, Chris Angelico wrote: > On Thu, Mar 3, 2016 at 8:49 AM, Mark Lawrence wrote: > > Are we discussing UK (highly generalised), Geordie, Glaswegian, US, > > Canadian, South African, Australian, New Zealand, or some other form of > > English? > > Is there any disagreement among them about the word "same"? So same is same But is is not is? IOW if we dont need to explain same why do we need to explain is? -- https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
On Thu, 3 Mar 2016 05:12 am, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> In this case, "same object" carries the normal English meaning of
>> "same" and the normal computer science meaning of "object" in the
>> sense of "Object Oriented Programming". There's no mystery here, no
>> circular definition.
>
> I see three possible ways of defining "is" / object identity (and other
> concepts):
>
>1. hand waving ("normal English")
>
>2. reduction to an underlying model (a real / conceptual computer)
>
>3. formal semantics
>
> All methods are in use. Experienced programmers have #2 in mind but are
> embarrassed to admit they understand Python through C. Thus, they offer
> explanation #1 to newbies, who are too embarrassed to admit they don't
> get the explanation.
There is no evidence that newbies "don't get the explanation". Completely
the opposite: newbies frequently find the behaviour of `is` mysterious[1]
*until* it is explained to them in terms of "same object", after which it
becomes clear. (At least for those who understand what "object" means in
OOP terms.)
And then the same two people, you and Rustom, come along and insist that the
docs don't define `is` correctly and raising irrelevant philosophical
objections. But there's no evidence that these issues are the least bit
relevant to the newbies who asked the questions in the first place.
> I think #3 could be tried more often.
I completely agree! It could be tried more often!
Other things that could be tried more often include:
- defining `is` through the medium of interpretive dance;
- defining `is` by wafting information-rich pheromones through the air;
- defining `is` by taking copious amounts of hallucinogens until your mind
becomes one with the universe and you intuitively understand everything.
But I think that in the case of Python, a combination of #1 and #2 are
needed.
(I think that nearly all people need to have some sort of concrete picture
in their heads for an object, even if they then go on to consciously reject
that picture as "just an implementation detail". Objects are not
necessarily C structs with a pointer back to a struct which represents the
object's class, but that's a common implementation.)
> It is analogous to providing the
> BNF of Python's syntax (which *is* done: https://docs.python.org/3/reference/grammar.html>).
BNF is for describing syntax, not semantics. Nobody has trouble with the
syntax of `is`, it is a simple binary operator. There is no analogous
BNF-equivalent for semantics.
[1] Usually because they are either interpreting it as a synonym for
equality, or because they are confused by Python's caching of small ints
and some strings.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Explaining names vs variables in Python
On Thu, 3 Mar 2016 08:49 am, Mark Lawrence wrote: > On 02/03/2016 17:23, Steven D'Aprano wrote: >> On Thu, 3 Mar 2016 01:11 am, Marko Rauhamaa wrote: >> >>> What is missing is the rules that are obeyed by the "is" operator. >> >> I think what is actually missing is some common bloody sense. The Python >> docs are written in English, and don't define *hundreds*, possible >> *thousands* of words because they are using their normal English meaning. >> >> The docs for `is` say: >> >> 6.10.3. Identity comparisons >> >> The operators is and is not test for object identity: x is y is true if >> and only if x and y are the same object. x is not y yields the inverse >> truth value. >> >> https://docs.python.org/3/reference/expressions.html#is-not >> >> In this case, "same object" carries the normal English meaning of "same" >> and the normal computer science meaning of "object" in the sense of >> "Object Oriented Programming". There's no mystery here, no circular >> definition. >> > > Are we discussing UK (highly generalised), Geordie, Glaswegian, US, > Canadian, South African, Australian, New Zealand, or some other form of > English? To the best of my knowledge, `is` has the same meaning in all variants of English (although there are sometimes differences in grammatical form, e.g. "this be that" versus "this is that"). It is a very old word, and such old words tend to have astonishingly stable semantics and irregular spelling. https://en.wiktionary.org/wiki/is#English https://en.wiktionary.org/wiki/be#English -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
On Thu, 3 Mar 2016 09:10 am, Marko Rauhamaa wrote: > Ethan Furman : > >> No, it isn't. Using '\' for line continuation is strongly discouraged. > > Why would you discourage valid syntax? Because it is error-prone and ugly. This is valid syntax too. Do you write your code like this? x = ++ ++ -- ++ -- --1 y = (2), 3 s = "Hello world!" . upper() -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
On Thu, 3 Mar 2016 11:02 am, Carl Meyer wrote: > On 03/02/2016 04:54 PM, Chris Angelico wrote: >> On Thu, Mar 3, 2016 at 10:46 AM, wrote: >>> On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote: if (some_condition and some_other_condition and some_final_condition): play_bingo() >>> >>> How about: >>> >>> continue_playing = ( >>> some_condition and >>> some_other_condition and >>> some_final_condition >>> ) >>> >>> if continue_playing: >>> play_bingo() >>> >>> or: >>> >>> play_conditions = [ >>> some_condition, >>> some_other_condition, >>> some_final_condition, >>> ] >>> >>> if all(play_conditions): >>> play_bingo() >> >> Those feel like warping your code around the letter of the law, >> without really improving anything. > > Not at all! Taking a series of boolean-joined conditions and giving the > combined condition a single name is often a major improvement in > readability. Not primarily for code-layout reasons, but because it > forces you to name the concept (e.g. "continue_playing" here.) If you only use "continue_playing" in exactly one place, then it doesn't deserve a name. You wouldn't write: the_index = x + 1 value = sequence[the_index] would you? > Names are important! Too important to waste on every single-use expression. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: [Off-topic] Requests author discusses MentalHealthError exception
On Thu, 3 Mar 2016 04:02 am, Rustom Mody wrote: > And how is [1]'s starting different from Kenneth's finding his weight > to be the weight of the universe? Is that a trick question? "How is a raven like a writing desk?" "Neither of them are made of cheese cake." We can be absolutely certain that Kenneth weighs less than the entire universe. We don't even need a set of scales. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
Steven D'Aprano writes: > If you only use "continue_playing" in exactly one place, then it > doesn't deserve a name. I disagree. If it's complex, then it may still deserve a name. > > Names are important! > > Too important to waste on every single-use expression. To waste on *every* single-use expression? Of course. No one was advocating that. The point is to bind a descriptive name to a *complex* expression, if doing so will clarify the semantic intent of that expression. If your functions are so long that you fear using a specific name will deter you from using it again *in the same scope*, then the name isn't descriptive and a better one should be chosen, or the function is too large and should be broken into smaller pieces. -- \ “The history of Western science confirms the aphorism that the | `\ great menace to progress is not ignorance but the illusion of | _o__)knowledge.” —Daniel J. Boorstin, historian, 1914–2004 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
On Thu, Mar 3, 2016 at 1:30 PM, Ben Finney wrote: > If your functions are so long that you fear using a specific name will > deter you from using it again *in the same scope*, then the name isn't > descriptive and a better one should be chosen, or the function is too > large and should be broken into smaller pieces. It's not just name collisions. You should be able to keep in your head every local name in a section of code. Giving a name to a single-use expression wastes one of those precious slots in your mind, even if it's easily and safely unique. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: [Off-topic] Requests author discusses MentalHealthError exception
On Thu, Mar 3, 2016 at 1:27 PM, Steven D'Aprano wrote: > We can be absolutely certain that Kenneth weighs less than the entire > universe. We don't even need a set of scales. Formal proof: 1) No physical object can have negative mass. 2) I am a part of the universe and have positive mass. 3) I am not Kenneth. 4) The sum of my mass and Kenneth's mass must exceed Kenneth's mass alone. Unless someone wants to dispute 1 or 2, we can be logically certain. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to know if an object is still be referenced?
sohca...@gmail.com at 2016/3/3 UTC+8 7:38:45AM wrote: > "label" might be a local variable, but it's constructor includes a reference > to the frame in which it is going. The frame object will create a reference > to the newly-created Label object. At that point, there will be two > references to the new Label object. When the function exits and "label" goes > out of scope, the object still exists because the frame still has a reference. > It sound reasonable enough:-) There is a page talking about why should keep a separate reference in tkinter. http://effbot.org/pyfaq/why-do-my-tkinter-images-not-appear.htm I also saw almost every code on the web about it was written in this way: label = Label(playbar_frame, image=photo) label.image = photo But why? Won't it be better if it was written as: label = Label(playbar_frame, image=photo) label.imgKeeper = photo At least it makes the meaning more clear, not lead someone to a wrong direction:-( Anyway, following Terry's suggestion might be a better idea, making it bind to an object which will live for as long as the application is. --Jach -- https://mail.python.org/mailman/listinfo/python-list
Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload())
On 3/2/2016 10:22 AM, Rustom Mody wrote: On Tuesday, March 1, 2016 at 12:23:02 PM UTC+5:30, Terry Reedy wrote: On 2/29/2016 7:42 AM, Rustom Mody wrote: Is import needed at all when trying out in Idle? ... So it does appear that 1. import not necessary with(in) idle 2. However import and f5 (ie is run as main) are different May some idle experts elaborate on this? Whats the idle idiom of import-ing? Rustom, since I know that you are not a rank beginner, I have trouble understanding what you are asking. Heh! I know some things; dont know many things F5 when editing foo.py is equivalent to running "python -i foo.py" on a command line while 'in' the directory containing foo.py. In both cases, foo.py is run as a main module, with __name__ == '__main__'. The difference is that F5 runs foo.py under IDLE supervision, with results going into and interactive inputs coming from IDLE shell instead of the console interpreter. Imports are used in a module to access objects within the imported module. Let me try to explain again There is import and import. There is the formal meaning of the import keyword in python -- call it import-f There is the informal expectation and need of programmers to 'pull something into python' -- call it import-i What do you mean by import-i that is different module import? Keyboard input with input()? File input with file.read(), etcetera? Running a file with 'python filename' or 'python -m filename'? That there is some cognitive dissonance between import-f and import-i is seen in the OP's question itself; The OP's question is faulty. Repeat imports *are* allowed. also Chris' "I dont believe the language should be changed" So the question is around: What is the best practice for doing import-i in python? Since I don't know what you mean by import-i, I cannot answer. As the OP finds import-f works once and fails thereafter This is false. Import is a name binding statement. If a module is not builtin, the first attempt to bind a name to a particular module has to create the module and cache it in sys.modules. If it is builtin, the first attempt caches the module. Subsequent attempts reuse the cached module. Here are three imports that involve the same module. All three run, none fail. >>> import itertools as it >>> import itertools as it2 >>> from itertools import count >>> it, it2, count (, , ) If you want to create and cache a new module of the same name, perhaps after editing a file, delete the cache entry before importing again. Reload does this for you. What it does not attempt to do is to change or delete all the old bindings and references. If one does plan to reload a module, then one should only access the module *and its contents* via one name and keep track of any other references to its contents, such as from instances to classes in the module. This may be easy for a simple module of functions, but in the general case, can be be difficult to impossible. In idle one can get the desired result of import-i with F5 Is that right? Having no idea what import-i is, I cannot answer. I explained F5 in my previous answer. Also in general is there good usecases for import-f at that interpreter prompt As I said before, the purpose of an import is to access the contents of module 2 from within module 1, where module1 can be the main module, including in interactive mode. A beginner experimenting with core python might proceed for hours without an import. Anyone experimenting with a module must import the module first. I usually import one or more modules in a given interactive session. > in idle? Whether the prompt is in a console text window or IDLE gui window is irrelevant. The IDLE Shell gui window imitates interactive python in a text console. It submits each statement entered to Python for execution and displays the stdout and stderr results. I think not but not sure of it Here is an example use of import for learning tkinter. >>> import tkinter as tk As expected, nothing visible happens. >>> root = tk.Tk() A default master windows is created *and displayed*. >>> b = tk.Button(root, text = 'hello world') Nothing visible happens. >>> b But an instance of the class was created. >>> b.grid() Button appears. Master window shrinks to fit. >>> t = tk.Toplevel(root) A new toplevel window appears. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
On 03/02/2016 06:33 PM, Chris Angelico wrote: It's not just name collisions. You should be able to keep in your head every local name in a section of code. Giving a name to a single-use expression wastes one of those precious slots in your mind, even if it's easily and safely unique. If it's a single-use name I stop remembering after its single use. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
On 2016-03-03 08:29, Ben Finney wrote: > Skip Montanaro writes: >> Running flake8 over some code which has if statements with >> multiple conditions like this: >> >> if (some_condition and >> some_other_condition and >> some_final_condition): >> play_bingo() > > For this reason I prefer to indent all continuation lines 8 spaces:: > > if ( > some_condition and > some_other_condition and > some_final_condition): > play_bingo() This is generally what I do with two modifications, (1) putting the conjunction at the beginning makes it easier for me to read, and (2) putting the close-paren and colon on their own line to make diffs cleaner when adding/removing conditions: if ( some_condition and some_other_condition and some_additional_condition ): play_bingo() making my diffs look like if ( some_condition and some_other_condition and some_additional_condition +and some_new_condition ): play_bingo() instead of if ( some_condition and some_other_condition -and some_additional_condition): +and some_additional_condition +and some_new_condition): play_bingo() which is harder to follow, IMHO. Though, as a side note, if I have lots of "and" or "or" conjunctions, I tend to use any() or all() on a list of them: if all([ some_condition, some_other_condition, some_additional_condition, +some_new_condition, ]): play_bingo() which I happen to find even tidier (though it might come at a minor performance penalty, having not tested it since it's never mattered in my code) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: [Off-topic] Requests author discusses MentalHealthError exception
On Thursday, March 3, 2016 at 7:59:13 AM UTC+5:30, Steven D'Aprano wrote: > On Thu, 3 Mar 2016 04:02 am, Rustom Mody wrote: > > > And how is [1]'s starting different from Kenneth's finding his weight > > to be the weight of the universe? > > Is that a trick question? > > "How is a raven like a writing desk?" > > "Neither of them are made of cheese cake." > > We can be absolutely certain that Kenneth weighs less than the entire > universe. We don't even need a set of scales. No trick William Blake starts Auguries of Innocence with: To see a world in a grain of sand, And a heaven in a wild flower, Hold infinity in the palm of your hand, And eternity in an hour. Reading the whole at http://www.artofeurope.com/blake/bla3.htm would make this discussion less academic Kenneth (at some point) felt he had the mass of the universe. So you can choose (one/some of) 1. Kenneth is like Blake 2. Blake is a lunatic 3. Standards of lunacy differ from 17th century to now Likewise... On Thursday, March 3, 2016 at 8:05:27 AM UTC+5:30, Chris Angelico wrote: > On Thu, Mar 3, 2016 at 1:27 PM, Steven D'Aprano wrote: > > We can be absolutely certain that Kenneth weighs less than the entire > > universe. We don't even need a set of scales. > > Formal proof: > > 1) No physical object can have negative mass. > 2) I am a part of the universe and have positive mass. > 3) I am not Kenneth. > 4) The sum of my mass and Kenneth's mass must exceed Kenneth's mass alone. What do physical objects have to do with Kenneth's experience? For you (Chris) you may (choose to) see Kenneth that way Kenneth (at least for a while) got out of that notion Forcing him back into that is what Larry calls "Forcing people into the status quo" Speaking for myself: I am certainly closer to the 'status quo" (most of the time at least) than Kenneth However I would not like to die How does one not die and still hold onto the belief that this 60 kg body is me? It may be instructive to take any religion of your choice (not necessarily 'new age') Focus on their starting/ending points You would, if you neglect the doctrinal/mythological/cultural gook inbetween, find something like this there invariably. You can reject this if you choose but then whats the talk of consensus when you reject the outlook of billions of people over millenia? -- https://mail.python.org/mailman/listinfo/python-list
Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload())
On Thursday, March 3, 2016 at 8:11:20 AM UTC+5:30, Terry Reedy wrote: > On 3/2/2016 10:22 AM, Rustom Mody wrote: > > On Tuesday, March 1, 2016 at 12:23:02 PM UTC+5:30, Terry Reedy wrote: > >> On 2/29/2016 7:42 AM, Rustom Mody wrote: > >> > >>> Is import needed at all when trying out in Idle? > >> ... > >>> So it does appear that > >>> 1. import not necessary with(in) idle > >>> 2. However import and f5 (ie is run as main) are different > >>> > >>> May some idle experts elaborate on this? Whats the idle idiom of > >>> import-ing? > >> > >> Rustom, since I know that you are not a rank beginner, I have trouble > >> understanding what you are asking. > > > > Heh! > > I know some things; dont know many things > > > >> F5 when editing foo.py is equivalent > >> to running "python -i foo.py" on a command line while 'in' the directory > >> containing foo.py. In both cases, foo.py is run as a main module, with > >> __name__ == '__main__'. The difference is that F5 runs foo.py under > >> IDLE supervision, with results going into and interactive inputs coming > >> from IDLE shell instead of the console interpreter. > >> > >> Imports are used in a module to access objects within the imported module. > > > > Let me try to explain again > > > > There is import and import. > > There is the formal meaning of the import keyword in python -- call it > > import-f > > There is the informal expectation and need of programmers to 'pull something > > into python' -- call it import-i > > What do you mean by import-i that is different module import? Keyboard > input with input()? File input with file.read(), etcetera? Running a > file with 'python filename' or 'python -m filename'? I define something... either with def foo()... or x = ... I want to see what foo does/what x is I want to check that my understanding of these matches python's representation of the same. I could keep typing the the def foo()... but that can get painful quickly So I put these in a file... And import! At this point I am pleased Because what I expect of import (import-i) and what python does with the import keyword (import-f) match... seemingly Until I go and change the def in the file and run the import again Fails Restart python -- works > > > That there is some cognitive dissonance between import-f and import-i is > > seen > > in the OP's question itself; > > The OP's question is faulty. Repeat imports *are* allowed. > > > also Chris' "I dont believe the language should be changed" > > > > So the question is around: > > What is the best practice for doing import-i in python? > > Since I don't know what you mean by import-i, I cannot answer. > > > As the OP finds import-f works once and fails thereafter > > This is false. Import is a name binding statement. If a module is not > builtin, the first attempt to bind a name to a particular module has to > create the module and cache it in sys.modules. If it is builtin, the > first attempt caches the module. Subsequent attempts reuse the cached > module. Here are three imports that involve the same module. All three > run, none fail. > > >>> import itertools as it > >>> import itertools as it2 > >>> from itertools import count > >>> it, it2, count > (, , > ) > > If you want to create and cache a new module of the same name, perhaps > after editing a file, delete the cache entry before importing again. > Reload does this for you. What it does not attempt to do is to change or > delete all the old bindings and references. > > If one does plan to reload a module, then one should only access the > module *and its contents* via one name and keep track of any other > references to its contents, such as from instances to classes in the > module. This may be easy for a simple module of functions, but in the > general case, can be be difficult to impossible. > > > In idle one can get the desired result of import-i with F5 > > Is that right? > > Having no idea what import-i is, I cannot answer. I explained F5 in my > previous answer. > > > Also in general is there good usecases for import-f at that interpreter > > prompt > > As I said before, the purpose of an import is to access the contents of > module 2 from within module 1, where module1 can be the main module, > including in interactive mode. A beginner experimenting with core > python might proceed for hours without an import. Anyone experimenting > with a module must import the module first. I usually import one or > more modules in a given interactive session. > > > in idle? > > Whether the prompt is in a console text window or IDLE gui window is > irrelevant. The IDLE Shell gui window imitates interactive python in a > text console. It submits each statement entered to Python for execution > and displays the stdout and stderr results. > > > I think not but not sure of it > > Here is an example use of import for learning tkinter. > > >>> import tkinter as tk > > As expected, nothing vis
Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload())
On Thursday, March 3, 2016 at 9:38:11 AM UTC+5:30, Rustom Mody wrote: > On Thursday, March 3, 2016 at 8:11:20 AM UTC+5:30, Terry Reedy wrote: > > On 3/2/2016 10:22 AM, Rustom Mody wrote: > > > On Tuesday, March 1, 2016 at 12:23:02 PM UTC+5:30, Terry Reedy wrote: > > >> On 2/29/2016 7:42 AM, Rustom Mody wrote: > > >> > > >>> Is import needed at all when trying out in Idle? > > >> ... > > >>> So it does appear that > > >>> 1. import not necessary with(in) idle > > >>> 2. However import and f5 (ie is run as main) are different > > >>> > > >>> May some idle experts elaborate on this? Whats the idle idiom of > > >>> import-ing? > > >> > > >> Rustom, since I know that you are not a rank beginner, I have trouble > > >> understanding what you are asking. > > > > > > Heh! > > > I know some things; dont know many things > > > > > >> F5 when editing foo.py is equivalent > > >> to running "python -i foo.py" on a command line while 'in' the directory > > >> containing foo.py. In both cases, foo.py is run as a main module, with > > >> __name__ == '__main__'. The difference is that F5 runs foo.py under > > >> IDLE supervision, with results going into and interactive inputs coming > > >> from IDLE shell instead of the console interpreter. > > >> > > >> Imports are used in a module to access objects within the imported > > >> module. > > > > > > Let me try to explain again > > > > > > There is import and import. > > > There is the formal meaning of the import keyword in python -- call it > > > import-f > > > There is the informal expectation and need of programmers to 'pull > > > something > > > into python' -- call it import-i > > > > What do you mean by import-i that is different module import? Keyboard > > input with input()? File input with file.read(), etcetera? Running a > > file with 'python filename' or 'python -m filename'? > > I define something... either with > def foo()... > or > x = ... > > I want to see what foo does/what x is > I want to check that my understanding of these matches python's representation > of the same. > I could keep typing the the > def foo()... > but that can get painful quickly > > So I put these in a file... > And import! > > At this point I am pleased > Because what I expect of import (import-i) > and what python does with the import keyword (import-f) match... seemingly > > Until I go and change the def in the file and run the import again > Fails > Restart python -- works Just to be clear, I dont believe the problem is with import-f per se It is with overloading python to be both scripting engine and interactive interpreter. Both ruby and haskell find it expedient to separate the two Ruby has irb and ruby Haskell has ghc (compiler), runhaskell (scripting) ghci (interpreter) -- https://mail.python.org/mailman/listinfo/python-list
Inception
Is it possible to embed CPython in CPython, e.g. using ctypes, cffi, or cython? -- https://mail.python.org/mailman/listinfo/python-list
Re: Inception
Denis Akhiyarov writes: > Is it possible to embed CPython in CPython, e.g. using ctypes, cffi, > or cython? I don't know what you mean by “embed” in this context. What would qualify as “yes” for you? -- \“You don't change the world by placidly finding your bliss — | `\you do it by focusing your discontent in productive ways.” | _o__) —Paul Z. Myers, 2011-08-31 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Inception
Ben Finney writes: > Denis Akhiyarov writes: > > > Is it possible to embed CPython in CPython, e.g. using ctypes, cffi, > > or cython? > > I don't know what you mean by “embed” in this context. What would > qualify as “yes” for you? Here is CPython embedded in CPython:: >>> import subprocess >>> subprocess.check_call(["python3", "--version"]) Python 3.5.1+ If that doesn't impress you, then you'll need to be more specific about what you're expecting. -- \“If the arguments in favor of atheism upset you, explain why | `\they’re wrong. If you can’t do that, that’s your problem.” | _o__) —Amanda Marcotte, 2015-02-13 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Inception
Embed using C-API from ctypes, cffi or cython, but not using subprocesses. Thanks for asking! Here is link to official documentation about embedding: https://docs.python.org/3.6/extending/index.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Inception
Denis Akhiyarov writes: > Embed using C-API from ctypes, cffi or cython, but not using > subprocesses. Thanks for asking! I'm glad you appreciate my asking, but I am no closer to an answer. What would meet your requirements, what would be a “yes” for you? > Here is link to official documentation about embedding: > https://docs.python.org/3.6/extending/index.html I'm familiar with that document. It doesn't help me understand what you mean by “embed CPython in CPython”. -- \“I went to the hardware store and bought some used paint. It | `\ was in the shape of a house.” —Steven Wright | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Inception
On Thursday, March 3, 2016 at 11:13:58 AM UTC+5:30, Denis Akhiyarov wrote: > Embed using C-API from ctypes, cffi or cython, but not using subprocesses. > Thanks for asking! > > Here is link to official documentation about embedding: > > https://docs.python.org/3.6/extending/index.html Nowadays its fashionable to talk of the "xy problem" http://code.tutsplus.com/tutorials/what-is-the-xy-problem-and-why-is-it-bad--cms-21023 ie you really need y but only know how to ask for x. Maybe you need to back off from python... docs/apis/jargon etc And tell us at a higher level WHAT you want and leave it to others to come up with HOWs [Disclaimer: Dont know that much about the extending API but if I remember right full-scale re-entrancy was considered and rejected] -- https://mail.python.org/mailman/listinfo/python-list
Re: Inception
Ben Finney writes: > I'm familiar with that document. It doesn't help me understand what you > mean by “embed CPython in CPython”. It seems straightforward enough to me. Lots of Python programs load C extensions. Denis is asking whether one of those C extensions could itself embed CPython through the embedding interface. My answer: I don't know, but I'm dubious about the prospect, based on how the embedding interface works. One of Armin Ronacher's old blog posts discusses the interface and some of its drawbacks: http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/#the-damn-interpreter It might be that MicroPython or PyPy is easier to embed in that way. -- https://mail.python.org/mailman/listinfo/python-list
Re: [Off-topic] Requests author discusses MentalHealthError exception
On Mar 2, 2016 9:01 PM, "Rustom Mody" wrote: > > On Thursday, March 3, 2016 at 7:59:13 AM UTC+5:30, Steven D'Aprano wrote: > > On Thu, 3 Mar 2016 04:02 am, Rustom Mody wrote: > > > > > And how is [1]'s starting different from Kenneth's finding his weight > > > to be the weight of the universe? > > > > Is that a trick question? > > > > "How is a raven like a writing desk?" > > > > "Neither of them are made of cheese cake." > > > > We can be absolutely certain that Kenneth weighs less than the entire > > universe. We don't even need a set of scales. > > No trick > > William Blake starts Auguries of Innocence with: > > To see a world in a grain of sand, > And a heaven in a wild flower, > Hold infinity in the palm of your hand, > And eternity in an hour. > > Reading the whole at http://www.artofeurope.com/blake/bla3.htm > would make this discussion less academic > > Kenneth (at some point) felt he had the mass of the universe. > > So you can choose (one/some of) > > 1. Kenneth is like Blake > 2. Blake is a lunatic > 3. Standards of lunacy differ from 17th century to now Please don't refer to the mentally ill as "lunatics". That's very insensitive. To answer your proposition, either Blake was also mentally ill, which does not preclude his poetry from being well regarded or important. Or, more likely, he was being metaphorical and did not believe these words to be literally true. > What do physical objects have to do with Kenneth's experience? There's no good reason to believe that there is anything other than the physical. Believing otherwise for no better reason than the incoherent experience of a demonstrably fallible human mind is indulging fantasy and delusion. > For you (Chris) you may (choose to) see Kenneth that way > Kenneth (at least for a while) got out of that notion > Forcing him back into that is what Larry calls > "Forcing people into the status quo" > > Speaking for myself: > I am certainly closer to the 'status quo" (most of the time at least) than > Kenneth > However I would not like to die > How does one not die and still hold onto the belief that this 60 kg body is me? Much as one might wish otherwise, one simply doesn't. Going back in the other direction, do you believe that you were never "born"? If not, how do you conceive yourself existing infinitely in one temporal direction and not the other? > It may be instructive to take any religion of your choice (not necessarily 'new age') > Focus on their starting/ending points > You would, if you neglect the doctrinal/mythological/cultural gook inbetween, > find something like this there invariably. > You can reject this if you choose but then whats the talk of consensus > when you reject the outlook of billions of people over millenia? Most of whom did not have the luxury of being born after the enlightenment and the advancement of science to denature them of superstition. -- https://mail.python.org/mailman/listinfo/python-list
Re: [Off-topic] Requests author discusses MentalHealthError exception
On Mon, 29 Feb 2016 23:29:43 + Mark Lawrence wrote: > On 29/02/2016 22:40, Larry Martell wrote: >> I think for the most part, the mental health industry is most >> interested in pushing drugs and forcing people into some status quo. > I am disgusted by your comments. I'll keep my original reply in reserve. Actually, if you view it by raw numbers, where depression makes up the bulk of the total number of mental problems, Larry's statement is true. Studies not performed by the industry shows that an un-medicated depression ends on average half a day later than one that's treated with some sort of SSRI. Disclaimer: I'm depressed myself, and I've taken an interest into the hows and whys of SSRI medications. -- //Wegge -- https://mail.python.org/mailman/listinfo/python-list
