##// END OF EJS Templates
manifest: delay import of `typing.ByteString` for py 3.14 support (issue6940)...
manifest: delay import of `typing.ByteString` for py 3.14 support (issue6940) Since Python 2.7 and 3.5, `typing.ByteString` was defined as an alias for `bytes | bytearray | memoryview`, and `bytes` was also accepted as a shorthand for this, so we have `bytes` sprinkled all over the codebase. But then PEP-688 reversed all of that by deprecating `typing.ByteString` and its successor `collections.abc.ByteString` in Python 3.12 (as well as the `bytes` shorthand)[1], and removing it completely in Python 3.14. That leaves us with a couple of problems, namely defining something useful that spans py3.8-py3.13 and keeps pytype happy, and finding all of the instances where `bytes` doesn't really mean `bytes`. The current successor to all of this is `collections.abc.Buffer` in Python 3.12 (or `typing_extensions.Buffer` in previous versions). However, the current CI does type checking using Python 3.11 (so the former is not avaiable), and pytype has issues with importing `typing_extensions.Buffer`[2]. The good news is we don't need to deal with this mess immediately, since the type annotation evaluation is delayed to the type checking phase, and we're making no effort at supporting it in all supported versions of Python. So by delaying the import of this particular symbol, we can still use it for type checking purposes, but can start assessing Python 3.14 problems without doing a lot of extra work. Putting this on stable will allow people interested in 3.14 to work on it 4-5 extra months earlier (and apparently there's some interest). [1] https://peps.python.org/pep-0688/#no-special-meaning-for-bytes [2] https://github.com/google/pytype/issues/1772

File last commit:

r32571:92bcaef3 default
r53224:0851d94b stable
Show More
editmergeps.ps1
78 lines | 1.6 KiB | text/x-powershell | PowerShellLexer
# A simple script for opening merge conflicts in editor
# A loose translation of contrib/editmerge to powershell
# Please make sure that both editmergeps.bat and editmerge.ps1 are available
# via %PATH% and use the following Mercurial settings to enable it
#
# [ui]
# editmergeps
# editmergeps.args=$output
# editmergeps.check=changed
# editmergeps.premerge=keep
$file=$args[0]
function Get-Lines
{
Select-String "^<<<<<<" $file | % {"$($_.LineNumber)"}
}
$ed = $Env:HGEDITOR;
if ($ed -eq $nil)
{
$ed = $Env:VISUAL;
}
if ($ed -eq $nil)
{
$ed = $Env:EDITOR;
}
if ($ed -eq $nil)
{
$ed = $(hg showconfig ui.editor);
}
if ($ed -eq $nil)
{
Write-Error "merge failed - unable to find editor"
exit 1
}
if (($ed -eq "vim") -or ($ed -eq "emacs") -or `
($ed -eq "nano") -or ($ed -eq "notepad++"))
{
$lines = Get-Lines
$firstline = if ($lines.Length -gt 0) { $lines[0] } else { $nil }
$previousline = $nil;
# open the editor to the first conflict until there are no more
# or the user stops editing the file
while (($firstline -ne $nil) -and ($firstline -ne $previousline))
{
if ($ed -eq "notepad++")
{
$linearg = "-n$firstline"
}
else
{
$linearg = "+$firstline"
}
Start-Process -Wait -NoNewWindow $ed $linearg,$file
$previousline = $firstline
$lines = Get-Lines
$firstline = if ($lines.Length -gt 0) { $lines[0] } else { $nil }
}
}
else
{
& "$ed" $file
}
$conflicts=Get-Lines
if ($conflicts.Length -ne 0)
{
Write-Output "merge failed - resolve the conflicts (line $conflicts) then use 'hg resolve --mark'"
exit 1
}
exit 0