Re: matrix from matrix
My apologies for not providing enough information. I'll share my code attempt shortly. Cheers for your help :) Shei -- https://mail.python.org/mailman/listinfo/python-list
Python Error
Hi, I am unable to install Python on my system. After installing Python I get the below error when I try to open Python. [image: Inline image 1] Regards Girish -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Web Scrapping : Within href readonly those value that have href in it
To complement what Peter wrote: I'd approach this problem using
XPath. XPath is a query language for XML/HTML documents; it's a great
tool to have in your web scraping toolbox (among other tasks). With
Python's excellent lxml library you can do some XPath processing. Here's
how I might tackle this problem:
== [ scrape.py ] ==
from lxml import etree
# ...somehow get HTML/XML into the variable xml
root = etree.HTML(xml)
hrefs = root.xpath("//a[@href and starts-with(@href, 'http://')]/@href")
# magic => ^^
print(hrefs) # if you want to see what this looks like
== [ end scrape.py ] ==
The argument to the xpath method here is an XPath expression. The
overall form is:
//a[.]/@href
The '//a' at the beginning means: starting at the root node of the
document, find all a (anchor) elements that match the condition
specified by ".". The '/@href' at the end means: give me the href
attribute of the nodes (if any) that remain.
Looking inside the square brackets (what's known as the predicate in the
XPath world), we find
@href and starts-with(@href, 'http://')
The 'and' bit should be clear (there are two conditions that need to be
checked). The first part says: the a element should have an href
attribute. The second part says that the value of the href element had
better start with 'http://'.
In fact, we could simplify the predicate to
starts-with(@href, 'http://')
If an element does not even have an href attribute, its value does not
start with 'http://'. It's not an error, and no exception will be
thrown, when the XPath evaluator applies the starts-with function to an
a element that does not have an href attribute.
Hope this helps.
Best regards,
Jesse
--
Jesse Alama
http://xml.sh
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Error
On 1/16/2017 12:32 AM, Girish Khasnis wrote: Hi, I am unable to install Python on my system. After installing Python I get the below error when I try to open Python. [image: Inline image 1] Copy and paste the error message. This is text only list. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
RE: Sockets: IPPROTO_IP not supported
> Trying to sniff Ethernet packets, I do this: > >s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_IP) > > but it results in this: > > $ sudo python3 sniff_survey.py > Traceback (most recent call last): > File "sniff_survey.py", line 118, in > s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_IP) > File "/usr/lib/python3.2/socket.py", line 94, in __init__ > _socket.socket.__init__(self, family, type, proto, fileno) > socket.error: [Errno 93] Protocol not supported > > Anybody know what I'm doing wrong? (Python 3.2.3 under Debian 3.2.84-1.) Have a look at the bottom of this SO question: http://stackoverflow.com/questions/5385312/ipproto-ip-vs-ipproto-tcp-ipproto-udp -- https://mail.python.org/mailman/listinfo/python-list
ANN: Python Meeting Düsseldorf - 18.01.2017
[This announcement is in German since it targets a local user group meeting in Düsseldorf, Germany] ANKÜNDIGUNG Python Meeting Düsseldorf http://pyddf.de/ Ein Treffen von Python Enthusiasten und Interessierten in ungezwungener Atmosphäre. Mittwoch, 18.01.2017, 18:00 Uhr Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk Düsseldorfer Arcaden, Bachstr. 145, 40217 Düsseldorf Diese Nachricht ist auch online verfügbar: http://www.egenix.com/company/news/Python-Meeting-Duesseldorf-2017-01-18 NEUIGKEITEN * Bereits angemeldete Vorträge: Charlie Clark "Kurze Einführung in openpyxl und Pandas" Jochen Wersdörfer "CookieCutter" Marc-Andre Lemburg "Optimierung in Python mit PuLP" Weitere Vorträge können gerne noch angemeldet werden: i...@pyddf.de * Startzeit und Ort: Wir treffen uns um 18:00 Uhr im Bürgerhaus in den Düsseldorfer Arcaden. Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad und befindet sich an der Seite der Tiefgarageneinfahrt der Düsseldorfer Arcaden. Über dem Eingang steht ein großes "Schwimm' in Bilk" Logo. Hinter der Tür direkt links zu den zwei Aufzügen, dann in den 2. Stock hochfahren. Der Eingang zum Raum 1 liegt direkt links, wenn man aus dem Aufzug kommt. Google Street View: http://bit.ly/11sCfiw EINLEITUNG Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in Düsseldorf, die sich an Python Begeisterte aus der Region wendet: * http://pyddf.de/ Einen guten Überblick über die Vorträge bietet unser YouTube-Kanal, auf dem wir die Vorträge nach den Meetings veröffentlichen: * http://www.youtube.com/pyddf/ Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld, in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf: * http://www.egenix.com/ * http://www.clark-consulting.eu/ PROGRAMM Das Python Meeting Düsseldorf nutzt eine Mischung aus (Lightning) Talks und offener Diskussion. Vorträge können vorher angemeldet werden, oder auch spontan während des Treffens eingebracht werden. Ein Beamer mit XGA Auflösung steht zur Verfügung. (Lightning) Talk Anmeldung bitte formlos per EMail an i...@pyddf.de KOSTENBETEILIGUNG Das Python Meeting Düsseldorf wird von Python Nutzern für Python Nutzer veranstaltet. Um die Kosten zumindest teilweise zu refinanzieren, bitten wir die Teilnehmer um einen Beitrag in Höhe von EUR 10,00 inkl. 19% Mwst, Schüler und Studenten zahlen EUR 5,00 inkl. 19% Mwst. Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen. ANMELDUNG Da wir nur für ca. 20 Personen Sitzplätze haben, möchten wir bitten, sich per EMail anzumelden. Damit wird keine Verpflichtung eingegangen. Es erleichtert uns allerdings die Planung. Meeting Anmeldung bitte formlos per EMail an i...@pyddf.de WEITERE INFORMATIONEN Weitere Informationen finden Sie auf der Webseite des Meetings: http://pyddf.de/ Mit freundlichen Grüßen, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 16 2017) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ -- https://mail.python.org/mailman/listinfo/python-list
Re: A detailed description on virtualenv's packaging dependecies? (pip, easy_install, wheel, setuptools, distlib, etc.)
On Friday, 13 January 2017 09:27:21 UTC, haraldn...@gmail.com wrote: > I was working on a bugfix for Virtualenv, regarding very long shebang lines > that are breaking things. In the process, I realized that if I want really > fix to my particular issue it likely needs to be done on the lower level of > Python package management. I started with pip, moved to setuptools and now > set my sight on distlib. > > Can someone describe the specific dependencies of all the *packaging* > libraries that `virtualenv` uses? And the dependencies between them? > > I believe that virtualenv directly imports `pip`, `easy_install` and `wheel`. > Those in turn import `setuptools` and `distlib`. Am I so lucky as to assume > that distlib in the lowest-level library used by all the rest in virtualenv > for packages? I believe distlib is the lowest level. But I think you're looking at the problem wrongly. From the issue you reported, the problem you're hitting is that your OS limits the length of paths you can use in a "shebang" line, and the pathname for your virtualenv exceeds that limit. And as a result, script wrappers for Python modules installed in the virtualenv fail because the shebang line is too long. So it's not virtualenv creating the environment that needs to be fixed, but *anything* that installs wrappers that point to the environment Python with a shebang line (wherever they are installed to). By patching distlib, you'll catch the case of installing packages into the virtualenv using pip and distil (once they update distlib). But I don't think you will catch easy_install (which uses setuptools, which uses its own wrapper script) or setup.py install (which again most likely uses setuptools). And nothing will catch 3rd party tools that do their own thing. So if you want to try to minimise the impact of the OS limitation, you can patch both distlib and setuptools and probably get most things (actually, there's probably not much that doesn't use pip, so just patching distlib will probably get the majority of cases). You'll have to manually apply the workaround to any scripts you write yourself that you want to run with the virtualenv's Python. Or you can just accept the limitation and use shorter pathnames. If you're willing to accept the limitation, and it's possible to somehow determine from the OS what it allows, then getting virtualenv to warn if you use a "too long" pathname might be an alternative solution. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Running Virtualenv with a custom distlib?
On Friday, 13 January 2017 09:27:59 UTC, haraldn...@gmail.com wrote: > I want to do some development on `distlib`, and in the process run the code > via `virtualenv` which has distlib as a dependency. > > That is, not run the process inside a virtualenv, but run virtualenv's code > using a custom dependency. What are the steps I need to go through to achieve > this? > > It seems to me that normal package management (`pip`) is not possible here. virtualenv bundles a local copy of pip. And that pip in turn vendors distlib. So you'd need to build a new pip wheel with your customised version of distlib vendored in it, and then build virtualenv with that version of pip embedded. (You can avoid the last step by putting the new pip wheel in a virtualenv_embedded directory next to virtualenv.py, but you'd have to check the docs and maybe sources to ensure I remembered that right. Also your pip wheel would need to be a higher version than the embedded one, or it would get ignored). Paul -- https://mail.python.org/mailman/listinfo/python-list
Error handling in context managers
I generally use context managers for my SQL database connections, so I can just write code like: with psql_cursor() as cursor: And the context manager takes care of making a connection (or getting a connection from a pool, more likely), and cleaning up after the fact (such as putting the connection back in the pool), even if something goes wrong. Simple, elegant, and works well. The problem is that, from time to time, I can't get a connection, the result being that cursor is None, and attempting to use it results in an AttributeError. So my instinctive reaction is to wrap the potentially offending code in a try block, such that if I get that AttributeError I can decide how I want to handle the "no connection" case. This, of course, results in code like: try: with psql_cursor() as cursor: except AttributeError as e: I could also wrap the code within the context manager in an if block checking for if cursor is not None, but while perhaps a bit clearer as to the purpose, now I've got an extra check that will not be needed most of the time (albeit a quite inexpensive check). The difficulty I have with either of these solutions, however, is that they feel ugly to me - and wrapping the context manager in a try block almost seems to defeat the purpose of the context manager in the first place - If I'm going to be catching errors anyway, why not just do the cleanup there rather than hiding it in the context manager? Now don't get me wrong - neither of these issues is terribly significant to me. I'll happily wrap all the context manager calls in a try block and move on with life if that it in fact the best option. It's just my gut says "there should be a better way", so I figured I'd ask: *is* there a better way? Perhaps some way I could handle the error internally to the context manager, such that it just dumps me back out? Of course, that might not work, given that I may need to do something different *after* the context manager, depending on if I was able to get a connection, but it's a thought. Options? --- Israel Brewster Systems Analyst II Ravn Alaska 5245 Airport Industrial Rd Fairbanks, AK 99709 (907) 450-7293 --- -- https://mail.python.org/mailman/listinfo/python-list
Re: Error handling in context managers
On Tue, Jan 17, 2017 at 5:06 AM, Israel Brewster wrote: > I generally use context managers for my SQL database connections, so I can > just write code like: > > with psql_cursor() as cursor: > > > And the context manager takes care of making a connection (or getting a > connection from a pool, more likely), and cleaning up after the fact (such as > putting the connection back in the pool), even if something goes wrong. > Simple, elegant, and works well. > > The problem is that, from time to time, I can't get a connection, the result > being that cursor is None, and attempting to use it results in an > AttributeError. My question is: If you can't get a connection, why do you get back None? Wouldn't it be better for psql_cursor() to raise an exception? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Error handling in context managers
Israel Brewster wrote:
> I generally use context managers for my SQL database connections, so I can
> just write code like:
>
> with psql_cursor() as cursor:
>
>
> And the context manager takes care of making a connection (or getting a
> connection from a pool, more likely), and cleaning up after the fact (such
> as putting the connection back in the pool), even if something goes wrong.
> Simple, elegant, and works well.
>
> The problem is that, from time to time, I can't get a connection, the
> result being that cursor is None, and attempting to use it results in an
> AttributeError. So my instinctive reaction is to wrap the potentially
> offending code in a try block, such that if I get that AttributeError I
> can decide how I want to handle the "no connection" case. This, of course,
> results in code like:
>
> try:
> with psql_cursor() as cursor:
>
> except AttributeError as e:
>
>
> I could also wrap the code within the context manager in an if block
> checking for if cursor is not None, but while perhaps a bit clearer as to
> the purpose, now I've got an extra check that will not be needed most of
> the time (albeit a quite inexpensive check).
That seems to be the cleanest approach.
> The difficulty I have with either of these solutions, however, is that
> they feel ugly to me - and wrapping the context manager in a try block
> almost seems to defeat the purpose of the context manager in the first
> place - If I'm going to be catching errors anyway, why not just do the
> cleanup there rather than hiding it in the context manager?
>
> Now don't get me wrong - neither of these issues is terribly significant
> to me. I'll happily wrap all the context manager calls in a try block and
> move on with life if that it in fact the best option. It's just my gut
> says "there should be a better way", so I figured I'd ask: *is* there a
> better way? Perhaps some way I could handle the error internally to the
> context manager, such that it just dumps me back out? Of course, that
> might not work, given that I may need to do something different *after*
> the context manager, depending on if I was able to get a connection, but
> it's a thought. Options?
The problem is that there is no way to skip the with-block. It would be nice
if you could raise a special exception in the __enter__() method that would
achieve that.
For the time being you could
(1) abuse a for loop
def psql_cursor():
try:
yield make_cursor()
except NoConnection:
pass
for cursor in psql_cursor():
...
or you could
(2) return something that hopefully raises an exception soon, e. g.
$ cat conditional_context.py
import sys
from contextlib import contextmanager
class Cursor:
def execute(self, sql):
print("EXECUTING", sql)
class Exit(Exception):
pass
class FailingCursor:
def __getattr__(self, name):
raise Exit
@contextmanager
def cursor():
try:
yield FailingCursor() if "--fail" in sys.argv else Cursor()
except Exit:
print("no connection")
with cursor() as cs:
cs.execute("insert into...")
$ python3 conditional_context.py
EXECUTING insert into...
$ python3 conditional_context.py --fail
no connection
Option (1) works, but looks wrong while option (2) looks better, but does
not work reliably in the general case, e. g. when you perform some costly
calculation before the first attribute access.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Error handling in context managers
On Tue, 17 Jan 2017 05:06 am, Israel Brewster wrote:
> I generally use context managers for my SQL database connections, so I can
> just write code like:
>
> with psql_cursor() as cursor:
>
>
> And the context manager takes care of making a connection (or getting a
> connection from a pool, more likely), and cleaning up after the fact (such
> as putting the connection back in the pool), even if something goes wrong.
> Simple, elegant, and works well.
>
> The problem is that, from time to time, I can't get a connection, the
> result being that cursor is None,
Seriously? psql_cursor().__enter__ returns None instead of failing? That
sounds like a poor design to me.
Where is this psql_cursor coming from?
> and attempting to use it results in an
> AttributeError. So my instinctive reaction is to wrap the potentially
> offending code in a try block, such that if I get that AttributeError I
> can decide how I want to handle the "no connection" case. This, of course,
> results in code like:
>
> try:
> with psql_cursor() as cursor:
>
> except AttributeError as e:
>
Except that isn't necessarily the no-connection case. It could be *any*
AttributeError anywhere in the entire with block.
> I could also wrap the code within the context manager in an if block
> checking for if cursor is not None, but while perhaps a bit clearer as to
> the purpose, now I've got an extra check that will not be needed most of
> the time (albeit a quite inexpensive check).
It's cheap, it's only needed once (at the start of the block), it isn't
subject to capturing the wrong exception... I would definitely write:
with psql_cursor() as cursor:
if cursor is not None:
> The difficulty I have with either of these solutions, however, is that
> they feel ugly to me - and wrapping the context manager in a try block
> almost seems to defeat the purpose of the context manager in the first
> place - If I'm going to be catching errors anyway, why not just do the
> cleanup there rather than hiding it in the context manager?
Context managers don't necessarily swallow exceptions (although they can).
That's not what they're for. Context managers are intended to avoid:
try:
...
finally:
...
*not* try...except blocks. If you need a try...except, then you could avoid
using the context manager and re-invent the wheel:
try:
...
except:
...
finally:
# do whatever cleanup the context manager already defines
# but now you have to do it yourself
or you can let the context manager do what it does, and write your own code
to do what you do:
try:
with ...:
...
except:
...
[...]
> says "there should be a better way", so I figured I'd ask: *is* there a
> better way? Perhaps some way I could handle the error internally to the
> context manager, such that it just dumps me back out?
That's what's supposed to happen:
py> with open('foobarbaz') as f:
... pass
...
Traceback (most recent call last):
File "", line 1, in
FileNotFoundError: [Errno 2] No such file or directory: 'foobarbaz'
Notice that the context manager simply raises an exception on failure, which
I can catch or not as I so choose, rather than returning None.
I really think that the problem here is the design of psql_cursor().
> Of course, that
> might not work, given that I may need to do something different *after*
> the context manager, depending on if I was able to get a connection, but
> it's a thought. Options?
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Error handling in context managers
Steve D'Aprano : > or you can let the context manager do what it does, and write your own code > to do what you do: > > try: > with ...: >... > except: > ... Even better: try: a = open(...) except ...: ... with a: ... You want to catch exceptions immediately after (potentially) raising them. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Sockets: IPPROTO_IP not supported
On Mon, 16 Jan 2017 10:17:06 +, Joseph L. Casale wrote:
>> Trying to sniff Ethernet packets, I do this:
>>
>>s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_IP)
>>
>> but it results in this:
>>
>> $ sudo python3 sniff_survey.py
>> Traceback (most recent call last):
>> File "sniff_survey.py", line 118, in
>> s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_IP)
>> File "/usr/lib/python3.2/socket.py", line 94, in __init__
>> _socket.socket.__init__(self, family, type, proto, fileno)
>> socket.error: [Errno 93] Protocol not supported
>>
>> Anybody know what I'm doing wrong? (Python 3.2.3 under Debian 3.2.84-1.)
>
> Have a look at the bottom of this SO question:
> http://stackoverflow.com/questions/5385312/ipproto-ip-vs-ipproto-tcp-ipproto-udp
That discussion was helpful. Thanks.
Still, I'm not out of the woods. From bmargulies's answer at that link,
"IPPROTO_IP is for raw IP packets",
which sounds like what I want. But when I use AF_INET, SOCK_RAW, and
IPPROTO_IP, I get the "Protocol not supported" error as shown above.
>From the link you provided and "man socket", I was inspired to flail
about, finding this:
domaintypeprotocol result
--- -- -
AF_INET SOCK_RAWIPPROTO_IP "Protocol not supported"
AF_INET SOCK_RAWIPPROTO_IPIP Sees nothing
AF_INET SOCK_RAWIPPROTO_TCP Sees TCP traffic, no "dig", no "ping"
AF_INET SOCK_RAWIPPROTO_UDP Sees DNS ("dig", but not "ping")
AF_INET SOCK_RAWIPPROTO_ICMP Sees "ping", but not "dig"
AF_INET SOCK_RAWIPPROTO_RAW Sees nothing
AF_INET SOCK_RAW0 "Protocol not supported"
AF_INET SOCK_STREAM 0 "Transport endpoint is not connected"
AF_INET SOCK_DGRAM 0 Sees nothing
AF_INET SOCK_RDM0 "Socket type not supported"
AF_IPXSOCK_RAWIPPROTO_RAW "Socket type not supported"
AF_PACKET SOCK_RAWIPPROTO_RAW Sees nothing
AF_PACKET SOCK_RAWIPPROTO_TCP Sees nothing
So I can receive TCP traffic through one socket, and UDP traffic through
another socket, and ICMP traffic through a third; but I would like to
see all IP packets, regardless of higher-level protocol, and would
prefer to get them through a single pipe. (Perhaps it's unreasonable
for me to ask something as high-level as a socket to give me something
as low-level as a raw packet.)
My starting point, by the way, was sample code for "a very simple
network sniffer", presented at docs.python.org/3/library/socket.html,
which opened the socket with
s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_IP)
which is the line that results in the "Protocol not supported" error
on my system. (That sample code is labelled as being "for Windows",
so the document is not in error.)
--
To email me, substitute nowhere->runbox, invalid->com.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Error handling in context managers
On 1/16/2017 1:06 PM, Israel Brewster wrote:
I generally use context managers for my SQL database connections, so I can just
write code like:
with psql_cursor() as cursor:
And the context manager takes care of making a connection (or getting a
connection from a pool, more likely), and cleaning up after the fact (such as
putting the connection back in the pool), even if something goes wrong. Simple,
elegant, and works well.
The problem is that, from time to time, I can't get a connection, the result
being that cursor is None,
This would be like open('bad file') returning None instead of raising
FileNotFoundError.
and attempting to use it results in an AttributeError.
Just as None.read would.
Actually, I have to wonder about your claim. The with statement would
look for cursor.__enter__ and then cursor.__exit__, and None does not
have those methods. In other words, the expression following 'with'
must evaluate to a context manager and None is not a context manager.
>>> with None: pass
Traceback (most recent call last):
File "", line 1, in
with None: pass
AttributeError: __enter__
Is psql_cursor() returning a fake None object with __enter__ and
__exit__ methods?
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
tokenize.untokenize adding line continuation characters
Here's something odd I've found with the tokenize module: tokenizing 'if x:\n
y' and then untokenizing the result adds '\\\n' to the end. Attempting to
tokenize the result again fails because of the backslash continuation with
nothing other than a newline after it. On the other hand, if the original
string ends with a newline then it works fine. Can anyone explain why this
happens?
I'm using Python 3.4.3 on Windows 8. Copypasted from iPython:
import tokenize, io
tuple(tokenize.tokenize(io.BytesIO('if x:\ny'.encode()).readline))
Out[2]:
(TokenInfo(type=56 (ENCODING), string='utf-8', start=(0, 0), end=(0, 0),
line=''),
TokenInfo(type=1 (NAME), string='if', start=(1, 0), end=(1, 2), line='if
x:\n'),
TokenInfo(type=1 (NAME), string='x', start=(1, 3), end=(1, 4), line='if x:\n'),
TokenInfo(type=52 (OP), string=':', start=(1, 4), end=(1, 5), line='if x:\n'),
TokenInfo(type=4 (NEWLINE), string='\n', start=(1, 5), end=(1, 6), line='if
x:\n'),
TokenInfo(type=5 (INDENT), string='', start=(2, 0), end=(2, 4), line='
y'),
TokenInfo(type=1 (NAME), string='y', start=(2, 4), end=(2, 5), line='y'),
TokenInfo(type=6 (DEDENT), string='', start=(3, 0), end=(3, 0), line=''),
TokenInfo(type=0 (ENDMARKER), string='', start=(3, 0), end=(3, 0), line=''))
tokenize.untokenize(_).decode()
Out[3]: 'if x:\ny\\\n'
tuple(tokenize.tokenize(io.BytesIO(_.encode()).readline))
---
TokenErrorTraceback (most recent call last)
in ()
> 1 tuple(tokenize.tokenize(io.BytesIO(_.encode()).readline))
C:\Program Files\Python34\lib\tokenize.py in _tokenize(readline, encoding)
558 else: # continued statement
559 if not line:
--> 560 raise TokenError("EOF in multi-line statement", (lnum,
0))
561 continued = 0
562
TokenError: ('EOF in multi-line statement', (3, 0))
--
https://mail.python.org/mailman/listinfo/python-list
Re: tokenize.untokenize adding line continuation characters
On Tuesday 17 January 2017 09:42, Rotwang wrote: > Here's something odd I've found with the tokenize module: [...] > Copypasted from iPython: It's not impossible that iPython is doing something funny with the tokenize module. Before reporting it as a bug, I recommend that you confirm that it also occurs in the standard Python interpreter and isn't iPython specific. Just run your same code but directly from python, not the interactive iPython console. -- Steven "Ever since I learned about confirmation bias, I've been seeing it everywhere." - Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Error handling in context managers
Israel Brewster wrote: The problem is that, from time to time, I can't get a connection, the result being that cursor is None, That's your problem right there -- you want a better-behaved version of psql_cursor(). def get_psql_cursor(): c = psql_cursor() if c is None: raise CantGetAConnectionError() return c with get_psql_cursor() as c: ... -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Error handling in context managers
Terry Reedy wrote: Traceback (most recent call last): File "", line 1, in with None: pass AttributeError: __enter__ Like he said, you get an AttributeError! -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Emulating Final classes in Python
I wish to emulate a "final" class using Python, similar to bool: py> class MyBool(bool): ... pass ... Traceback (most recent call last): File "", line 1, in TypeError: type 'bool' is not an acceptable base type It doesn't have to be absolutely bulletproof, but anyone wanting to subclass my class should need to work for it, which hopefully will tell them that they're doing something unsupported. Any hints? -- Steven "Ever since I learned about confirmation bias, I've been seeing it everywhere." - Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Emulating Final classes in Python
On 01/16/2017 11:05 PM, Steven D'Aprano wrote: I wish to emulate a "final" class using Python, similar to bool: py> class MyBool(bool): ... pass ... Traceback (most recent call last): File "", line 1, in TypeError: type 'bool' is not an acceptable base type It doesn't have to be absolutely bulletproof, but anyone wanting to subclass my class should need to work for it, which hopefully will tell them that they're doing something unsupported. Any hints? Use a metaclass. Have the metaclass create the first one, and refuse to make any others. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Emulating Final classes in Python
On Tuesday 17 January 2017 18:05, Steven D'Aprano wrote:
> I wish to emulate a "final" class using Python, similar to bool:
[...]
> Any hints?
I may have a solution: here's a singleton (so more like None than bools) where
instantiating the class returns the singleton, and subclassing the class fails:
class DoneMeta(type):
_final = None
def __new__(meta, name, bases, ns):
if meta._final is None:
meta._final = cls = super().__new__(meta, name, bases, ns)
return cls
elif meta._final in bases: # Not sure this check is needed.
raise TypeError('base class is final and cannot be subclassed')
class DoneType(metaclass=DoneMeta):
__slots__ = ()
_instance = None
def __new__(cls):
if cls._instance is None:
cls._instance = inst = super().__new__(cls)
return inst
return cls._instance
def __repr__(self):
return ''
DONE = DoneType()
del DoneType, DoneMeta
assert type(DONE)() is DONE
Thoughts? Any improvements or criticism? (Apart from "don't do it" :-)
Of course this is Python, and so we can actually dig under the hood and make a
new instance if we really try:
py> x = object.__new__(type(DONE))
py> x
py> x is DONE
False
and similarly there are probably ways to bypass the anti-subclassing code. But
the way I see it, if you're doing that, you either know what you're doing in
which case good on you, or you don't, in which case you deserve whatever
happens to you :-)
--
Steven
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." - Jon Ronson
--
https://mail.python.org/mailman/listinfo/python-list
