You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hast du noch ein paar nette Ideen zum Umstieg auf Python 3? Mit Boost 1.68 sollte der möglich sein.
Ich habe scintilla 4.0.1 mit python3 getestet und bis dato ist mir nur aufgefallen das Python-Text nach oder von bytes konvertiert
werden muß.
Heisst, mit Python Version2 war ein String standardmäßig ein Byte-Object, mit Python3 ist dies nun ein Unicode-Object, wenn also ein
Script nun etwas wie editor.addText('some text') macht, wird dies nicht funktionieren da es eigentlich editor.addText(b'some text')heißen
müsste. Das ist aber unschön aus Sicht des Users so dass ein automatisches prüfen und konvertieren nötig wäre.
Gleiches gilt für die PS-Console.
Oder sonst noch Gedanken, was geändert/verbessert werden könnte?
Man könnte ein Feature eibauen, welches dynamische generierte dialog erlaubt.
Siehe hierzu https://blogs.msdn.microsoft.com/oldnewthing/20050429-00/?p=35743
Wenn man das auf static, radio/checkbox und normale button sowie ein text control beschränkt sollte es auch mit
überschaubaren Aufwand realisierbar sein.
Die Idee war in etwa sowas:
editor.customDialog('Custom Dialog Title',
(x,y,w,h),
[('static', 'Convert document', x,y,w,h),
('radio', 'ALL TO UPPERCASE', x,y, w,h),
('radio', 'all to lowercase', x,y, w,h),
('button', 'OK - let's do it', x,y, w,h),
('button', 'Ignore and close', x,y, w,h),])
Das skript übergibt also den Titel, x,y Koordinaten sowie die Breite und Höhe des Dialogssowie eine Liste
von dynamisch generierten Controls. Deren x,y sollten relative zum Dialog sein. Also ein x,y = 0 von static
wäre der erste linke obere Punkt innerhalb des Dialogs und nicht auf dem Monitor.
Bezüglich Beispielskripten, die werde ich Dir noch zukommen lassen werde sie nur ein bisschen überarbeiten,
heißt, vorallem, dokumentieren.
why need manual unpack?
download msi and right click - install.
it will automatically put files in the correct location, wherever npp
needs them? or is there some catch?
Thanks.
--
Rawat
I know I've generally been told that "ANSI/codepages" are the reason that PythonScript 3 has never moved out of Alpha. But there has been nothing on this issue in 4 years, other than a comment in 2023 that this issue was the tracker for PS3.
The original list of test failures in ANSI were fixed years ago. So what remains to be solved? What is still holding up the transition from PS3 being alpha to releasing it into Plugins Admin? Is there an actionable and testable list of things that still remain to be fixed/implemented, so that if someone wanted to contribute to that part of the effort, they would know what is needed?
(It can be frustrating in the Forum to have to support both PS2 and PS3 for scripts that I publish, because while I already made the transition to PS3 for my own use, the average Forum member will only install whatever's available in PluginsAdmin, so any public scripts have to work for PS2 as well, or average Forum members aren't likely to be able to use them. Every time I have to fix something, like here, because of differences in behavior or features between Python2.7+libraries and Python3.12+libraries, I am reminded yet again of how much I really wish PS3 were in Plugins Admin rather than just alpha.)
and is not easy to fix, I think.
PS must treat the cases where a buffer is ANSI, DBCS or UNICODE differently.
In the old PS2 everything was a byte buffer and python2 created, or rather tried to create, a string from it.
Now Python3 assumes that it is a utf8 encoded byte stream, which means that another encoded buffer would have to be converted to utf8 or converted from utf8 to its original encoding.
This is feasible in itself, but what happens if you use actions based on different encodings?
For example, get a substring of X and mark it. Different length!
My attempt to act as a bytestream again has unfortunately not yet worked.
//TODO how to get str.attr("encode")(codePageName) working again here
Most likely to overcome that problem the code needs a switch to internally handle the text as byte buffer again and not as python 3 does as utf8 stream.
Could "PythonScript" and (a new) "PythonScript3" both appear in Plugins Admin? The answer is "they could" but the real question is, would that be reasonable?
Can't it just be made known to only use PS3 on UTF-8 files? Those publishing PS3 scripts could assert editor.getCodePage() == 65001 early on in the script...
Using PythonScript in parallel to PythonScript3 requires renaming of the install folder and the plugin dll on master.
I think it is not worth the effort to support both versions and would prefer to just switch to PythonScript3 and see how big is the user complain on it.
What I have in mind is replacing PythonScript(2) in PluginAdmin with PythonScript(3), so it appears as update and the old PS(2) installation is replaced and there should be no issue with a parallel installation of both variants.
Activity
chcg commentedon May 27, 2018
See sergey-shandar/getboost#43, currently no nuget packet seems to be available for boost python which is correctly build against python 3.
Initial test branch created at https://github.com/chcg/PythonScript/tree/python36_test.
See also http://python3porting.com/cextensions.html
initial try of build adaptations for python 3 support, see #36 on blo…
initial try of build adaptations for python 3 support, see #36 on blo…
initial try of build adaptations for python 3 support, see #36 on blo…
jacktose commentedon Aug 9, 2018
boostorg/python#129 is closed and apparently fixed as of April. That should fix sergey-shandar/getboost#43.
Edit: sergey-shandar/getboost#43 is closed now.
initial try of build adaptations for python 3 support, see #36 on blo…
chcg commentedon Oct 3, 2018
Ideas on this task from Claudia:
[-]Move to Python 3.6[/-][+]Move to Python 3.7[/+]initial try of build adaptations for python 3 support, see #36 on blo…
initial try of build adaptations for python 3 support, see #36 on blo…
update to boost 1.72.0 with python 3.8
update to boost 1.72.0 with python 3.8
[-]Move to Python 3.7[/-][+]Move to Python 3.8[/+]23 remaining items
Ekopalypse commentedon Jul 7, 2020
@pete312
download a zip from https://github.com/bruderstein/PythonScript/releases/tag/v3.0.1.
Depending on your notepad++ configuration you either have to unpack into %APPDATA%\notepad++ or
into the installation directory of notepad++.
vsrawat commentedon Jul 7, 2020
Ekopalypse commentedon Jul 7, 2020
@vsrawat
I don't know as I don't use the installed version.
added fix for some ansi issues as described in diíscussion #36 (comment)
pryrt commentedon Dec 4, 2024
@chcg,
I know I've generally been told that "ANSI/codepages" are the reason that PythonScript 3 has never moved out of Alpha. But there has been nothing on this issue in 4 years, other than a comment in 2023 that this issue was the tracker for PS3.
The original list of test failures in ANSI were fixed years ago. So what remains to be solved? What is still holding up the transition from PS3 being alpha to releasing it into Plugins Admin? Is there an actionable and testable list of things that still remain to be fixed/implemented, so that if someone wanted to contribute to that part of the effort, they would know what is needed?
(It can be frustrating in the Forum to have to support both PS2 and PS3 for scripts that I publish, because while I already made the transition to PS3 for my own use, the average Forum member will only install whatever's available in PluginsAdmin, so any public scripts have to work for PS2 as well, or average Forum members aren't likely to be able to use them. Every time I have to fix something, like here, because of differences in behavior or features between Python2.7+libraries and Python3.12+libraries, I am reminded yet again of how much I really wish PS3 were in Plugins Admin rather than just alpha.)
Ekopalypse commentedon Dec 4, 2024
The issue still exists
and is not easy to fix, I think.
PS must treat the cases where a buffer is ANSI, DBCS or UNICODE differently.
In the old PS2 everything was a byte buffer and python2 created, or rather tried to create, a string from it.
Now Python3 assumes that it is a utf8 encoded byte stream, which means that another encoded buffer would have to be converted to utf8 or converted from utf8 to its original encoding.
This is feasible in itself, but what happens if you use actions based on different encodings?
For example, get a substring of X and mark it. Different length!
My attempt to act as a bytestream again has unfortunately not yet worked.
And I can understand your frustration.
chcg commentedon Dec 5, 2024
Failing tests are internal ones from
https://github.com/bruderstein/PythonScript/blob/master/PythonScript/python_tests/tests/
The main issue is within
PythonScript/PythonScript/src/ScintillaWrapper.cpp
Line 691 in a48411a
Most likely to overcome that problem the code needs a switch to internally handle the text as byte buffer again and not as python 3 does as utf8 stream.
alankilborn commentedon Dec 6, 2024
Questions:
assert editor.getCodePage() == 65001early on in the script...chcg commentedon Dec 30, 2024
I think it is not worth the effort to support both versions and would prefer to just switch to PythonScript3 and see how big is the user complain on it.
Ekopalypse commentedon Dec 30, 2024
As far as I understand, even with the latest Python version it is not possible to host multiple runtimes in one process
alankilborn commentedon Dec 30, 2024
Was I or anyone else suggesting this?
Ekopalypse commentedon Dec 30, 2024
If there will be two versions in the PluginAdmin, there will be people who install both and then ...
alankilborn commentedon Dec 30, 2024
Well, appropriate warnings should be added to description in PluginAdmin...
And really, maybe a deprecation warning for PS2 (I believe it is behind in new features and functions anyway).
chcg commentedon Dec 31, 2024
What I have in mind is replacing PythonScript(2) in PluginAdmin with PythonScript(3), so it appears as update and the old PS(2) installation is replaced and there should be no issue with a parallel installation of both variants.
added fix for some ansi issues as described in diíscussion bruderstei…