Re: GIL-Removal Project Takes Another Step (Posting On Python-List Prohibited)

[Chris Angelico via Python-list]

On Wed, 20 Mar 2024 at 18:31, Greg Ewing via Python-list
 wrote:
>
> On 20/03/24 4:14 pm, Lawrence D'Oliveiro wrote:
> > not to
> > mention the latency when there isn’t quite enough memory for an allocation
> > and you have to wait until the next GC run to proceed. Run the GC a
> > thousand times a second, and the latency is still 1 millisecond.
>
> That's not the way it usually works. If you run out of memory, you
> run a GC there and then. You don't have to wait for GCs to occur on
> a time schedule.
>
> Also, as a previous poster pointed out, GCs are typically scheduled
> by number of allocations, not by time.
>

FYI you're violating someone's request by responding to them in a way
that results in it getting onto python-list, so it's probably safest
to just ignore cranks and trolls and let them stew in their own
juices.

But normally the GC doesn't need to be scheduled at all. In CPython,
the only reason to "run garbage collection" is to detect cycles, so
you would have to be generating inordinate amounts of cyclic garbage
for this to matter at all.

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

Re: GIL-Removal Project Takes Another Step (Posting On Python-List Prohibited)

[Greg Ewing via Python-list]

On 20/03/24 4:14 pm, Lawrence D'Oliveiro wrote:

not to
mention the latency when there isn’t quite enough memory for an allocation
and you have to wait until the next GC run to proceed. Run the GC a
thousand times a second, and the latency is still 1 millisecond.


That's not the way it usually works. If you run out of memory, you
run a GC there and then. You don't have to wait for GCs to occur on
a time schedule.

Also, as a previous poster pointed out, GCs are typically scheduled
by number of allocations, not by time.

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

Re: PEP about recommended project folder layout

[Chris Angelico]

On Sun, 31 Jul 2022 at 20:27, Weatherby,Gerard  wrote:
>
> I’m not aware of any standard convention for laying out packages.
>
> PEP 8 (https://peps.python.org/pep-0008/) specifies conventions for how to 
> write Python, so a standard layout PEP would not be inconsistent.
>

PEP 8 species rules for laying out the code of the Python standard
library. Its adoption by other projects does not constitute the Python
developers declaring that it's a convention for how to write all
Python code.

A better example would be PEP 257 https://peps.python.org/pep-0257/
but even that is more for the purpose of tooling. It does at least try
to describe usage conventions, though.

Conventions for laying out packages (as opposed to actual requirements
defined by the packaging system itself) would be better described
somewhere other than a PEP.

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

Re: PEP about recommended project folder layout

[Weatherby,Gerard]

I’m not aware of any standard convention for laying out packages.

PEP 8 (https://peps.python.org/pep-0008/) specifies conventions for how to 
write Python, so a standard layout PEP would not be inconsistent.

—
Gerard Weatherby | Application Architect NMRbox | NAN | Department of Molecular 
Biology and Biophysics
 UConn Health 263 Farmington Avenue, Farmington, CT 06030-6406 uchc.edu
On Jul 30, 2022, 4:37 PM -0400, Barry , wrote:
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

On 30 Jul 2022, at 13:52, c.bu...@posteo.jp wrote:

Isn't there a PEP?

PEP are for improving python. They are not for telling people how to use python.
I would be surprised to fine a PEP that addressed this.

Barry


On 2022-07-26 07:14 c.bu...@posteo.jp wrote:
Hello,

I am not sure if I looked into the correct sources. I was looking in
"PEP 609 – Python Packaging Authority (PyPA) Governance" [1] and the
"PyPA specifications" [2].

My question in short: Is there an official document (e.g. a PEP)
about a recommended layout for project folders.

Looking into the wild and past there are a lot of variations of such
layouts. I am far away from being a pro but depending on experience
in my own projects and what I have learned from others (e.g. in
blog-posts/tutorials) I recommend to have the "test" folder and the
package folder side by side on the same level in the project folder
(the root).

my_project
|- tests
| └ test_*.py
|- my_package
| └ __init__.py
└-- README.md

I sometimes add to it the so called "src"-Layout where the package
folder is one level deeper in an extra "src" folder.

my_project
|- tests
| └ test_*.py
|- src
| └- my_package
| └ __init__.py
└-- README.md

I don't want to discuss the pros and cons of all variations. What I
need is an official document I can use in discussions with other
maintainers. If there is a PEP/document against my current
recommendation I am also fine with this. ;)

Kind
Christian

[1] -- 
<https://urldefense.com/v3/__https://peps.python.org/pep-0609/__;!!Cn_UX_p3!ipqSQS5_ZFxO37h5h5XALf2DxE3eV-x6qNSrVnKJU3cLZIkLfKhuTzSxi1fb-BvYNVPXeT-nYFX8ogu6BLuJjA$
 >
[2] -- 
<https://urldefense.com/v3/__https://packaging.python.org/en/latest/specifications__;!!Cn_UX_p3!ipqSQS5_ZFxO37h5h5XALf2DxE3eV-x6qNSrVnKJU3cLZIkLfKhuTzSxi1fb-BvYNVPXeT-nYFX8oguyjbg15g$
 >

--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!ipqSQS5_ZFxO37h5h5XALf2DxE3eV-x6qNSrVnKJU3cLZIkLfKhuTzSxi1fb-BvYNVPXeT-nYFX8ogse6_J2Hg$

--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!ipqSQS5_ZFxO37h5h5XALf2DxE3eV-x6qNSrVnKJU3cLZIkLfKhuTzSxi1fb-BvYNVPXeT-nYFX8ogse6_J2Hg$
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP about recommended project folder layout

[Barry]

> On 30 Jul 2022, at 13:52, c.bu...@posteo.jp wrote:
> 
> Isn't there a PEP?

PEP are for improving python. They are not for telling people how to use python.
I would be surprised to fine a PEP that addressed this.

Barry

> 
>> On 2022-07-26 07:14 c.bu...@posteo.jp wrote:
>> Hello,
>> 
>> I am not sure if I looked into the correct sources. I was looking in 
>> "PEP 609 – Python Packaging Authority (PyPA) Governance" [1] and the 
>> "PyPA specifications" [2].
>> 
>> My question in short: Is there an official document (e.g. a PEP)
>> about a recommended layout for project folders.
>> 
>> Looking into the wild and past there are a lot of variations of such 
>> layouts. I am far away from being a pro but depending on experience
>> in my own projects and what I have learned from others (e.g. in 
>> blog-posts/tutorials) I recommend to have the "test" folder and the 
>> package folder side by side on the same level in the project folder
>> (the root).
>> 
>> my_project
>> |- tests
>> |  └ test_*.py
>> |- my_package
>> |  └ __init__.py
>> └-- README.md
>> 
>> I sometimes add to it the so called "src"-Layout where the package 
>> folder is one level deeper in an extra "src" folder.
>> 
>> my_project
>> |- tests
>> |  └ test_*.py
>> |- src
>> |  └- my_package
>> | └ __init__.py
>> └-- README.md
>> 
>> I don't want to discuss the pros and cons of all variations. What I
>> need is an official document I can use in discussions with other
>> maintainers. If there is a PEP/document against my current
>> recommendation I am also fine with this. ;)
>> 
>> Kind
>> Christian
>> 
>> [1] -- <https://peps.python.org/pep-0609/>
>> [2] -- <https://packaging.python.org/en/latest/specifications>
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

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

Re: PEP about recommended project folder layout

[c.buhtz]

Isn't there a PEP?

On 2022-07-26 07:14 c.bu...@posteo.jp wrote:
> Hello,
> 
> I am not sure if I looked into the correct sources. I was looking in 
> "PEP 609 – Python Packaging Authority (PyPA) Governance" [1] and the 
> "PyPA specifications" [2].
> 
> My question in short: Is there an official document (e.g. a PEP)
> about a recommended layout for project folders.
> 
> Looking into the wild and past there are a lot of variations of such 
> layouts. I am far away from being a pro but depending on experience
> in my own projects and what I have learned from others (e.g. in 
> blog-posts/tutorials) I recommend to have the "test" folder and the 
> package folder side by side on the same level in the project folder
> (the root).
> 
> my_project
> |- tests
> |  └ test_*.py
> |- my_package
> |  └ __init__.py
> └-- README.md
> 
> I sometimes add to it the so called "src"-Layout where the package 
> folder is one level deeper in an extra "src" folder.
> 
> my_project
> |- tests
> |  └ test_*.py
> |- src
> |  └- my_package
> | └ __init__.py
> └-- README.md
> 
> I don't want to discuss the pros and cons of all variations. What I
> need is an official document I can use in discussions with other
> maintainers. If there is a PEP/document against my current
> recommendation I am also fine with this. ;)
> 
> Kind
> Christian
> 
> [1] -- <https://peps.python.org/pep-0609/>
> [2] -- <https://packaging.python.org/en/latest/specifications>

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

PEP about recommended project folder layout

[c . buhtz]

Hello,

I am not sure if I looked into the correct sources. I was looking in 
"PEP 609 – Python Packaging Authority (PyPA) Governance" [1] and the 
"PyPA specifications" [2].


My question in short: Is there an official document (e.g. a PEP) about a 
recommended layout for project folders.


Looking into the wild and past there are a lot of variations of such 
layouts. I am far away from being a pro but depending on experience in 
my own projects and what I have learned from others (e.g. in 
blog-posts/tutorials) I recommend to have the "test" folder and the 
package folder side by side on the same level in the project folder (the 
root).


my_project
|- tests
|  └ test_*.py
|- my_package
|  └ __init__.py
└-- README.md

I sometimes add to it the so called "src"-Layout where the package 
folder is one level deeper in an extra "src" folder.


my_project
|- tests
|  └ test_*.py
|- src
|  └- my_package
| └ __init__.py
└-- README.md

I don't want to discuss the pros and cons of all variations. What I need 
is an official document I can use in discussions with other maintainers. 
If there is a PEP/document against my current recommendation I am also 
fine with this. ;)


Kind
Christian

[1] -- <https://peps.python.org/pep-0609/>
[2] -- <https://packaging.python.org/en/latest/specifications>
--
https://mail.python.org/mailman/listinfo/python-list

[issue494572] plugin project generation has problems

[admin]

Change by admin :


--
github: None -> 35773

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: For a hierarchical project, the EXE file generated by "pyinstaller" does not start.

[Mohsen Owzar]

Chris Angelico schrieb am Dienstag, 7. Dezember 2021 um 19:16:54 UTC+1:
> On Wed, Dec 8, 2021 at 4:49 AM Mohsen Owzar  wrote: 
> > *** 
> > GPIOContrl.py 
> > *** 
> > class GPIOControl: 
> > def my_print(self, args): 
> > if print_allowed == 1: 
> > print(args) 
> > 
> > def __init__(self):
> Can't much help with your main question as I don't do Windows, but one 
> small side point: Instead of having a my_print that checks if printing 
> is allowed, you can conditionally replace the print function itself. 
> 
> if not print_allowed: 
> def print(*args, **kwargs): pass 
> 
> ChrisA

Thanks Chris
Your answer didn't help me to solve my problem, but gave me another idea to 
write a conditional print statement.

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

Re: For a hierarchical project, the EXE file generated by "pyinstaller" does not start.

[Chris Angelico]

On Wed, Dec 8, 2021 at 4:49 AM Mohsen Owzar  wrote:
> ***
> GPIOContrl.py
> ***
> class GPIOControl:
> def my_print(self, args):
> if print_allowed == 1:
> print(args)
>
> def __init__(self):

Can't much help with your main question as I don't do Windows, but one
small side point: Instead of having a my_print that checks if printing
is allowed, you can conditionally replace the print function itself.

if not print_allowed:
def print(*args, **kwargs): pass

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

For a hierarchical project, the EXE file generated by "pyinstaller" does not start.

[Mohsen Owzar]

Hi all, 

I have a problem with "pyinstaller".
When I compile a single Python file, an EXE file is created in the "dist" 
directory, with which I can start the program and the GUI appears after a few 
seconds.
But when I try to compile my project with "pyinstaller 
Relais_LastDauerTester.py" and generate an EXE file from it, an ".exe" file is 
also created in the "dist" directory, but nothing happens when I run both .exe 
files from Windows Explorer with a double click or from the DOS shell by 
invoking it.
The mouse pointer changes briefly to an hourglass and then back and nothing 
happens.
The only difference between these two programs is that the first is just a 
single file and my project is structured hierarchically. I tried to demonstrate 
the structure of the project below with two "DIR" DOS commands.
In PyCharm you only need to run the top file "Relais_LastDauerTester.py", so I 
used this file for "pyinstaller".
But it looks like I have to give (I believe) an extra argument for a 
hierarchical project.
I googled all weekend to find a workable solution. But all I found was for 
converting a ".py" file and not a project like mine.
With some suggestions, I should add a "pause" or "input ()" command to the code 
to prevent the DOS shell from disappearing quickly, which is out of the 
question for me.
Do you have any idea what it could be?
I thank you in advance for any useful advice that could help me.

Greeting
Mohsen

PS 
I work on a PC with 
1201 INFO: PyInstaller: 4.7 
1202 INFO: Python: 3.9.5 
1282 INFO: Platform: Windows-10-10.0.18363-SP0 

Project Structure from PyCharm
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 
...\SW\Relais_LastDauerTester_V0.5 
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 
 .idea 
 Logfiles 
 Relais_LastDauerTester 
276 Relais_LastDauerTester.py 
 Screenshotfiles 
405 settings.ini 

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 
...\SW\Relais_LastDauerTester_V0.5\Relais_LastDauerTester 
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 
9’308  GPIOControl.py 
90’618   GUI_View.py 
998 main.py 
28’625  TestControl.py 
269  __init__.py 
   __pycache__ 


Simplified project files with the "import" lines 
*** 
Relais_LastDauerTester.py.py 
*** 
#!/usr/bin/env python3 
# -*- coding: utf-8 -*- 
from Relais_LastDauerTester.main import main 

if __name__ == "__main__": 
main() 

*** 
main.py 
*** 
import sys 

from PyQt5.QtCore import * 
from PyQt5.QtWidgets import QApplication 
from .GUI_View import MainWindow 

def main(): 
app = QApplication(sys.argv) 

window = MainWindow() 
window.show() 

sys.exit(app.exec_()) 

if __name__ == '__main__': 
main() 

*** 
GUI_View.py 
*** 
import sys 
import subprocess 

import PyQt5.QtGui as qtg 
from PyQt5.QtWidgets import (QLabel, QPushButton, QLineEdit, QCheckBox, 
QWidget, 
QVBoxLayout, QHBoxLayout, QGridLayout, QDialog, QFileDialog) 
from .TestControl import * 

class MainWindow(QWidget): 
def __init__(self): 
super().__init__() 

def createMainWindow(self): 
... 

def exitMainWindow(self): 
... 

def ChangeToPrefWindow(self): 
self.prefwindow.show() 
self.hide() 

class PrefWindow(QWidget): 
def __init__(self, parent=None): 
super().__init__() 
self.parent = parent 
... 
self.createPrefWindow() 

def ChangeToMainWindow(self): 
... 

def createPrefWindow(self): 
... 

class CustomLineEdit(QLineEdit): 
clicked = pyqtSignal() 

def mousePressEvent(self, QMouseEvent): 
self.clicked.emit() 

class Keypad_Window_New(QDialog): 
def __init__(self, num=0, parent=None): 
super().__init__(parent) 
self.parent = parent 
... 

TestContrl.py 
*** 
from PyQt5.QtCore import * 
from .GPIOControl import GPIOControl 

class WorkerSignals(QObject): 
signal_Update_Label = pyqtSignal() 

class TestControl(QRunnable): 
signals = WorkerSignals() 

def __init__(self, parent=None): 
super().__init__() 
self.parent = parent 
... 

*** 
GPIOContrl.py 
*** 
class GPIOControl: 
def my_print(self, args): 
if print_allowed == 1: 
print(args) 

def __init__(self):
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue40432] Pegen regenerate project for Windows not working

[Steve Dower]

Change by Steve Dower :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40432] Pegen regenerate project for Windows not working

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset f65f3f0e99b27e0a4ea6bb7e30c5bdb5832a76c6 by Miss Islington (bot) 
in branch '3.9':
bpo-40432: Use python 3.8 or higher to compile CPython on Windows (GH-25389) 
(#25637)
https://github.com/python/cpython/commit/f65f3f0e99b27e0a4ea6bb7e30c5bdb5832a76c6


--
nosy: +lukasz.langa

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40432] Pegen regenerate project for Windows not working

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 8.0 -> 9.0
pull_requests: +24332
pull_request: https://github.com/python/cpython/pull/25637

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40432] Pegen regenerate project for Windows not working

[Steve Dower]

Steve Dower  added the comment:


New changeset 425434dadc30d96dc1c0c628f954f9b6f5edd2c9 by Ken Jin in branch 
'master':
bpo-40432: Use python 3.8 or higher to compile CPython on Windows (#25389)
https://github.com/python/cpython/commit/425434dadc30d96dc1c0c628f954f9b6f5edd2c9


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40432] Pegen regenerate project for Windows not working

[Steve Dower]

Steve Dower  added the comment:

Thanks for the PR, kj! Left a suggestion for you, but otherwise it should solve 
the problem nicely.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40432] Pegen regenerate project for Windows not working

[Steve Dower]

Steve Dower  added the comment:

That'll be a change to PCbuild/find_python.bat that needs to be backported 
then. It probably defaults to 3.7 in all branches right now, but since 3.9 is 
out we can update them all to that (it downloads on demand if necessary).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40432] Pegen regenerate project for Windows not working

[Jeremy Kloth]

Jeremy Kloth  added the comment:

Adding windows team to the nosy list

--
components: +Windows
nosy: +jkloth, paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40432] Pegen regenerate project for Windows not working

[Ken Jin]

Change by Ken Jin :


--
nosy: +kj
nosy_count: 2.0 -> 3.0
pull_requests: +24122
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/25389

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40432] Pegen regenerate project for Windows not working

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Seems that the regeneration script is not detecting correctly that needs 
Python3.8+ for regenerating pegen. Check for instance:

https://buildbot.python.org/all/#/builders/596/builds/2/steps/2/logs/stdio

--
resolution: fixed -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: [Python-ideas] Re: Looking for people interested in a Python register virtual machine project

[Guido van Rossum]

On Tue, Mar 23, 2021 at 12:40 PM Skip Montanaro 
wrote:

> I've not attempted to make any changes to calling conventions. It
> occurred to me that the LOAD_METHOD/CALL_METHOD pair could perhaps be
> merged into a single opcode, but I haven't really thought about that.
> Perhaps there's a good reason the method is looked up before the
> arguments are pushed onto the stack (call_function()?). In a
> register-based VM there's no need to do things in that order.
>

IIRC the reason is that Python's language reference promises left-to-right
evaluation here. So o.m(f()) needs to evaluate o.m (which may have a side
effect if o overrides __getattr__) before it calls f().

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

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

Re: [Python-ideas] Looking for people interested in a Python register virtual machine project

[Skip Montanaro]

> a) You're working with CPython bleeding edge.
> b) You find that (bleeding edge) adding extra chore.
> c) Nobody told you to work on bleeding (nor boss, nor a maintainer who
> said "I'll merge it once you've done"),
>
> Then: why do you complicate your task by working on bleeding edge?
> Could take not too old CPython version, e.g. 3.8/3.9, instead, and work
> with that.

I started this in the 3.9 alpha timeframe. Staying up-to-date wasn't
too difficult. It never occurred to me that the virtual machine would
undergo so much churn for 3.10, so I just stuck with main/master and
paid the price when the changes started to arrive in earnest. When the
3.10 branch is created I will take that off-ramp this time.

> Btw, from just "pep", it's unclear if, and how much, you reuse Victor's
> work. If not, why? (The answer is useful to contributors - you ask them
> to "reuse" your code - how it's regarding your reuse of code of folks
> who were before you?).

Both Victor's and my earlier work took place in the dim dark past.
There have been so many functional changes to the virtual machine that
directly reusing either old code base wasn't feasible. I do have a
copy of Victor's work though which I have referred to from
time-to-time. I just never tried to merge it with something recent,
like 3.9.

> > > explicitly. Would be interesting to read (in the following "pep"
> > > sections) what makes them "almost completely distinct".
> >
> > Well, sure. The main difference is the way two pairs of instructions
> > (say, BINARY_ADD vs BINARY_ADD_REG) get their operands and save their
> > result. You still have to be able to add two objects, call functions,
> > etc.
>
> I'd note that your reply skips answering question about calling
> convention for register-based VM, and that's again one of the most
> important questions (and one I'd be genuinely interested to hear).

I've not attempted to make any changes to calling conventions. It
occurred to me that the LOAD_METHOD/CALL_METHOD pair could perhaps be
merged into a single opcode, but I haven't really thought about that.
Perhaps there's a good reason the method is looked up before the
arguments are pushed onto the stack (call_function()?). In a
register-based VM there's no need to do things in that order.

> > The fact that I treat the current frame's stack space as registers
> > makes it pretty much impossible to execute both stack and register
> > instructions within the same frame.
>
> I don't see how that would be true (in general, I understand that you
> may have constraints re: that, but that's exactly why I bring that up -
> why do you have constraints like that?). Even existing Python VM allows
> to use both in the same frame, e.g. LOAD_FAST. It takes value of
> register and puts it on a stack.

Sure, but that's because it must. All operands must be on the stack.
My code does have a step where it tries to remove LOAD_FAST_REG and
STORE_FAST_REG opcodes. It's not very good though. Pesky implicit
references cause problems. Still, I am able to remove some of them.
This should get better over time. And, it is possible that at some
point I decide to add back in some stack space for stuff like calling
functions, constructing lists, etc.

> Do you mean details like need to translate stack-based instructions
> into 2 (or more) instructions of: a) actual register-register
> instruction and; b) stack pointer adjustment, so stack-based
> instructions still kept working?

Yes, but I see (I think) what you're getting at. If I continued to
maintain the stack pointer, in theory stack opcodes could exist along
with register opcodes.

> Yes, you would need to do that, until you fully switch to
> register-based ones. But then there's 2 separate tasks:
>
> 1. Make register VM work. (Should be medium complexity.)
> 2. Make it fast. (Likely will be hard.)

I'm not too worried about #2 yet. :-) And as demonstrated by the
current project's incompleteness, either I'm not up to medium
complexity tasks anymore or it's harder than you think. :-)

Some of the second step isn't too hard, I don't think. I already
mentioned eliding generated fast LOAD/STORE instructions, and in my
previous email mentioned copying constants from the code object to the
frame object on creation. I also think opcode prediction and fast
dispatch should be straightforward. I just haven't bothered with that
yet.

> If you want to achieve both right from the start - oh-oh, that may be
> double-hard.
>
> > Victor's implementation did things
> > differently in this regard. I believe he just allocated extra space
> > for 256 registers at the end of each frame, so (in theory, I suppose),
> > you could have instructions from both executed in the same frame.
>
> I hope you have a plan of how to deal with more than 256 registers,
> etc. Register VM adds a lot of accidental implementation complexity ;-).

One of the reasons I just reused the current stack space as my
register space harkens back to a thread with Tim Peters back in 

Re: [Python-ideas] Looking for people interested in a Python register virtual machine project

[Skip Montanaro]

Thanks for the response. I will try to address your comments inline.

> I guess it should be a good idea to answer what's the scope of this
> project - is it research one or "production" one? If it's research one,
> why be concerned with the churn of over-modern CPython versions?
> Wouldn't it be better to just use some scalable, incremental
> implementation which would allow to forward-port it to a newer version,
> if it ever comes to that?

The motivation for revisiting this idea was/is largely personal. As I
indicated, I first messed around with it over 20 years ago and it's
been in the back of my mind ever since. Somehow I never lost the code
despite I'm not sure how many computers came and went and that the
code was never uploaded to any sort of distributed version control
system. I decided to pick things up again as a way to mostly keep my
head in the game after I retired. So, neither "research" nor
"production" seems to be a correct descriptor. Still, if taken to
functional completion — functional enough for performance testing and
application to more than just toy scripts — I realized pretty quickly
that I'd need help.

> Otherwise, if it's "production", who's the "customer" and how they
> "compensate" you for doing work (chasing the moving target) which is
> clearly of little interest to you and conflicts with the goal of the
> project?

Nobody is compensating me. I have no desire to try and turn it into
something I do for hire. Maybe I misunderstood your question?

> > This PEP proposes the addition of register-based instructions to the
> > existing Python virtual machine, with the intent that they eventually
> > replace the existing stack-based opcodes.
>
> Sorry, what? The purpose of register-based instructions is to just
> replace stack-based instructions? That's not what's I'd like to hear as
> the intro phrase. You probably want to replace one with the other
> because register-based ones offer some benefit, faster execution
> perhaps? That's what I'd like to hear instead of "deciphering" that
> between the lines.

Replacing stack-based instructions would be a reasonable initial goal,
I think. Victor reported performance improvements in his
implementation (also a translator). As I indicated in the "PEP" (I use
that term rather loosely, as I have no plans at the moment to submit
it for consideration, certainly not in its current, incomplete state),
a better ultimate way to go would be to generate register instructions
directly from the AST. The current translation scheme allows me to
write simple test case functions, generate register instructions, then
compare that when called the two produce the same result.

> > They [2 instruction sets] are almost completely distinct.
>
> That doesn't correspond to the mental image I would have. In my list,
> the 2 sets would be exactly the same, except that stack-based encode
> argument locations implicitly, while register-based - explicitly. Would
> be interesting to read (in the following "pep" sections) what makes them
> "almost completely distinct".

Well, sure. The main difference is the way two pairs of instructions
(say, BINARY_ADD vs BINARY_ADD_REG) get their operands and save their
result. You still have to be able to add two objects, call functions,
etc.

> > Within a single function only one set of opcodes or the other will
> > be used at any one time.
>
> That would be the opposite of "scalable, incremental" development
> approach mentioned above. Why not allow 2 sets to freely co-exist, and
> migrate codegeneration/implement code translation gradually?

The fact that I treat the current frame's stack space as registers
makes it pretty much impossible to execute both stack and register
instructions within the same frame. Victor's implementation did things
differently in this regard. I believe he just allocated extra space
for 256 registers at the end of each frame, so (in theory, I suppose),
you could have instructions from both executed in the same frame.

> > ## Motivation
>
> I'm not sure the content of the section corresponds much to its title.
> It jumps from background survey of the different Python VM optimizations
> to (some) implementation details of register VM - leaving "motivation"
> somewhere "between the lines".
>
> > Despite all that effort, opcodes which do nothing more than move data
> > onto or off of the stack (LOAD_FAST, LOAD_GLOBAL, etc) still account
> > for nearly half of all opcodes executed.
>
> ... And - you intend to change that with a register VM? In which way and
> how? As an example, LOAD_GLOBAL isn't going anywhere - it loads a
> variable by *symbolic* name into a register.

Certainly, if you have data which isn't a

Re: [Python-ideas] Looking for people interested in a Python register virtual machine project

[Skip Montanaro]

> Yeah, that is old writing, so is probably less clear (no pun intended)
> than it should be. In frame_dealloc, Py_CLEAR is called for
> stack/register slots instead of just Py_XDECREF. Might not be
> necessary.

Also, the intent is not to change any semantics here. The
implementation of RETURN_VALUE_REG still Py_INCREFs the to-be-returned
value. It's not like the data can get reclaimed before the caller
receives it.

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

Re: [Python-ideas] Looking for people interested in a Python register virtual machine project

[Skip Montanaro]

> In the "Object Lifetime" section you say "registers should be cleared upon 
> last reference". That isn't safe, since there can be hidden dependencies on 
> side effects of __del__, e.g.:
>
> process_objects = create_pipeline()
> output_process = process_objects[-1]
> return output_process.wait()
>
> If the process class terminates the process in __del__ (PyQt5's QProcess 
> does), then implicitly deleting process_objects after the second line will 
> break the code.

Yeah, that is old writing, so is probably less clear (no pun intended)
than it should be. In frame_dealloc, Py_CLEAR is called for
stack/register slots instead of just Py_XDECREF. Might not be
necessary.

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

Re: [Python-ideas] Looking for people interested in a Python register virtual machine project

[Skip Montanaro]

Yes, I remember Parrot. As I understand it their original goal was a
language-agnostic virtual machine, which might have complicated things.

I will do a bit of reading and add some text to the "PEP."

Skip

On Sat, Mar 20, 2021, 11:36 AM David Mertz  wrote:

> The Parrot project was also intended to be the same thing, and for a while
> had a fair number of contributors. Unfortunately, it never obtained the
> performance wins that were good for.
>
> On Sat, Mar 20, 2021, 11:55 AM Skip Montanaro 
> wrote:
>
>> Back in the late 90s (!) I worked on a reimagining of the Python
>> virtual machine as a register-based VM based on 1.5.2. I got part of
>> the way with that, but never completed it. In the early 2010s, Victor
>> Stinner got much further using 3.4 as a base. The idea (and dormant
>> code) has been laying around in my mind (and computers) these past
>> couple decades, so I took another swing at it starting in late 2019
>> after retirement, mostly as a way to keep my head in the game. While I
>> got a fair bit of the way, it stalled. I've picked it up and put it
>> down a number of times in the past year, often needing to resolve
>> conflicts because of churn in the current Python virtual machine.
>> Though I kept getting things back in sync, I realize this is not a
>> one-person project, at least not this one person. There are several
>> huge chunks of Python I've ignored over the past 20 years, and not
>> just the internals. (I've never used async anything, for example.) If
>> it is ever to truly be a viable demonstration of the concept, I will
>> need help. I forked the CPython repo and have a branch (register2) of
>> said fork which is currently synced up with the 3.10 (currently
>> master) branch:
>>
>> https://github.com/smontanaro/cpython/tree/register2
>>
>> I started on what could only very generously be called a PEP which you
>> can read here. It includes some of the history of this work as well as
>> details about what I've managed to do so far:
>>
>> https://github.com/smontanaro/cpython/blob/register2/pep-.rst
>>
>> If you think any of this is remotely interesting (whether or not you
>> think you'd like to help), please have a look at the "PEP". Because
>> this covers a fair bit of the CPython implementation, chances to
>> contribute in a number of areas exist, even if you have never delved
>> into Python's internals. Questions/comments/pull requests welcome.
>>
>> Skip Montanaro
>> ___
>> Python-ideas mailing list -- python-id...@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-id...@python.org/message/IUKZPH4ZSZ22RZFKMITQ3Q6A22P4BXWX/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Looking for people interested in a Python register virtual machine project

[Skip Montanaro]

Back in the late 90s (!) I worked on a reimagining of the Python
virtual machine as a register-based VM based on 1.5.2. I got part of
the way with that, but never completed it. In the early 2010s, Victor
Stinner got much further using 3.4 as a base. The idea (and dormant
code) has been laying around in my mind (and computers) these past
couple decades, so I took another swing at it starting in late 2019
after retirement, mostly as a way to keep my head in the game. While I
got a fair bit of the way, it stalled. I've picked it up and put it
down a number of times in the past year, often needing to resolve
conflicts because of churn in the current Python virtual machine.
Though I kept getting things back in sync, I realize this is not a
one-person project, at least not this one person. There are several
huge chunks of Python I've ignored over the past 20 years, and not
just the internals. (I've never used async anything, for example.) If
it is ever to truly be a viable demonstration of the concept, I will
need help. I forked the CPython repo and have a branch (register2) of
said fork which is currently synced up with the 3.10 (currently
master) branch:

https://github.com/smontanaro/cpython/tree/register2

I started on what could only very generously be called a PEP which you
can read here. It includes some of the history of this work as well as
details about what I've managed to do so far:

https://github.com/smontanaro/cpython/blob/register2/pep-.rst

If you think any of this is remotely interesting (whether or not you
think you'd like to help), please have a look at the "PEP". Because
this covers a fair bit of the CPython implementation, chances to
contribute in a number of areas exist, even if you have never delved
into Python's internals. Questions/comments/pull requests welcome.

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

need help with a ctypes project for PyPI

[Simon Zhang]

Hi,

I have created a ctypes project as in the following link's first answer:
https://stackoverflow.com/questions/42585210/extending-setuptools-extension-to-use-cmake-in-setup-py

Since my machine's gcc is too high version or something, I used the docker
image located here:
https://quay.io/repository/pypa/manylinux2014_x86_64
to compile the copied .whl file. I ran auditwheel repair on my whl file
then copied it back to my local machine without complaints.

I'm not sure I understand the subsequent process I need to do with PyPI.

If I copy the manylinux2014 wheel back to my local machine  (into the dist
folder) and run the command:

python3 -m twine upload --repository testpypi dist/*

following the instructions from:
https://packaging.python.org/tutorials/packaging-projects/

when I pip3 install spamplusplus (this is the name I gave my test project)
https://test.pypi.org/project/spamplusplus/

I get that the CMakeLists.txt file is not existent. I used the same
setup.py file given in the link:
https://stackoverflow.com/questions/42585210/extending-setuptools-extension-to-use-cmake-in-setup-py

However I get the error that CMakeLists.txt file is not being uploaded?

 cmake /tmp/pip-build-6ff9ifuu/spamplusplus
-DCMAKE_LIBRARY_OUTPUT_DIRECTORY=/tmp/pip-build-6ff9ifuu/spamplusplus/build/lib.linux-x86_64-3.6/spamplusplus
-DCMAKE_BUILD_TYPE=Release
  CMake Error: The source directory
"/tmp/pip-build-6ff9ifuu/spamplusplus" does not appear to contain
CMakeLists.txt.

I think this is something basic involving paths but could be more involved.

Can anyone help!!

Thanks,

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

Asyncio project code review

[James]

Good day for everyone.

I have new asyncio project which use aiohttp connector and asyncio 
protocols/transports for tunneling packets through Tor Network cleanly. 
Project called aiotor: https://github.com/torpyorg/aiotor


If someone with experience in asyncio field can make code review I will 
be appreciated for any comments.


I prepared pull request to make it convenient to review and comment on 
the code: https://github.com/torpyorg/aiotor/pull/1


Thanks in advance.
--
https://mail.python.org/mailman/listinfo/python-list

asyncio project code review

[James]

Good day everyone.

I have new asyncio project which use aiohttp connector and asyncio 
protocols/transports for tunneling packets through Tor Network cleanly. 
Project called aiotor: https://github.com/torpyorg/aiotor


If someone with experience in asyncio field can make code review I will 
be appreciated for any comments.


I prepared pull request to make it convenient to review and comment on 
the code: https://github.com/torpyorg/aiotor/pull/1



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

A new project to be started

[Agnese Camellini]

Hello to everyone, i don't have a clear idea about who to write about this
project, which is only an idea, but it has to be written i think.
At first it was just a comparative literature research project, but now
that i am more involved in development, it has started to become more like
a different programming language or framework.
There is someone here who can receive attachments and who has the time to
read the research project and look at the presentation i am making?
Is anyone interested in developing a new language/framework on python? Who
should i ask to?
I only have a degree in Philosophy, i didn't have the money to take a new
one in computer science and so i studied by myself (luckily the university
exam bibliographies are public in Italy).
I have an idea of these two fields but there is another one involved, that
is Theory of language and logic (mathematical and constructivist logic).
However is  there anyone here i can speak to about those arguments?
Thanks a lot.
Agnese Camellini
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41616] Global variable in whole project and Relative imports problem

[Guido van Rossum]

Change by Guido van Rossum :


--
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41616] Global variable in whole project and Relative imports problem

[Steven D'Aprano]

Steven D'Aprano  added the comment:

One issue per ticket please.

Versions 3.9 and older are all in feature freeze, they will not get new 
features.

Combining a global declaration with an assignment has been requested before, 
and rejected. If you want to discuss that feature again, you should raise it on 
the Python-Ideas mailing list first, but unless you have a stronger reason than 
just saving a line of code, it probably won't be accepted.

Project-wide globals has not, as far as I can remember, been requested before, 
but again it needs to be discussed on Python-Ideas first.

Your comments about relative imports don't seem to be either a feature request 
or a bug report, but just a vague complaint that it often causes problems. 
Please be more precise.

Problems with global variables are nearly always problems with global 
variables, not bugs with Python. Global variables are very easy to misuse and 
often cause problems.

https://weblogs.asp.net/wallen/6750

http://wiki.c2.com/?GlobalVariablesAreBad

--
nosy: +steven.daprano
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue41616>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41616] Global variable in whole project and Relative imports problem

[ManPython]

New submission from ManPython :

1. Curently we have easy option to declare global variable (GV) 
a) like this:
global var1
var1 = 'whatever'

b) with some improved version like this:
global var1 'whatever'
or:
global var1,var2, 'whatever1','whatever2'

c) The Python is in way to produce small lines of code but this philosophy 
around GV not offering this.


2. Can we have easy option to delclare global variable for whole project 
including MVC?
a) By this is requiments to call GV in any place like in Model, View or 
Controler and change thits var globaly.

b) I noticed that programers many often calling module in main to operate with, 
where this way made many problems withs Relative imports
https://stackoverflow.com/questions/30669474/beyond-top-level-package-error-in-relative-import
https://stackoverflow.com/questions/14132789/relative-imports-in-python-2-7/
https://stackoverflow.com/questions/35166821/valueerror-attempted-relative-import-beyond-top-level-package
https://stackoverflow.com/questions/4000/attempted-relative-import-beyond-toplevel-package

b) In my test the Relative imports made often problems (As imposible to load - 
most often Django, but similar with Pyside2) and I noticed that exist some 
relation with global var. In some of P36 version most often due to libs. Wan't 
checking this, expecting other way (more easy) to solve typical problems with 
GV.
1) in Django most often is meeting in config.py
2) in Pyside2 most often is meeting in main.py where we calling 
model,view,controler (or other liek utils) and we trying working in some core 
variables that limitig projects to easy manage GV

--
components: Interpreter Core
messages: 375799
nosy: ManPython
priority: normal
severity: normal
status: open
title: Global variable in whole project and Relative imports problem
type: enhancement
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 
<https://bugs.python.org/issue41616>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: The FaQ project - Single or Double quotes

[Abdur-Rahmaan Janhangeer]

I'm still unsure whether or not to have a summary instead of just listing
the
texts

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius


On Thu, Jun 11, 2020 at 10:00 PM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

> Since the single vs double quote thread
> i decided to reactivate the FaQ project.
>
> You can view it here
>
> https://abdur-rahmaanj.github.io/pyfaq/[list]_Single_or_double_quotes.html
>
> The index has some some more summaries:
>
> https://abdur-rahmaanj.github.io/pyfaq/
> <https://abdur-rahmaanj.github.io/pyfaq/>
>
> I auto pull the messages with some manual edits like
> filtering empty mails etc
>
> Mr Christopher maintains one for python-ideas
> https://github.com/PythonCHB/PythonListsSummaries
>
> This one is intended to have even some common questions
> like where do i start etc
>
> Kind Regards,
>
> Abdur-Rahmaan Janhangeer
> compileralchemy <https://compileralchemy.github.io/> | blog
> <https://abdur-rahmaanj.github.io/>
> github <https://github.com/Abdur-RahmaanJ>
> Mauritius
>
-- 
https://mail.python.org/mailman/listinfo/python-list

The FaQ project - Single or Double quotes

[Abdur-Rahmaan Janhangeer]

Since the single vs double quote thread
i decided to reactivate the FaQ project.

You can view it here

https://abdur-rahmaanj.github.io/pyfaq/[list]_Single_or_double_quotes.html

The index has some some more summaries:

https://abdur-rahmaanj.github.io/pyfaq/
<https://abdur-rahmaanj.github.io/pyfaq/>

I auto pull the messages with some manual edits like
filtering empty mails etc

Mr Christopher maintains one for python-ideas
https://github.com/PythonCHB/PythonListsSummaries

This one is intended to have even some common questions
like where do i start etc

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue40432] Pegen regenerate project for Windows not working

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40432] Pegen regenerate project for Windows not working

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 9b64ef3ac7b434065dbff0048b9103999e4b491a by Anthony Shaw in 
branch 'master':
bpo-40432 Fix MSBuild project for Pegen grammars (#GH-9785)
https://github.com/python/cpython/commit/9b64ef3ac7b434065dbff0048b9103999e4b491a


--

___
Python tracker 
<https://bugs.python.org/issue40432>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40432] Pegen regenerate project for Windows not working

[anthony shaw]

Change by anthony shaw :


--
keywords: +patch
pull_requests: +19108
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19785

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40432] Pegen regenerate project for Windows not working

[anthony shaw]

New submission from anthony shaw :

The additional tasks in the MSBuild project for pegen regeneration are not 
functional:

- Setting PYTHONPATH= inline cannot be done in Windows using that method
- The task does not inherit environment variables that way
- The path to the peg_generator module is in Unix path format

PR to follow

--
assignee: anthonypjshaw
components: Build
messages: 367613
nosy: anthonypjshaw, pablogsal
priority: normal
severity: normal
status: open
title: Pegen regenerate project for Windows not working
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40432>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40293] cpython-source-deps project missing release for libffi commits

[Gregory Szorc]

Gregory Szorc  added the comment:

I don't like utilizing the dynamic archive links like 
https://github.com/python/cpython-source-deps/archive/libffi.zip (even if you 
pin the commit) because GitHub does not guarantee the file content is 
deterministic over time. I perform SHA-256 validation of all dependencies I 
download from the Internet. And if I rely on the /archive/ URLs, all it takes 
is GitHub updating some library that subtly changes the tar/zip structure and 
my hashes are invalidated.

Release artifacts are immutable and don't have this problem.

As it stands, I will likely `git clone` and check out the commit I need. 
Although I would prefer a release artifact.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40293] cpython-source-deps project missing release for libffi commits

[Steve Dower]

Steve Dower  added the comment:

To save the clicks, here's the URL that will get the latest sources from the 
libffi branch: https://github.com/python/cpython-source-deps/archive/libffi.zip

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40293] cpython-source-deps project missing release for libffi commits

[Steve Dower]

Steve Dower  added the comment:

In master, we build against the latest build out of that repo, which comes from 
the libffi branch (not the 3.3.0 RC).

In 3.8 (and 3.7? I forget) we use the 3.3.0 RC build. There's no later release 
from libffi (last I checked), and no important fixes since then (only ARM64 
support, which we contributed).

We'll probably tag for 3.9.0b1 and retarget the master branch to take that one, 
so that we can control updates that go into that release. But right now there 
isn't anything we want to tag right now (and GitHub generates the tarball 
itself, so we don't have to upload anything - you can get the branch tip 
through the "Download" button on the front page).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40293] cpython-source-deps project missing release for libffi commits

[Gregory Szorc]

New submission from Gregory Szorc :

The https://github.com/python/cpython-source-deps project is missing a source 
archive release for commits to libffi needed to support building on Windows.

The latest release of libffi is version libffi-3.3.0-rc0-r1, which corresponds 
to 
https://github.com/python/cpython-source-deps/commit/8ba2b2c38744420a235e3e7f419cce2591aaf331.

There have been a few commits since that release: 
https://github.com/python/cpython-source-deps/compare/8ba2b2c38744420a235e3e7f419cce2591aaf331...libffi

Most notable is 
https://github.com/python/cpython-source-deps/commit/ed22026f39b37f892ded95d7b30e77dfb5126334
 because without this commit, the source is not buildable on Windows using 
MSVC, at least not with the  prepare_ffi.bat script in CPython's Git 
repository. (Build fails due to issues with FFI_BUILDING_DLL).

Would it be possible to cut a new tag and upload a source tarball for libffi?

--
components: Build, Windows
messages: 366523
nosy: indygreg, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: cpython-source-deps project missing release for libffi commits
type: enhancement

___
Python tracker 
<https://bugs.python.org/issue40293>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

My New Project : Aduct

[J.Arun Mani via Python-list]

Hello,
I made my first Python package that can be installed via PIP. It is called 
"Aduct".
https://github.com/atornel/Aduct.
Aduct is a toolkit to design graphical applications that can be dynamically 
changed with a little work as possible. It is designed by inheriting objects 
provided by [Gtk](http://www.gtk.org/) and thus by following principles of 
Aduct with Gtk, one can make powerful applications that are easy for a 
developer to develop, third-party person to improve and end user to use.
Put simply, Aduct lets you make complex interfaces which can be easily changed 
by users without any trouble.
What help I need :
This is my first project where I put a much work in writing docs and things. So 
I'm a pretty noob who needs a help from various people with different ideas. 
Hence I kindly request you to spend time with Aduct (if you can) :
1. Use Aduct - please use it and tell me your feedback, I will be really happy
2. Requesting features and reporting bugs - as already said, you might have a 
different perspective of how a feature should work, I welcome those.
3. Criticisms - They are always hurting, but still I'm ready to face it.
4. Sharing with others - If you think that there is someone who can make use of 
Aduct, you can help by sharing Aduct.
5. Writing docs - The docs could be unclear, could be improved, you can help me 
here.
6. Improving source code - I salute those brave hearts who are ready to dive 
into business of coding. Don't worry, formatting won't be so poor, I used 
Black, Pylint, Bandit to make it readable and powerful.
7. Star it - The most easy one; it encourages me.

This is not any spam or promotion. Aduct is released in LGPL license and is 
completely free. Improving and using Aduct, strengthens the community work, 
meaning of open source, gives me a satisfaction.

Thank you for reading till here,
J Arun Mani
:)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: NLP Project with Python

[Souvik Dutta]

I thought about an app that would be similar to Google's current sound
recording that records sounds and turns them into words and characters. I
was thinking that you might be able to make an app or atleast a program
that takes a picture and saves it in the form of text document which could
be played when someone wants.

For example let us suppose you take a picture of a book. The program should
be able to extract all the words and save them in form of a text file. It
should also be able to play the file that is convert it into an audiobook
when requested to do so.

I think this will take time.

Souvik flutter dev

On Wed, Apr 8, 2020, 12:45 PM  wrote:

> Hello everyone
> I`m new to python. I need to select a project idea so that I can work with
> it during this semester. the project should be in the area of business and
> finance
> at first I was thinking of creating a project using NLP but I don`t know
> what exactly to create
> also I would like to create something related to blockchain, such as
> tracking the currency at which its sold and bought, customers reviews and
> the value of cryptocurrencies during this outbreak of the coronavirus
> I welcome all your ideas just please inspire me. I`m lost in my own
> thoughts.
> thanks in advance
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: NLP Project with Python

[joseph pareti]

if you want to do work in NLP there are numerous opportunities, especially
with the virus oubreak
see e.g.
https://www.cnbc.com/2020/03/03/bluedot-used-artificial-intelligence-to-predict-coronavirus-spread.html

Am Mi., 8. Apr. 2020 um 09:18 Uhr schrieb :

> Hello everyone
> I`m new to python. I need to select a project idea so that I can work with
> it during this semester. the project should be in the area of business and
> finance
> at first I was thinking of creating a project using NLP but I don`t know
> what exactly to create
> also I would like to create something related to blockchain, such as
> tracking the currency at which its sold and bought, customers reviews and
> the value of cryptocurrencies during this outbreak of the coronavirus
> I welcome all your ideas just please inspire me. I`m lost in my own
> thoughts.
> thanks in advance
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
Regards,
Joseph Pareti - Artificial Intelligence consultant
Joseph Pareti's AI Consulting Services
https://www.joepareti54-ai.com/
cell +49 1520 1600 209
cell +39 339 797 0644
-- 
https://mail.python.org/mailman/listinfo/python-list

NLP Project with Python

[dreamyladygirl]

Hello everyone
I`m new to python. I need to select a project idea so that I can work with it 
during this semester. the project should be in the area of business and finance
at first I was thinking of creating a project using NLP but I don`t know what 
exactly to create
also I would like to create something related to blockchain, such as tracking 
the currency at which its sold and bought, customers reviews and the value of 
cryptocurrencies during this outbreak of the coronavirus
I welcome all your ideas just please inspire me. I`m lost in my own thoughts.
thanks in advance 
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue38814] Python3.7.5 crashes on OSX with my django project

[László Károlyi]

László Károlyi  added the comment:

Hey,

the problem normalized after installing the newest version of cryptography, 
with which I could reproduce the same problem too.

It turned out that asn1crypto wasn't even needed in my project.

Sorry for the inconvenience, and thank you for your help.

--

___
Python tracker 
<https://bugs.python.org/issue38814>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38814] Python3.7.5 crashes on OSX with my django project

[Ned Deily]

Ned Deily  added the comment:

Sorry, we have strayed from dealing with a Python issue here so, if you need 
nore assistance, you really should seek help elsewhere.  But a quick web search 
found this which seems to describe your problem:

https://github.com/wbond/asn1crypto/issues/113

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38814] Python3.7.5 crashes on OSX with my django project

[László Károlyi]

László Károlyi  added the comment:

Upon reinstalling openssl with homebrew, I get the following info:

--
openssl is keg-only, which means it was not symlinked into /usr/local,
because Apple has deprecated use of OpenSSL in favor of its own TLS and crypto 
libraries.

If you need to have openssl first in your PATH run:
  echo 'set -g fish_user_paths "/usr/local/opt/openssl/bin" $fish_user_paths' 
>> ~/.config/fish/config.fish

For compilers to find openssl you may need to set:
  set -gx LDFLAGS "-L/usr/local/opt/openssl/lib"
  set -gx CPPFLAGS "-I/usr/local/opt/openssl/include"

For pkg-config to find openssl you may need to set:
  set -gx PKG_CONFIG_PATH "/usr/local/opt/openssl/lib/pkgconfig"


So assumingly the system-wide library should be preferred, may it be whatever 
one.

`/usr/bin/openssl version` says LibreSSL 2.8.3.

Probably I could still link to the homebrew installed SSL using the provided 
flags, but I'm quite sure this same problem will pop up at a lot of other 
Catalina users.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38814] Python3.7.5 crashes on OSX with my django project

[Ned Deily]

Ned Deily  added the comment:

Almost any kind of crash is possible when using ctypes.  But you almost 
certainly don't want to be loading /usr/lib/libcrypto.dylib.  That's the macOS 
legacy version which is there only for legacy Apple-supplied third-party 
components, like the Apple-supplie system Python.  Apple doesn't even supply 
the header files for the system libssl and libcrypto deliberately so you are 
not supposed to be able to successfully link with them.  So you should try to 
figure out why asn1crypto is apparently linked with it.  It should likely be 
trying to link with a libcrypto provided by Homebrew openssl.  Good luck.

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38814] Python3.7.5 crashes on OSX with my django project

[László Károlyi]

László Károlyi  added the comment:

Here's an md5sum of /usr/lib/libcrypto.dylib:

MD5 (/usr/lib/libcrypto.dylib) = d19ca8b227c32d30f92ed0665dfe73d0

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38814] Python3.7.5 crashes on OSX with my django project

[László Károlyi]

László Károlyi  added the comment:

As I'm triangulating the problem down, I can now reproduce the problem without 
running django:

python -X faulthandler -c 'from asn1crypto._perf import _big_num_ctypes'

gives the output:

Fatal Python error: Aborted

Current thread 0x000117155dc0 (most recent call first):
  File 
"/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ctypes/__init__.py",
 line 364 in __init__
  File 
"/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/asn1crypto/_perf/_big_num_ctypes.py",
 line 39 in 
  File "", line 219 in _call_with_frames_removed
  File "", line 728 in exec_module
  File "", line 677 in _load_unlocked
  File "", line 967 in _find_and_load_unlocked
  File "", line 983 in _find_and_load
  File "", line 219 in _call_with_frames_removed
  File "", line 1035 in _handle_fromlist
  File "", line 1 in 
fish: 'python -X faulthandler -c 'from…' terminated by signal SIGABRT (Abort)

I took the opportunity to see what library loading fails, by printing 
self._name and mode before line 365 in ctypes/__init__.py:

It tries to load /usr/lib/libcrypto.dylib with mode 4, and that's where it 
crashes.

--
status: closed -> open

___
Python tracker 
<https://bugs.python.org/issue38814>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38814] Python3.7.5 crashes on OSX with my django project

[László Károlyi]

László Károlyi  added the comment:

So after making the changes, recompiling everything and using `python -X 
faulthandler backend/manage.py runserver --nothreading --noasgi --noreload` to 
start django without the autoreloader that hides the crashed process' output, 
here's what I get:

  File 
"/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ctypes/__init__.py",
 line 364 in __init__
  File 
"/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/asn1crypto/_perf/_big_num_ctypes.py",
 line 39 in 
  File "", line 219 in _call_with_frames_removed
  File "", line 728 in exec_module
  File "", line 677 in _load_unlocked
  File "", line 967 in _find_and_load_unlocked
  File "", line 983 in _find_and_load
  File 
"/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/asn1crypto/_int.py",
 line 56 in 
  File "", line 219 in _call_with_frames_removed
  File "", line 728 in exec_module
  File "", line 677 in _load_unlocked
  File "", line 967 in _find_and_load_unlocked
  File "", line 983 in _find_and_load
  File 
"/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/asn1crypto/_elliptic_curve.py",
 line 51 in 
  File "", line 219 in _call_with_frames_removed
  File "", line 728 in exec_module
  File "", line 677 in _load_unlocked
  File "", line 967 in _find_and_load_unlocked
  File "", line 983 in _find_and_load
  File 
"/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/asn1crypto/keys.py",
 line 22 in 
  File "", line 219 in _call_with_frames_removed
  File "", line 728 in exec_module
  File "", line 677 in _load_unlocked
  File "", line 967 in _find_and_load_unlocked
  File "", line 983 in _find_and_load
  File 
"/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/cryptography/x509/extensions.py",
 line 14 in 
  File "", line 219 in _call_with_frames_removed
  File "", line 728 in exec_module
  File "", line 677 in _load_unlocked
  File "", line 967 in _find_and_load_unlocked
  File "", line 983 in _find_and_load
  File 
"/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/cryptography/x509/base.py",
 line 16 in 
  File "", line 219 in _call_with_frames_removed
  File "", line 728 in exec_module
  File "", line 677 in _load_unlocked
  File "", line 967 in _find_and_load_unlocked
  File "", line 983 in _find_and_load
  File 
"/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/cryptography/x509/__init__.py",
 line 8 in 
  File "", line 219 in _call_with_frames_removed
  File "", line 728 in exec_module
  File "", line 677 in _load_unlocked
  File "", line 967 in _find_and_load_unlocked
  File "", line 983 in _find_and_load
  File "", line 219 in _call_with_frames_removed
  File "", line 1035 in _handle_fromlist
  File 
"/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/cryptography/hazmat/backends/openssl/backend.py",
 line 18 in 
  File "", line 219 in _call_with_frames_removed
  File "", line 728 in exec_module
  File "", line 677 in _load_unlocked
  File "", line 967 in _find_and_load_unlocked
  File "", line 983 in _find_and_load
  File 
"/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/cryptography/hazmat/backends/openssl/__init__.py",
 line 7 in 
  File "", line 219 in _call_with_frames_removed
  File "", line 728 in exec_module
  File "", line 677 in _load_unlocked
  File "", line 967 in _find_and_load_unlocked
  File "", line 983 in _find_and_load
  File "", line 219 in _call_with_frames_removed
  File "", line 953 in _find_and_load_unlocked
  File "", line 983 in _find_and_load
  File 
"/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/cryptography/hazmat/backends/__init__.py",
 line 15 in default_backend
  File 
"/Users/laszlokarolyi/Work/project/backend/ticketshop/printing/api/v1/qz_signer.py",
 line 19 in 
  File "", line 219 in _call_with_frames_removed
  File "", line 728 in exec_module
  File "", line 677 in _load_unlocked
  File "", line 967 in _find_and_load_unlocked
  File "", line 983 in _find_and_load
  File 
"/Users/laszlokarolyi/Work/project/backend/ticketshop/printing/api/urls.py", 
line 4 in 
  File "", line 219 in _call_with_frames_removed
  File "", line 728 in exec_module
  File "", line 67

[issue38814] Python3.7.5 crashes on OSX with my django project

[Ned Deily]

Ned Deily  added the comment:

The stack track is pretty suspicious.  I really don't know why it would be 
crashing where it shows which seems to be pretty early in the interpreter.  If 
you haven't already, you might just want to try reinstalling from Homebrew 
first and try again.  If you do try a debug build and it still crashes, the 
stack trace should be very explicit about where it is crashing.

--
status: pending -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38814] Python3.7.5 crashes on OSX with my django project

[Ned Deily]

Change by Ned Deily :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38814] Python3.7.5 crashes on OSX with my django project

[László Károlyi]

László Károlyi  added the comment:

Hello,

the only C extension I use is xapian and mysql (with mariadb), xapian comes 
from their own git repo, and mariadb comes from mysqlclient, both (and 
everything else I don't know about) compile with the python 3.7.5 I installed 
within a venv.

I'll try to recompile python with the debug mode enabled, and then reinstall 
the entire venv to see what debug I get.

Where should I look for debug logs then?

Also, as you might have seen from the irc logs and the pastebin links posted 
there, python crashes somewhere around reading the django language directories, 
for a mystical reason. Yet to be found out.

--
status: closed -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38814] Python3.7.5 crashes on OSX with my django project

[Ned Deily]

Ned Deily  added the comment:

Sorry but with a non-debug build of Python, it's not very likely someone would  
be able to glean much from the macOS crash stack trace here.  You also seem to 
have a very large number of C extension modules, some apparently from Homebrew 
and others from other sources ("/Users/USER/*/" ?). Also, I don't understand 
what you mean by:

"I use homebrew with the latest packages and python3.7.5 is now compiled from 
source, to avoid dependency problems."

And it seems you were reporting lots of problems on IRC beyond what is reported 
here.

The best I can suggest is to try to ensure that all binaries you are using are 
all from one source, for example, Homebrew or conda, and make sure any packages 
with C extension modules are built using the same python instance.  If the 
problem persists, you may need to consider installing a debug version of Python 
or building one from source (./configure --with-pydebug ... ) but for 3.7.x at 
least that means you will also need to rebuild all packages that have C 
extension modules as debug mode has a different ABI.

Please feel free to reopen this issue with a reproducible test case if further 
investigation suggests a problem with Python itself.  Good luck!

--
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38814] Python3.7.5 crashes on OSX with my django project

[László Károlyi]

New submission from László Károlyi :

Hey,

I have a huge Django project that starts up fine with the dev server on Linux 
and in production that is also Linux. Whenever I try to start it on my OSX, the 
python process crashes with a SIGABRT and I get a crash window from OSX.

I use homebrew with the latest packages and python3.7.5 is now compiled from 
source, to avoid dependency problems.

Here's the log:
Process:   Python [85125]
Path:  
/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python
Identifier:Python
Version:   3.7.5 (3.7.5)
Code Type: X86-64 (Native)
Parent Process:fish [1857]
Responsible:   Terminal [1732]
User ID:   501

Date/Time: 2019-11-15 17:39:46.178 +0100
OS Version:Mac OS X 10.15.1 (19B88)
Report Version:12
Anonymous UUID:CC50B63E-FBC1-6461-576B-EE6AF1E52EFE

Sleep/Wake UUID:   A2774262-4258-4B95-8AAF-642CDEF9014E

Time Awake Since Boot: 28 seconds
Time Since Wake:   710 seconds

System Integrity Protection: enabled

Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_CRASH (SIGABRT)
Exception Codes:   0x, 0x
Exception Note:EXC_CORPSE_NOTIFY

Termination Signal:Abort trap: 6
Termination Reason:Namespace SIGNAL, Code 0x6
Terminating Process:   Python [85125]

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib  0x7fff67936e1a __kill + 10
1   org.python.python   0x000100ab0614 os_kill + 57
2   org.python.python   0x0001009d910c 
_PyMethodDef_RawFastCallKeywords + 488
3   org.python.python   0x0001009d8698 
_PyCFunction_FastCallKeywords + 41
4   org.python.python   0x000100a6cfd0 call_function + 628
5   org.python.python   0x000100a65fab 
_PyEval_EvalFrameDefault + 6767
6   org.python.python   0x0001009d8a6c 
function_code_fastcall + 106
7   org.python.python   0x000100a6d03d call_function + 737
8   org.python.python   0x000100a66046 
_PyEval_EvalFrameDefault + 6922
9   org.python.python   0x000100a6d831 
_PyEval_EvalCodeWithName + 1698
10  org.python.python   0x0001009d8660 
_PyFunction_FastCallKeywords + 212
11  org.python.python   0x000100a6d03d call_function + 737
12  org.python.python   0x000100a65fab 
_PyEval_EvalFrameDefault + 6767
13  org.python.python   0x000100a6d831 
_PyEval_EvalCodeWithName + 1698
14  org.python.python   0x0001009d82d8 
_PyFunction_FastCallDict + 444
15  org.python.python   0x0001009d93df 
_PyObject_Call_Prepend + 131
16  org.python.python   0x0001009d87a5 PyObject_Call + 136
17  org.python.python   0x000100a6628f 
_PyEval_EvalFrameDefault + 7507
18  org.python.python   0x000100a6d831 
_PyEval_EvalCodeWithName + 1698
19  org.python.python   0x0001009d82d8 
_PyFunction_FastCallDict + 444
20  org.python.python   0x0001009d93df 
_PyObject_Call_Prepend + 131
21  org.python.python   0x0001009d87a5 PyObject_Call + 136
22  org.python.python   0x000100a6628f 
_PyEval_EvalFrameDefault + 7507
23  org.python.python   0x000100a6d831 
_PyEval_EvalCodeWithName + 1698
24  org.python.python   0x0001009d82d8 
_PyFunction_FastCallDict + 444
25  org.python.python   0x0001009d93df 
_PyObject_Call_Prepend + 131
26  org.python.python   0x0001009d87a5 PyObject_Call + 136
27  org.python.python   0x000100a6628f 
_PyEval_EvalFrameDefault + 7507
28  org.python.python   0x000100a6d831 
_PyEval_EvalCodeWithName + 1698
29  org.python.python   0x0001009d82d8 
_PyFunction_FastCallDict + 444
30  org.python.python   0x0001009d93df 
_PyObject_Call_Prepend + 131
31  org.python.python   0x0001009d87a5 PyObject_Call + 136
32  org.python.python   0x000100a6628f 
_PyEval_EvalFrameDefault + 7507
33  org.python.python   0x000100a6d831 
_PyEval_EvalCodeWithName + 1698
34  org.python.python   0x0001009d82d8 
_PyFunction_FastCallDict + 444
35  org.python.python   0x0001009d93df 
_PyObject_Call_Prepend + 131
36  org.python.python   0x0001009d87a5 PyObject_Call + 136
37  org.python.python   0x000100a6628f 
_PyEval_EvalFrameDefault + 7507
38  org.python.python   0x0001009d8a6c 
function_code_fastcall + 106
39

Discontinuing the pymssql Project

[Randy Syring]

I believe it's become necessary to discontinue the pymssql project. 
Pymssql is a dbapi2 drive for Microsoft SQL server.


Full Announcement: https://github.com/pymssql/pymssql/issues/668

Thank you to everyone who has contributed to pymssql over the years. 
Unfortunately, I believe it's time to discontinue pymssql. It provides 
an incredible amount of utility to those of us that need to connect to 
MSSQL from Python. But, as a project, it has failed to attract enough 
interest/talent/funding to maintain it.


Why discontinue it and not let someone else maintain it? We've tried 
over the years. See #516 
<https://github.com/pymssql/pymssql/issues/516>. We have got a few 
people drop by to help occasionally, but nothing sustained enough to 
feel like transfer of the project was warranted.


I had always hoped my consulting business would be able to help 
maintain the library for clients that use it. But there is too much 
work here for us to tackle that doesn't really benefit our client's 
usage and we transitioned to PyODBC earlier this year.


I'm also concerned that if I simply abandon the project a bad actor 
could gain control and start installing nasty stuff on what I am sure 
is a lot of corporate servers.


It's my hope that by discontinuing this project better solutions will 
be developed and/or adopted to take it's place.



  Other Related Issues

  * Proposal to discontinue pymssql in favor of pyodbc #477
<https://github.com/pymssql/pymssql/issues/477>
  * Maintainers Needed - Apply Within #516
<https://github.com/pymssql/pymssql/issues/516>
  * Finding grants/funding for pymssql development #621
<https://github.com/pymssql/pymssql/issues/621>


  Alternatives

  * pyodbc <https://github.com/mkleehammer/pyodbc>: Microsoft backed
  o But see: https://github.com/level12/sqlalchemy_pyodbc_mssql
  * ctds <https://github.com/zillow/ctds>: by Zillow


  Interested in Taking Over?

Just fork pymssql and start your own project. Gain momentum, show 
progress, and I'd be happy to link to your project from here.



  Next Steps

I'm going to leave this issue open for suggestions on how best to 
deprecate/discontinue pymssql as a project. I'm sure there will be 
some who will suddenly be very interested in helping. I won't be 
considering those requests at this point. If you want to help, see 
above about forking.


At the end of November, 2019 I'm going to Archive this GH repository 
which will make it read-only.


I'll also need to figure out how to deprecate packages on PyPI so that 
people installing know the project is being discontinued.





*Randy Syring*
Husband | Father | Redeemed Sinner

/"For what does it profit a man to gain the whole world
and forfeit his soul?" (Mark 8:36 ESV)/

--
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/

   Support the Python Software Foundation:
   http://www.python.org/psf/donations/

Re: Would you be interested in this Python open source project?

[oliver]

There are tons of projects that need help, I recommend that instead of
re-inventing the wheel as there are enough choices out there re cicd and
very likely you will find that your goal of 10/90 is unrealistic.

Have a look at codetriage.com, and github has a feature that allows you to
search for projects that need help.

Another major advantage of helping an existing project is that you will be
seeing how others write python code so you will learn best practices faster
(dont kid yourself, if you do it on your own the code you write now you
will find horrible in a year, and you certainly will not be interested in
rewriting it!).

Keep up the good work!

On Wed., Oct. 9, 2019, 08:35 Simon Connah,  wrote:

>
> On 08/10/2019 15:05, Bill Deegan wrote:
> > You might just consider working with the BuildBot project to add support
> > for lighter weight build workers.
> > Re-Re-Re-inventing the wheel is almost always wasted effort.
>
> Buildbot looks good. I'll check to make sure its open source license is
> compatible with the Affero General Public License version 3. On the
> other hand I do have a desire to build something similar myself just to
> get the hang of things like this. Thank you for your reply.
>
> > On Tue, Oct 8, 2019 at 8:33 AM Rhodri James 
> wrote:
> >
> >> On 08/10/2019 11:22, Simon Connah wrote:
> >>> I'm posting this message as a way to gauge interest in the project and
> >>> to see if it is worth moving forward with. There are probably hundreds
> >>> of CI/CD tools out there and many more general devops tools but what I
> >>> want to build is a CI/CD tool that ONLY supports Python 3.6 or greater
> >>> and only runs on one Linux distribution (my preference is Ubuntu). This
> >>> way configuration would be much more simple than the vast majority of
> >>> devops tools which try to support every programming language that is
> >>> popular (or so it seems) on many different Linux distributions and even
> >>> Windows and macOS.
> >>>
> >>> My theory is that if you limit the devops tool to a very limited
> >>> subsection of the available options the system will be easier to
> >>> configure for users, more stable, easier to patch bugs in and generally
> >>> just be a better all around things for Python developers.
> >>>
> >>> I'd love to hear some feedback on the idea.
> >>>
> >> I think your reasoning is sound.  I probably wouldn't make a lot of use
> >> of it, but I live in Embedded Systems land where it's notoriously hard
> >> to do CI off the target silicon.  Other people living in more tractable
> >> problem spaces will probably be more enthusiastic.
> >>
> >> --
> >> Rhodri James *-* Kynesim Ltd
> >> --
> >> https://mail.python.org/mailman/listinfo/python-list
> >>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Would you be interested in this Python open source project?

[Simon Connah]

On 08/10/2019 15:05, Bill Deegan wrote:

You might just consider working with the BuildBot project to add support
for lighter weight build workers.
Re-Re-Re-inventing the wheel is almost always wasted effort.


Buildbot looks good. I'll check to make sure its open source license is 
compatible with the Affero General Public License version 3. On the 
other hand I do have a desire to build something similar myself just to 
get the hang of things like this. Thank you for your reply.



On Tue, Oct 8, 2019 at 8:33 AM Rhodri James  wrote:


On 08/10/2019 11:22, Simon Connah wrote:

I'm posting this message as a way to gauge interest in the project and
to see if it is worth moving forward with. There are probably hundreds
of CI/CD tools out there and many more general devops tools but what I
want to build is a CI/CD tool that ONLY supports Python 3.6 or greater
and only runs on one Linux distribution (my preference is Ubuntu). This
way configuration would be much more simple than the vast majority of
devops tools which try to support every programming language that is
popular (or so it seems) on many different Linux distributions and even
Windows and macOS.

My theory is that if you limit the devops tool to a very limited
subsection of the available options the system will be easier to
configure for users, more stable, easier to patch bugs in and generally
just be a better all around things for Python developers.

I'd love to hear some feedback on the idea.


I think your reasoning is sound.  I probably wouldn't make a lot of use
of it, but I live in Embedded Systems land where it's notoriously hard
to do CI off the target silicon.  Other people living in more tractable
problem spaces will probably be more enthusiastic.

--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list


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

Re: Would you be interested in this Python open source project?

[Simon Connah]

On 08/10/2019 13:17, Rhodri James wrote:

On 08/10/2019 11:22, Simon Connah wrote:
I'm posting this message as a way to gauge interest in the project 
and to see if it is worth moving forward with. There are probably 
hundreds of CI/CD tools out there and many more general devops tools 
but what I want to build is a CI/CD tool that ONLY supports Python 
3.6 or greater and only runs on one Linux distribution (my preference 
is Ubuntu). This way configuration would be much more simple than the 
vast majority of devops tools which try to support every programming 
language that is popular (or so it seems) on many different Linux 
distributions and even Windows and macOS.


My theory is that if you limit the devops tool to a very limited 
subsection of the available options the system will be easier to 
configure for users, more stable, easier to patch bugs in and 
generally just be a better all around things for Python developers.


I'd love to hear some feedback on the idea.



I think your reasoning is sound.  I probably wouldn't make a lot of 
use of it, but I live in Embedded Systems land where it's notoriously 
hard to do CI off the target silicon.  Other people living in more 
tractable problem spaces will probably be more enthusiastic.


Thank you for your reply. I'll keep working on this project and see how 
it turns out. I'm quite excited about it actually as I find that most 
CI/CD systems are so complicated when it comes to simple tasks. I want 
to build something where the developer spends 10 minutes reading the 
documentation and then can do 90% of what he needs with no more hand 
holding or Googling.


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

Re: Would you be interested in this Python open source project?

[Bill Deegan]

You might just consider working with the BuildBot project to add support
for lighter weight build workers.
Re-Re-Re-inventing the wheel is almost always wasted effort.

On Tue, Oct 8, 2019 at 8:33 AM Rhodri James  wrote:

> On 08/10/2019 11:22, Simon Connah wrote:
> > I'm posting this message as a way to gauge interest in the project and
> > to see if it is worth moving forward with. There are probably hundreds
> > of CI/CD tools out there and many more general devops tools but what I
> > want to build is a CI/CD tool that ONLY supports Python 3.6 or greater
> > and only runs on one Linux distribution (my preference is Ubuntu). This
> > way configuration would be much more simple than the vast majority of
> > devops tools which try to support every programming language that is
> > popular (or so it seems) on many different Linux distributions and even
> > Windows and macOS.
> >
> > My theory is that if you limit the devops tool to a very limited
> > subsection of the available options the system will be easier to
> > configure for users, more stable, easier to patch bugs in and generally
> > just be a better all around things for Python developers.
> >
> > I'd love to hear some feedback on the idea.
> >
>
> I think your reasoning is sound.  I probably wouldn't make a lot of use
> of it, but I live in Embedded Systems land where it's notoriously hard
> to do CI off the target silicon.  Other people living in more tractable
> problem spaces will probably be more enthusiastic.
>
> --
> Rhodri James *-* Kynesim Ltd
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Would you be interested in this Python open source project?

[Rhodri James]

On 08/10/2019 11:22, Simon Connah wrote:
I'm posting this message as a way to gauge interest in the project and 
to see if it is worth moving forward with. There are probably hundreds 
of CI/CD tools out there and many more general devops tools but what I 
want to build is a CI/CD tool that ONLY supports Python 3.6 or greater 
and only runs on one Linux distribution (my preference is Ubuntu). This 
way configuration would be much more simple than the vast majority of 
devops tools which try to support every programming language that is 
popular (or so it seems) on many different Linux distributions and even 
Windows and macOS.


My theory is that if you limit the devops tool to a very limited 
subsection of the available options the system will be easier to 
configure for users, more stable, easier to patch bugs in and generally 
just be a better all around things for Python developers.


I'd love to hear some feedback on the idea.



I think your reasoning is sound.  I probably wouldn't make a lot of use 
of it, but I live in Embedded Systems land where it's notoriously hard 
to do CI off the target silicon.  Other people living in more tractable 
problem spaces will probably be more enthusiastic.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Would you be interested in this Python open source project?

[Simon Connah]

I'm posting this message as a way to gauge interest in the project and 
to see if it is worth moving forward with. There are probably hundreds 
of CI/CD tools out there and many more general devops tools but what I 
want to build is a CI/CD tool that ONLY supports Python 3.6 or greater 
and only runs on one Linux distribution (my preference is Ubuntu). This 
way configuration would be much more simple than the vast majority of 
devops tools which try to support every programming language that is 
popular (or so it seems) on many different Linux distributions and even 
Windows and macOS.


My theory is that if you limit the devops tool to a very limited 
subsection of the available options the system will be easier to 
configure for users, more stable, easier to patch bugs in and generally 
just be a better all around things for Python developers.


I'd love to hear some feedback on the idea.

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

[issue24479] Support LMMS project files in mimetypes.guess_type

[STINNER Victor]

Change by STINNER Victor :


--
keywords:  -easy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24479] Support LMMS project files in mimetypes.guess_type

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24479] Support LMMS project files in mimetypes.guess_type

[Dong-hee Na]

Dong-hee Na  added the comment:

@vstiner

I'd like to work on this issue.
My plan is adding mime-types as 'mmp' to 'application/x-lmms-project'  and 
'mmpz' to 'application/x-lmms-project' 
What do you think?

--
nosy: +corona10

___
Python tracker 
<https://bugs.python.org/issue24479>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24479] Support LMMS project files in mimetypes.guess_type

[STINNER Victor]

STINNER Victor  added the comment:

This issue is 4 years old and has patches: it is no newcomer friendly, I remove 
the "easy" keyword.

--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37156] Fix libssl DLL tag in Tools/msi project

[Ned Deily]

Ned Deily  added the comment:


New changeset 9ad5e9edea08b0d377902d556624f03a2b8bb29b by Ned Deily (Steve 
Dower) in branch '3.7':
bpo-37156: Fix libssl DLL tag in MSI sources (GH-14219)
https://github.com/python/cpython/commit/9ad5e9edea08b0d377902d556624f03a2b8bb29b


--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37156] Fix libssl DLL tag in Tools/msi project

[Steve Dower]

Steve Dower  added the comment:


New changeset 43b97ae15c8cbb8c383314bb75c867d0f2f34376 by Steve Dower in branch 
'3.7':
bpo-37156: Fix libssl DLL tag in MSI sources (GH-14219)
https://github.com/python/cpython/commit/43b97ae15c8cbb8c383314bb75c867d0f2f34376


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37156] Fix libssl DLL tag in Tools/msi project

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +14057
pull_request: https://github.com/python/cpython/pull/14219

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: What's the latest best practice on Python project directory layouts?

[Cameron Simpson]

On 14Jun2019 09:23, Malcolm Greene  wrote:

I have a collection of command line scripts that share a collection of common 
modules. This code collection is for internal use and will run under a single 
version of Python 3.6+ and a single OS. My understanding of best practice is to 
organize this collection of Python files into a folder structure like this:

# common files
.gitignore
readme.md
requirements.txt
setup.py  <--- what is the advantage of this file for internally distributed 
code bases?

# app specific package folders
app-1
   __init__.py (optional; if needed)
   __main__.py
   app-1-module-1.py
   app-1-module-2.py
   app-1-module-N.py

app-2
   __init__.py (optional; if needed)
   __main__.py
   app-2-module-1.py
   app-2-module-2.py
   app-2-module-N.py

# modules shared across multiple apps
common
   common-module-1.py
   common-module-2.py
   common-module-N.py

# tests - place at package level with sub-packages for each package -OR- 
underneath each app package?
tests
   app-1
test_app-1-module-1.py
test_app-1-module-2.py
test_app-1-module-N.py
   app-2
test_app-2-module-1.py
test_app-2-module-2.py
test_app-2-module-N.py

# virtual env folder placed at same level as packages ???
venv
   

And execute each app via the following ...

python -m app-1 

Questions

1. Does the above structure sound reasonable?


Yes. Though I like to get them out of the top directory, details below.


2. Where to place virtual env files and what to call this folder? venv, .env, 
etc?


I use "venv" myself.


3. Where to put tests (pytest)? In a tests folder or under each package?


Personally, I'd do it however you would do them if the apps and the 
common modules were standalone. I use a foo_tests.py beside my foo.py 
module file myself, but a naming scheme adhering to the discoverability 
of your test running tool would also be a good choice.


4. Use a src folder or not? If so, where to put above files relative to 
the src folder?


Well, yeah. Always a subdirectory, I hate littering the top level.

Here is how I lay out a project, based on my current one (nonPython bits 
elided):


 project/
   bin/
   lib/python/all-modules-here
   venv/

Various points:

- I dislike using Python's "search for modules in the current 
 directory"; I would _always_ rather set $PYTHONPATH for specific 
 control.


- The lib/python depth is to accomodate lib/other-languages according to 
 the mix in the project.


Some context: I'm making a full stack app for a client at present. The 
client's code is like this:


 lib/python/clientname/appname/*.py

It happens that all the "common" code is in the appname subdirectory 
because it is self contained, but were it not it would be in


 lib/python/clientname/*.py

or possibly

 lib/python/clientname/util/*.py

(or "common" if you prefer).

One important aspect of this is that it lets me keep the client code 
away from conflicts with other library names, so the "clientname" module 
path component is important for this, _and_ it better labels the purpose 
of the module.


So the environment setup looks like this:

 project=/path/to/project  # or $(dirname "$0") if $0 is useful
 PYTHONPATH=$project/lib/python
 PATH=$project/bin:$project/venv/bin:$PATH
 export PYTHONPATH PATH

and the app is run:

 python -m clientname.appname args...

The app does relative imports for itself:

 from .util import SomeAppClass

and would import common code absolutely:

 from clientname.util import SomeCommonClass

In my current project I've actually got a small shell script which does 
the environment setup above and invokes the python app (or various other 
utility tasks like "init the database" etc). I find this approach 
generally useful.


Anyway, this might inform what choices you make. Happy to elaborate on 
specifics, though they get more personal and idiosyncratic the more fine 
grained we get.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

What's the latest best practice on Python project directory layouts?

[Malcolm Greene]

I have a collection of command line scripts that share a collection of common 
modules. This code collection is for internal use and will run under a single 
version of Python 3.6+ and a single OS. My understanding of best practice is to 
organize this collection of Python files into a folder structure like this:

# common files
.gitignore
readme.md
requirements.txt
setup.py  <--- what is the advantage of this file for internally distributed 
code bases?

# app specific package folders
app-1
__init__.py (optional; if needed)
__main__.py 
app-1-module-1.py
app-1-module-2.py
app-1-module-N.py

app-2
__init__.py (optional; if needed)
__main__.py 
app-2-module-1.py
app-2-module-2.py
app-2-module-N.py

# modules shared across multiple apps
common
common-module-1.py
common-module-2.py
common-module-N.py

# tests - place at package level with sub-packages for each package -OR- 
underneath each app package?
tests
app-1
 test_app-1-module-1.py
 test_app-1-module-2.py
 test_app-1-module-N.py
app-2
 test_app-2-module-1.py
 test_app-2-module-2.py
 test_app-2-module-N.py

# virtual env folder placed at same level as packages ???
venv


And execute each app via the following ...

python -m app-1 

Questions

1. Does the above structure sound reasonable?
2. Where to place virtual env files and what to call this folder? venv, .env, 
etc?
3. Where to put tests (pytest)? In a tests folder or under each package?
4. Use a src folder or not? If so, where to put above files relative to the src 
folder?

Malcolm

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

[issue37156] Fix libssl DLL tag in Tools/msi project

[Steve Dower]

Change by Steve Dower :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37156] Fix libssl DLL tag in Tools/msi project

[miss-islington]

miss-islington  added the comment:


New changeset 1c4084f4c13d7ec516abc0439288cbeb2c96489a by Miss Islington (bot) 
in branch '3.8':
bpo-37156: Fix libssl DLL tag in MSI sources (GH-13866)
https://github.com/python/cpython/commit/1c4084f4c13d7ec516abc0439288cbeb2c96489a


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37156] Fix libssl DLL tag in Tools/msi project

[miss-islington]

Change by miss-islington :


--
pull_requests: +13744
pull_request: https://github.com/python/cpython/pull/13868

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37156] Fix libssl DLL tag in Tools/msi project

[Steve Dower]

Steve Dower  added the comment:


New changeset e0c0c7e8c9f8153a54b92e43aa3d09e69a9fd0c0 by Steve Dower in branch 
'master':
bpo-37156: Fix libssl DLL tag in MSI sources (GH-13866)
https://github.com/python/cpython/commit/e0c0c7e8c9f8153a54b92e43aa3d09e69a9fd0c0


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37156] Fix libssl DLL tag in Tools/msi project

[Steve Dower]

Change by Steve Dower :


--
keywords: +patch
pull_requests: +13742
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/13866

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37156] Fix libssl DLL tag in Tools/msi project

[Steve Dower]

New submission from Steve Dower :

Mostly a note to self to fix the tag. Right now the x64 build gets an extra 
suffix, which is incorrect and causes installer builds to fail.

--
assignee: steve.dower
components: Windows
messages: 344638
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix libssl DLL tag in Tools/msi project
type: compile error
versions: Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue37156>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[Project Announcement] tglogger: Sending Live Logging Records to A Python Chat

[Eray Erdin]

I hereby announce my new project called tglogger to Python community. Check
it out here <https://github.com/erayerdin/tglogger>.

*What It Does*

tglogger contains custom handler and formatter implementations in order to
send logging records directly to a chat, which means you get logging feed
from your application almost instantly.

*Features*

 - The message has hashtags so that you can search chat history easily.
 - Can be integrated with Django. Even date time stamp in the message is
integrated to Django's settings.
 - Message contains detailed info about log record, such as hashtagged
level, which file and line the log was captured, under which method or
function the log occured, information about process and thread.

Contributions, reviews and usages are very welcome.

Have a good day.
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

[Project Announcement] tglogger: Sending Live Logging Records to A Python Chat

[Eray Erdin]

I hereby announce my new project called tglogger to Python community. Check
it out here <https://github.com/erayerdin/tglogger>.

*What It Does*

tglogger contains custom handler and formatter implementations in order to
send logging records directly to a chat, which means you get logging feed
from your application almost instantly.

*Features*

 - The message has hashtags so that you can search chat history easily.
 - Can be integrated with Django. Even date time stamp in the message is
integrated to Django's settings.
 - Message contains detailed info about log record, such as hashtagged
level, which file and line the log was captured, under which method or
function the log occured, information about process and thread.

Contributions, reviews and usages are very welcome.

Have a good day.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Mailing List Digest Project

[Jason Friedman]

>
>  Pretty cool.  FYI, the index page (now containing 4 articles) with Google
>> Chrome 72.0.3626.x prompts me to translate to French.  The articles
>> themselves do not.
>>
>
> I'm now getting the translation offer on other web pages with Chrome, not
just this one.
Thus, please ignore my prior posting.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Mailing List Digest Project

[Abdur-Rahmaan Janhangeer]

continuing a better effort here:
https://github.com/PythonCHB/PythonListsSummaries
moving to an impersonal repo later!


Garanti
sans virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Mailing List Digest Project

[Abdur-Rahmaan Janhangeer]

hum maybe beacuse i speak french some settings got configured but i don't
see how. btw we are moving to a better repo with sphinx


Garanti
sans virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, Mar 28, 2019 at 5:48 AM Jason Friedman  wrote:

> On Mon, Mar 25, 2019 at 11:03 PM Abdur-Rahmaan Janhangeer <
> arj.pyt...@gmail.com> wrote:
>
> > As proposed on python-ideas, i setup a repo to turn mail threads into
> > articles.
> >
> > i included a script to build .md to .html (with syntax highlighting) here
> > is the index
> >
> > https://abdur-rahmaanj.github.io/py-mailing-list-summary/
> >
> >  Pretty cool.  FYI, the index page (now containing 4 articles) with
> Google
> Chrome 72.0.3626.x prompts me to translate to French.  The articles
> themselves do not.
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
Abdur-Rahmaan Janhangeer
http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Mailing List Digest Project

[Jason Friedman]

On Mon, Mar 25, 2019 at 11:03 PM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

> As proposed on python-ideas, i setup a repo to turn mail threads into
> articles.
>
> i included a script to build .md to .html (with syntax highlighting) here
> is the index
>
> https://abdur-rahmaanj.github.io/py-mailing-list-summary/
>
>  Pretty cool.  FYI, the index page (now containing 4 articles) with Google
Chrome 72.0.3626.x prompts me to translate to French.  The articles
themselves do not.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Mailing List Digest Project

[Abdur-Rahmaan Janhangeer]

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

Re: The Mailing List Digest Project

[Christopher Barker]

 On Tue, Mar 26, 2019 at 8:32 AM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

> Great! will see sphinx but if i find the html hard to customise, i'll drop
> it.
>

Sphinx has theming support, plus you can do custom CSS if you want. But
Highly discourage you from worrying about formatting — decent structure is
good enough, and content is what matters.

Search feature and tags coming.
>

Sphinx has search built in.

also, currently i'm formatting the mails rather than an article, i don't
> know if a real summary of the topic preferable ...
>

These mailing lists are really big, and the threads are long and scattered,
and they are archived and searchable already.

So I think the real value would be article-style summaries (with links to
the threads).

For Python-Ideas, I’m thinking kind of a mini rejected PEP ...

-CHB

>





> Abdur-Rahmaan Janhangeer
> Mauritius
>
-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Mailing List Digest Project

[Christopher Barker]

On Mon, Mar 25, 2019 at 10:01 PM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

> As proposed on python-ideas, i setup a repo to turn mail threads into
> articles.
>

Thanks for doing this — I find myself frequently telling people about past
relevant threads on this list - it will be great to have a single place to
point people. It can be hard to find stuff in the archives if you’re not
sure what to search for.

here is the repo
>
> https://github.com/Abdur-rahmaanJ/py-mailing-list-summary
>
> i included a script to build .md to .html
>

Maybe Sphinx and  RST instead? For consistency with other Python docs?

But markup is far less important than content.

-CHB

(with syntax highlighting) here is the index
>
> https://abdur-rahmaanj.github.io/py-mailing-list-summary/
>
> included 3 articles as a start
>
> if you want to contribute an article, just follow existing .md format and
> put it in the .md folder
>
> planning to go across ideas, list and dev
>
> i can tell you, it's a really enjoyable experience.
>
> psst. we can enhance some html later
>
> --
> Abdur-Rahmaan Janhangeer
> Mauritius
>
-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Mailing List Digest Project

[Abdur-Rahmaan Janhangeer]

Great! will see sphinx but if i find the html hard to customise, i'll drop
it.

Search feature and tags coming.

also, currently i'm formatting the mails rather than an article, i don't
know if a real summary of the topic preferable ...

Abdur-Rahmaan Janhangeer
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

The Mailing List Digest Project

[Abdur-Rahmaan Janhangeer]

As proposed on python-ideas, i setup a repo to turn mail threads into
articles.

here is the repo

https://github.com/Abdur-rahmaanJ/py-mailing-list-summary

i included a script to build .md to .html (with syntax highlighting) here
is the index

https://abdur-rahmaanj.github.io/py-mailing-list-summary/

included 3 articles as a start

if you want to contribute an article, just follow existing .md format and
put it in the .md folder

planning to go across ideas, list and dev

i can tell you, it's a really enjoyable experience.

psst. we can enhance some html later

-- 
Abdur-Rahmaan Janhangeer
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue35830] building multiple (binary) packages from a single project

[Stefan Seefeld]

Change by Stefan Seefeld :


--
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35830] building multiple (binary) packages from a single project

[Éric Araujo]

Éric Araujo  added the comment:

The way to achieve this is to make sure your two components live in two 
separate directories, each with its setup.py.

This is the simple way that works with distutils/setuptools and pip 
install-from-vcs (you can install from a subdir of a repo).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35830] building multiple (binary) packages from a single project

[Stefan Seefeld]

Stefan Seefeld  added the comment:

Yes. Depending on the answer to my question(s), the request either becomes: 
"please add support for this use-case", or "this use-case isn't documented 
properly", i.e. a feature request or a bug report. You choose. :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35830] building multiple (binary) packages from a single project

[Steven D'Aprano]

Steven D'Aprano  added the comment:

This is a bug tracker for reporting bugs and enhancement requests, not a help 
desk.

Do you have a *specific* feature request or a bug to report? If not, you should 
ask this on a community forum such as Stackoverflow, Reddit's r/learnpython, 
the Python-list mailing list or the Python IRC channel.

--
nosy: +steven.daprano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35830] building multiple (binary) packages from a single project

[Stefan Seefeld]

New submission from Stefan Seefeld :

I'm working on a project that I'd like to split into multiple separately 
installable components. The main component is a command-line tool without any 
external dependencies. Another component is a GUI frontend that adds some 
third-party dependencies.
Therefore, I'd like to distribute the code in a single source package, but 
separate binary packages (so users can install only what they actually need).

I couldn't find any obvious way to support such a scenario with either 
`distutils` nor `setuptools`. Is there an easy solution to this ? (I'm 
currently thinking of adding two `setup()` calls to my `setup.py` script. That 
would then call all commands twice, so I'd need to override the `sdist` command 
to only build a single (joint) source package.
Is there a better way to achieve what I want ?

--
assignee: docs@python
components: Distutils, Documentation
messages: 334381
nosy: docs@python, dstufft, eric.araujo, stefan
priority: normal
severity: normal
status: open
title: building multiple (binary) packages from a single project
type: behavior

___
Python tracker 
<https://bugs.python.org/issue35830>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Slack NLP : open source project

[bhagvanarch]

If you would like to join the slack NLP project, please share your github id to 
email address is bhagv...@quanticacomputacao.com or bhagv...@gmail.com.


Slack NLP github repository

https://github.com/bhagvank/slacknlp



Slack channel

http://goo.gl/BMGHjr



Telegram group

https://t.me/joinchat/KisuQBRcgs9F7x6lQESpmg



check out my latest presentation on open source project-SlackNLP at Pycon 2018

https://goo.gl/hpWu12
-- 
https://mail.python.org/mailman/listinfo/python-list

Monte Carlo Quant: Opensource project

[bhagvanarch]

Quantica computacao has started an open source initiative in python. We invite 
students and professionals to be part of it . My email address is 
bhagv...@quanticacomputacao.com or bhagvana...@gmail.com

Repository link is : https://github.com/bhagvank/Montecarlo_Quant
If you want to participate and get invitation, please share the github ids.



A slack channel for monte carlo open source:

https://goo.gl/iM29fH

Telegram Group for Monte Carlo Open source:

https://t.me/joinchat/KisuQBYtJbinYm5tBytOTw
-- 
https://mail.python.org/mailman/listinfo/python-list