Re: How to use asyncore with SSL?
Grant Edwards : > On 2018-01-20, Marko Rauhamaa wrote: >> Also, a subsidiary thread is not necessary. Everything can be done >> within an async framework (in C anyway). > > Of course it can. But (ISTM) either the async framework has to be > SSL-aware, or the sockets have to be wrapped and "proxied" using > another socket or pipe -- I don't see how else you can provide > something that has the same select/poll and send/recv semantacs that > an unwrapped, non-blocking socket provides. If you mean that user-space software can't create new file descriptor types, you would be painfully correct. The read(2) and write(2) (as well as recv(2) and send(2)) system calls necessarily cross into the kernel-space. User-space file descriptors can be emulated but generally that requires the use of auxiliary processes or threads. If you relax your requirement a bit and let the async framework define its own I/O methods, the magic becomes possible: you can make TLS an asynchronous drop-in replacement for TCP. (I suppose every async framework defines its own I/O methods.) If all you need is a file-descriptor-based notification scheme, Linux can manage that through epollfd, eventfd and timerfd. My async framework does not offer such a notification interface but instead uses callback functions. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Can't get python running
On 21 January 2018 at 01:53, Chris Angelico wrote: > On Sun, Jan 21, 2018 at 12:46 PM, Steven D'Aprano > wrote: >> On Sun, 21 Jan 2018 12:21:40 +1100, Chris Angelico wrote: >> >>> Jim, let the installer put it where it wants to, and make sure you've >>> added it to PATH. Then you should be able to type "py" to start Python. >> >> Shouldn't the installer ensure that it puts "py" somewhere on the path? >> > > Only if you tick the box to do that (or at least, that was the case a > few versions ago). You don't have to do it manually, but you do have > to make sure the box is ticked. (Which might just mean making sure you > don't UNtick it; I don't know what the default is.) The "py" launcher is always added to PATH. It's installed by default (and always has been I believe) although there is a checkbox you can untick if you don't want to install it. What's less reliable is whether the "python.exe" executable is on PATH. That's been on and off by default depending on the Python version, and is currently (3.6) off, for reasons to do with the precedence of the user and system parts of the PATH variable (which are important, but that's not much help to people who wish that after you installed Python, typing "python" at the command prompt would just work...) Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no functional xml?
Rustom Mody wrote:
> Looking around for how to create (l)xml one sees typical tutorials like
> this:
>
> https://www.blog.pythonlibrary.org/2013/04/30/python-101-intro-to-xml-parsing-with-elementtree/
>
>
>
> Given the requirement to build up this xml:
>
>
> 1181251680
> 04008200E000
> 1181572063
>
>
> 1800
> Bring pizza home
>
>
>
>
>
> the way I would rather do it is thus:
>
> [Note in actual practice the 'contents' such as 1181251680 etc would come
> from suitable program variables/function-calls
> ]
>
>
> ex = Ea("zAppointments", {'reminder':'15'},
> E("appointment",
> En("begin", 1181251680),
> Et("uid", "04008200E000"),
> En("alarmTime", 1181572063),
> E("state"),
> E("location"),
> En("duration",1800),
> Et("subject", "Bring pizza home")))
>
>
> with the following obvious definitions:
>
> [The function names are short so that the above becomes correspondingly
> [readable]
>
>
> from lxml.etree import Element
>
> def Ea(tag, attrib=None, *subnodes):
> "xml node constructor"
> root = Element(tag, attrib)
> for n in subnodes:
> root.append(n)
> return root
>
> def E(tag, *subnodes):
> "Like E but without attributes"
> root = Element(tag)
> for n in subnodes:
> root.append(n)
> return root
>
> def Et(tag, text):
> "A pure text node"
> root = E(tag)
> root.text = text
> return root
>
> def En(tag, text):
> "A node containing a integer"
> root = E(tag)
> root.text = str(text)
> return root
>
>
> This approach seems so obvious that I find it hard to believe its not
> there somewhere… Am I missing something??
lxml.objectify?
>>> from lxml import etree
>>> from lxml.objectify import E
>>> appointments = E.appointments(
... E.appointment(
... E.begin(1181251680),
... E.uid("04008200E000"),
... E.alarmTime(1181572063),
... E.state(),
... E.location(),
... E.duration(1800),
... E.subject("Bring pizza home")
... ),
... reminder="15"
... )
>>> print(etree.tostring(appointments, pretty_print=True, encoding=str))
http://codespeak.net/lxml/objectify/pytype";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; reminder="15">
1181251680
04008200E000
1181572063
1800
Bring pizza home
>>>
Personally I'd probably avoid the extra layer and write a function that
directly maps dataclasses or database records to xml using the conventional
elementtree API.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Can't get python running
On 21/01/18 02:52, Chris Angelico wrote: > On Sun, Jan 21, 2018 at 12:40 PM, bartc wrote: >> On 21/01/2018 01:21, Chris Angelico wrote: >>> >>> On Sun, Jan 21, 2018 at 12:08 PM, bartc wrote: On 20/01/2018 17:16, Jim Sadler wrote: > > > I downloaded python 3.6.4 and although everything about the installation > seems correct (path, file size, checking on cmd to see if file installed > correctly-it is) What do you mean by 'checking on cmd'? I would install it somewhere like c:\python364, then it is easier to find than having it buried in its default installation path (I assume this is Windows). >>> >>> >>> python36 is a better choice of name >> >> >> That's what I use; I assumed everyone else used the 3-digit version in the >> path. > > Terrible assumption, given that it's not the default NOR a good idea :) > >> , as it doesn't cause problems when >>> >>> you upgrade to a new bugfix release. But there are permissions issues >>> with dropping stuff straight into the root directory, which is why the >>> default installers now put Python into Program Files. >> >> >> It's not in the root, the executable will be: >> >> c:\python36\python.exe >> >> Not c:\python.exe. Yes, Windows allows you to have your own directories >> within /. It's not Unix. > > I meant putting the pythonXY directory straight into the root. Yes, > Windows allows it... but only if you are administrator. I think. AFAIK you also have to be administrator to install things in r"C:\Program Files". If you install something user-only, (which more software supports than many people think) it ends to somewhere in the user directory. I always thought that installing things in "Program Files" rather than the root directory was just good manners (just like installing things in /usr/local or /opt on GNU/Linux) > Depends on the Windows version. And just FYI, Unix allows you to have > your own directories within / too, so I don't know what your point is. > Both OSes - recent versions, at least - restrict the creation of > directories and files straight in the root. > >>> Jim, let the installer put it where it wants to, and make sure you've >>> added it to PATH. Then you should be able to type "py" to start >>> Python. >> >> >> If I try to install 3.7 (as I already have 3.6) it suggests putting it in: >> >> c:\Users\users\AppData\Local\Programs\Python\Python37-32 >> >> Not actually a snappy path if you need to get there in a hurry to sort out >> problems. That is, in a location 7 levels deep. >> >> Get it working anywhere first to find out what the problem is. >> > > Get it working in the default location before you change things. The > %PATH% environment variable exists to save you from typing seven > levels of directory names. > > ChrisA > -- https://mail.python.org/mailman/listinfo/python-list
Re: Can't get python running
On 21/01/2018 01:52, Chris Angelico wrote: On Sun, Jan 21, 2018 at 12:40 PM, bartc wrote: Get it working anywhere first to find out what the problem is. Get it working in the default location before you change things. The %PATH% environment variable exists to save you from typing seven levels of directory names. That's fine when everything works as it should. It's less ideal depending on %PATH% when trying to figure out what's gone wrong, as you don't know if it's set up properly, or whether the new path is appended or prepended to %PATH%, or whether there is some other py.exe or python.exe lurking in a search path that is checked first. Also, if you have a command prompt already open, then its %PATH% will not be updated. -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no functional xml?
On Sunday, January 21, 2018 at 4:51:34 PM UTC+5:30, Peter Otten wrote:
> Rustom Mody wrote:
>
> > Looking around for how to create (l)xml one sees typical tutorials like
> > this:
> >
> > https://www.blog.pythonlibrary.org/2013/04/30/python-101-intro-to-xml-parsing-with-elementtree/
> >
> >
> >
> > Given the requirement to build up this xml:
> >
> >
> > 1181251680
> > 04008200E000
> > 1181572063
> >
> >
> > 1800
> > Bring pizza home
> >
> >
> >
> >
> >
> > the way I would rather do it is thus:
> >
> > [Note in actual practice the 'contents' such as 1181251680 etc would come
> > from suitable program variables/function-calls
> > ]
> >
> >
> > ex = Ea("zAppointments", {'reminder':'15'},
> > E("appointment",
> > En("begin", 1181251680),
> > Et("uid", "04008200E000"),
> > En("alarmTime", 1181572063),
> > E("state"),
> > E("location"),
> > En("duration",1800),
> > Et("subject", "Bring pizza home")))
> >
> >
> > with the following obvious definitions:
> >
> > [The function names are short so that the above becomes correspondingly
> > [readable]
> >
> >
> > from lxml.etree import Element
> >
> > def Ea(tag, attrib=None, *subnodes):
> > "xml node constructor"
> > root = Element(tag, attrib)
> > for n in subnodes:
> > root.append(n)
> > return root
> >
> > def E(tag, *subnodes):
> > "Like E but without attributes"
> > root = Element(tag)
> > for n in subnodes:
> > root.append(n)
> > return root
> >
> > def Et(tag, text):
> > "A pure text node"
> > root = E(tag)
> > root.text = text
> > return root
> >
> > def En(tag, text):
> > "A node containing a integer"
> > root = E(tag)
> > root.text = str(text)
> > return root
> >
> >
> > This approach seems so obvious that I find it hard to believe its not
> > there somewhere… Am I missing something??
>
> lxml.objectify?
>
> >>> from lxml import etree
> >>> from lxml.objectify import E
> >>> appointments = E.appointments(
> ... E.appointment(
> ... E.begin(1181251680),
> ... E.uid("04008200E000"),
> ... E.alarmTime(1181572063),
> ... E.state(),
> ... E.location(),
> ... E.duration(1800),
> ... E.subject("Bring pizza home")
> ... ),
> ... reminder="15"
> ... )
> >>> print(etree.tostring(appointments, pretty_print=True, encoding=str))
> http://codespeak.net/lxml/objectify/pytype";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; reminder="15">
>
> 1181251680
> 04008200E000
> 1181572063
>
>
> 1800
> Bring pizza home
>
>
>
> >>>
Nice!
I almost liked it… Then noticed that the attribute dict is in the wrong place
Here's the same without any namespace malarky:
>>> E = objectify.ElementMaker(annotate=False,namespace=None,nsmap=None)
>>> appointments = E.appointments(
E.appointment(
E.begin(1181251680),
E.uid("04008200E000"),
E.alarmTime(1181572063),
E.state(),
E.location(),
E.duration(1800),
E.subject("Bring pizza home")
),
reminder="15"
)
>>> print(et.tostring(appointments,pretty_print=1).decode('ascii'))
1181251680
04008200E000
1181572063
1800
Bring pizza home
>>>
Its obviously easier in python to put optional/vararg parameters on the
right side rather than on the left of a parameter list.
But its not impossible to get it in the desired order — one just has to
'hand-parse' the parameter list received as a *param
Thusly:
appointments = E.appointments(
{"reminder":"15"},
E.appointment(
E.begin(1181251680),
E.uid("04008200E000"),
E.alarmTime(1181572063),
E.state(),
E.location(),
E.duration(1800),
E.subject("Bring pizza home")
)
)
>
> Personally I'd probably avoid the extra layer and write a function that
> directly maps dataclasses or database records to xml using the conventional
> elementtree API.
I dont understand…
[I find the OO/imperative style of making a half-done node and then throwing
piece-by-piece of contents in/at it highly aggravating]
--
https://mail.python.org/mailman/listinfo/python-list
