`async def` breaks encapsulation?

[Marco Sulla via Python-list]

I worked a lot with `asyncio` many years ago, when `aiohttp` was first
born. Now I'm working again with it, since a library that I need
requires it.

asyncio is much more simple to use now, but there's something that
still make me doubtful: the require of the `async` keyword for
coroutines.

When I developed the aiohttp app, many times I changed my mind and an
async function turned back to be a normal one. But in the meanwhile
I'd used it for a bunch of coroutines, that I used for a bunch of
coroutines etc... so I had to check all the affected coroutines and
remove the `async` keyword from them.

This recall me checked exceptions in Java. If you add to a Java method
messTheCode() a `throws SomeException`, and subsequently you refactor
the code so the exception is no more raised, you have to remove the
`throws SomeException` from the function signature and to all the
functions that used `messTheCode()` that decided to not handle the
exception.

(This is why I do not use checked exceptions in Java... I wrap them in
unchecked ones. Yes, I'm an heretical :-D)

The fact that puzzles me is that no additional keyword for coroutines
was needed. A coroutines was simply a function with a `yield`. If it
quacks...

Why can't an asynchronous coroutine be simply a coroutine that has an
`async` or an `await` in its code, without `async` in the signature?
-- 
https://mail.python.org/mailman/listinfo/python-list

pyodbc slowness

[Larry Martell]

I have some Python code that uses pyodbc to talk to a SQL Server database.
In that code I do an  INSERT INTO  SELECT * FROM 

That query takes around 3 times longer to run when invoked from Python with
pyodbc than when run with direct SQL.

On one system we have 1,667 rows and the timings are direct sql 1.7s pyodbc
4.6s. On another system we have 15,000 rows and it's 15s vs 48s

In both cases, I am running from the same machine over the same network
talking to the same SQL Server.

The only difference I can find is the driver. When I run the direct SQL the
client I have uses the driver net.sourceforge.jtds.jdbc.Driver jtds12.jar
where as pyodbc uses {ODBC Driver 17 for SQL Server}.

Could this be the cause of the difference? Is there a different driver I
can use with pyodbc that would be faster?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pyodbc slowness

[Larry Martell]

On Wed, Mar 4, 2020 at 3:20 PM Larry Martell  wrote:
>
> I have some Python code that uses pyodbc to talk to a SQL Server database. In 
> that code I do an  INSERT INTO  SELECT * FROM 
>
> That query takes around 3 times longer to run when invoked from Python with 
> pyodbc than when run with direct SQL.
>
> On one system we have 1,667 rows and the timings are direct sql 1.7s pyodbc 
> 4.6s. On another system we have 15,000 rows and it's 15s vs 48s
>
> In both cases, I am running from the same machine over the same network 
> talking to the same SQL Server.
>
> The only difference I can find is the driver. When I run the direct SQL the 
> client I have uses the driver net.sourceforge.jtds.jdbc.Driver jtds12.jar 
> where as pyodbc uses {ODBC Driver 17 for SQL Server}.
>
> Could this be the cause of the difference? Is there a different driver I can 
> use with pyodbc that would be faster?

I discovered the issue is that I am selecting from a view. When
selecting from a table the time is the same. So what about a view
would make it take longer when accessed from pyodbc?
-- 
https://mail.python.org/mailman/listinfo/python-list

How does the super type present itself and do lookups?

[Adam Preble]

Months ago, I asked a bunch of stuff about super() and managed to fake it well 
enough to move on to other things for awhile. The day of reckoning came this 
week and I was forced to implement it better for my personal Python project. I 
have a hack in place that makes it work well-enough but I found myself 
frustrated with how shift the super type is. It's both the self and the parent 
class, but not.

If you don't know, you can trap what super() returns some time and poke it with 
a stick. If you print it you'll be able to tell it's definitely unique:
, >

If you try to invoke methods on it, it'll invoke the superclass' methods. 
That's what is supposed to happen and basically what already happens when you 
do super().invoke_this_thing() anyways.

Okay, so how is it doing the lookup for that? The child instance and the super 
types' __dict__ are the same. The contents pass an equality comparison and are 
the same if you print them.

They have the same __getattribute__ method wrapper. However, if you dir() them 
you definitely get different stuff. For one, the super type has its special 
variables __self__, __self_class__, and __thisclass__. It's missing __dict__ 
from the dir output. But wait, I just looked at that!

So I'm thinking that __getattr__ is involved, but it's not listed in anything. 
If I use getattr on the super, I'll get the parent methods. If I use 
__getattribute__, I get the child's methods. I get errors every way I've 
conceived of trying to pull out a __getattr__ dunder. No love.

I guess the fundamental question is: what different stuff happens when 
LOAD_ATTR is performed on a super object versus a regular object?

If you are curious about what I'm doing right now, I overrode __getattribute__ 
since that's primarily what I use for attribute lookups right now. It defer to 
the superclass' __getattribute__. If a method pops out, it replaces the self 
with the super's __self__ before kicking it out. I feel kind of dirty doing it:

https://github.com/rockobonaparte/cloaca/blob/312758b2abb80320fb3bf344ba540a034875bc4b/LanguageImplementation/DataTypes/PySuperType.cs#L36

If you want to see how I was experimenting with super, here's the code and 
output:

class Parent:
def __init__(self):
self.a = 1

def stuff(self):
print("Parent stuff!")


class Child(Parent):
def __init__(self):
super().__init__()
self.b = 2
self.super_instance = super()

def stuff(self):
print("Child stuff!")

def only_in_child(self):
print("Only in child!")


c = Child()
c.super_instance.__init__()
c.stuff()
c.super_instance.stuff()
print(c)
print(c.super_instance)
print(c.__init__)
print(c.super_instance.__init__)
print(c.stuff)
print(c.super_instance.stuff)
print(c.__getattribute__)
print(c.super_instance.__getattribute__)
print(dir(c))
print(dir(c.super_instance))
print(c.__dict__ == c.super_instance.__dict__)
print(getattr(c, "__init__"))
print(getattr(c.super_instance, "__init__"))
print(c.__getattribute__("__init__"))
print(c.super_instance.__getattribute__("__init__"))



Child stuff!
Parent stuff!
<__main__.Child object at 0x026854D99828>
, >
>
>
>
>


['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', 
'__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', 
'__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', 
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', 
'__str__', '__subclasshook__', '__weakref__', 'a', 'b', 'only_in_child', 
'stuff', 'super_instance']
['__class__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', 
'__ge__', '__get__', '__getattribute__', '__gt__', '__hash__', '__init__', 
'__init_subclass__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', 
'__reduce_ex__', '__repr__', '__self__', '__self_class__', '__setattr__', 
'__sizeof__', '__str__', '__subclasshook__', '__thisclass__', 'a', 'b', 
'super_instance']
True
>
>
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[RELEASE] Python 3.7.7rc1 is now available for testing

[Ned Deily]

Details here:

https://discuss.python.org/t/python-3-7-7rc1-is-now-available-for-testing/3638

https://www.python.org/downloads/release/python-377rc1/

--
  Ned Deily
  n...@python.org -- []

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help building python application from source

[Marco Sulla via Python-list]

Mh. I hoped not, but unluckily I expected a response like this.

People of Python List, I strongly discourage you to support this user.
He is quite suspicious for the following reasons:

1. he go so far as he offers money for, IMHO, a trivial task
2. he does not trust binaries from pip. He is so careful that he wants
to freeze the libraries he will use and he want to compile them, so he
can see the code and be sure that the binary was generated by that
code. A lack of trust in open source projects that is quite unusual
3. I don't trust any cryptocurrency.

I believe in privacy,  but not in financial privacy. Yes,
cryptocurrencies can be useful for circumvent bans from tyrannic
states. But they can, and _are_ used, primarily to:
 - wash dirty money, by criminals and mafias
 - evade taxes
 - buy highly unethical "products", like weapons... and who know what other
 - finance tyrannies.

I do _not_ think that all people that uses cryptocurrencies are
criminals. I had, for example, some co-workers that invested in
BitCoins, only for profit.

But I do not trust this man, and I hope no one will offer support to
him. By my side, I'll report this discussion to moderators.


On Tue, 3 Mar 2020 at 04:24, Mr. Lee Chiffre  wrote:
>
>
> > I think I have the solution, but can I ask you why are you creating a
> > bitcoin server?
> >
> Yes. I am a crypto anarchist. I have a bitcoin node to do my part to
> running the bitcoin network and help remain it decentralized and
> resilient. The more people that run a node the better it is. When it comes
> to hosting servers I believe I am able to do so in a highly secure manner.
> So I am doing my part in secure the bitcoin network and documenting what I
> do to help others do the same thing.
>
> I support the bitcoin project because it is a liberty enhancing technology
> to counter act over reaching government and expanding tyranny. People have
> a right to financial privacy. And the world needs a secure financial
> network to replace the existing institutional one that suffers from fraud
> and theft.In a cyber dystopian world we live in there is a war on cash
> and privacy to push us into a digital monetary system where governments
> are able to spy on and control everything and everyone. If there is a need
> for digital money let it be one that supports liberty instead of weakening
> it. It is vital that cypher tech outpaces the police state. What we do
> determines the future. We can let ourselves be enslaved and passive. Or we
> can be active and support the solutions that create a better world and
> preserve what is good.
>
> Right now it is a full node and not used for any other services or
> purposes. If possible I would like to add electrumx so users of the
> electrum wallet can use my server. Electrum is a very popular wallet and
> is what comes pre installed with TAILS.
>
> --
> lee.chif...@secmail.pro
> PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35
>
-- 
https://mail.python.org/mailman/listinfo/python-list

How to solve a deadlock in an orthodox way

[Pau Freixes]

Hi folks,

During the development of a Python library which uses under the hood a
C++ library - using Cyhton - we found a deadlock issue between a lock
maintained by the C++ library and the GIL lock.

The problem started to appear at the moment that we tried to offload
all IO operations into an isolated thread. Basically, a thread running
an Asyncio loop. Once this thread was added, we had to start using
call_soon_threadsafe for scheduling new functions into the IO loop,
hereby is when deadlocks start appearing.

Why?

Before adding the new thread for offloading the IO operations we were
not releasing the GIL at each call to the C++ library, and in the very
beginning tried to be stick to that plan which resulted to be nocive
with the appearance of deadlocks.

Two threads might have the following behaviour, which would result in
a deadlock:

1 - (thread 1) (Cython) call a C++ function
2 - (thread 1) (C++ code) create a mutex X
3 - (thread 1) (C++ code) calls cython callback
4 - (thread 1) (Cython) calls call_son_threadsafe
5 - (thread 1) (Python) releases the GIL
6 - (thread 1) (Python) sock.sends(...)
7 - (thread 2) (Python) acquires GIL
8 - (thread 2) (Cython) call a C++ function
9 - (thread 2) (C++ code) tries to acquire the mutex X (gets locked)
10 - (thread 1) (Python) acuqires GIL (gets locked)

The IO thread synchronization, which was done by writing to a specific
FD, was releasing the GIL which would give the chance to other threads
to be executed and have the chance on getting locked into the already
locked mutex, ending up in a fatal deadlock.

For addressing the situation we explicitly released the GIL at each
C++ call, which solved the issue with some none negligible performance
sacrificing.

Do you have any idea how this deadlock could be prevented without
having to release the GIL at each C++ call? Considering that we do not
have any freedom on modifying the C++ code.

We have a solution that might work but it's not easy to implement, or
at least not for all of the environments. The idea is basically not
running the piece of code that is implicitly releasing the GIL and
deferring its execution to after the C++ code function. It seems to
work quite well since the C++ code is basically an asynchronous
framework that only needs to schedule a callback. This is doable in
environments where we already have an Asyncio thread, its a matter of
make a call to `call_soon(offload_io_work_into_another_thread, cb)`,
but for environments where we do not have an automatic mechanism for
deferring the execution of code we would need to implement them which
could be a none straightforward task.

Thoughts?

Thanks!

-- 
--pau
-- 
https://mail.python.org/mailman/listinfo/python-list

What is the correct interpreter

[Jim Ferraro]

Where is the correct interpreter?
I have installed python several times
Pycharm all ways selects

C:\ProgramFiles\JetBrains\PyCharm Community Edition 2019.3.3\bin\pycharm64.exe
But when I run a simple code it objects to the interpreter???


Sent from Mail for Windows 10

-- 
https://mail.python.org/mailman/listinfo/python-list

Application setup like windows msi

[J A]

I was wondering g if there was a way to distribute an application that took
advantage of user input like a windows .msi does. On linux of course.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Application setup like windows msi

[Michael Torrie]

On 3/4/20 4:51 PM, J A wrote:
> I was wondering g if there was a way to distribute an application that took
> advantage of user input like a windows .msi does. On linux of course.

Several installer frameworks can make interactive installers for Linux.
There's the NullSoft installer and InstallerVICE.  And quite a few
commercial packages have rolled their own installers. Although I find
installers of any kind of annoying on Linux and don't seem all that
necessary.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Python-Dev] [RELEASE] Python 3.7.7rc1 is now available for testing

[Ned Deily]

On Mar 4, 2020, at 17:17, Jonathan Goble  wrote:
> On Wed, Mar 4, 2020 at 1:02 PM Ned Deily  wrote:
> Details here:
> 
>> https://discuss.python.org/t/python-3-7-7rc1-is-now-available-for-testing/3638
>> 
>> "Assuming no critical problems are found prior to 2020-02-10..."

> I would like to know how you expect people to travel back in time to report 
> problems. :P

python3.7 -m pip install guidos_time_machine

If, for some reason that doesn't work, let's wait until 2020-03-10!

--
  Ned Deily
  n...@python.org -- []

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Python-Dev] [RELEASE] Python 3.7.7rc1 is now available for testing

[Jonathan Goble]

On Wed, Mar 4, 2020 at 1:02 PM Ned Deily  wrote:

> Details here:
>
>
> https://discuss.python.org/t/python-3-7-7rc1-is-now-available-for-testing/3638


"Assuming no critical problems are found prior to *2020-02-10*..."

I would like to know how you expect people to travel back in time to report
problems. :P
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Python-Dev] [RELEASE] Python 3.7.7rc1 is now available for testing

[Ned Deily]

On Mar 4, 2020, at 23:39, Jonathan Goble  wrote:
>> On Wed, Mar 4, 2020 at 10:05 PM Ned Deily  wrote:
>> On Mar 4, 2020, at 17:17, Jonathan Goble  wrote:
>> > On Wed, Mar 4, 2020 at 1:02 PM Ned Deily  wrote:
>> > Details here:
>> >> https://discuss.python.org/t/python-3-7-7rc1-is-now-available-for-testing/3638
>> >> "Assuming no critical problems are found prior to 2020-02-10..."
>> > I would like to know how you expect people to travel back in time to 
>> > report problems. :P
>> 
>> python3.7 -m pip install guidos_time_machine
>> 
>> If, for some reason that doesn't work, let's wait until 2020-03-10!
> 
> Well, it works now! (if you substitute dashes for the underscores)
> 
> https://pypi.org/project/guidos-time-machine/
> 
> Brand new package uploaded by Guido 36 minutes ago.

Python is great for just-in-time agile development, especially in future 
tenths. 

  --
Ned Deily
n...@python.org -- []

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is the correct interpreter

[Miki Tebeka]

Hi,

> Where is the correct interpreter?
> I have installed python several times
> Pycharm all ways selects
> 
> C:\ProgramFiles\JetBrains\PyCharm Community Edition 2019.3.3\bin\pycharm64.exe
This is the PyCharm executable, not the Python one. See 
https://www.jetbrains.com/help/pycharm/configuring-local-python-interpreters.html
 on how to configure the interpreter.

> But when I run a simple code it objects to the interpreter???
I order to help we'll need more information. What is the code you're trying to 
run and what is the error?

Happy hacking,
Miki
-- 
https://mail.python.org/mailman/listinfo/python-list