Re: from __future__ import annotations bug?
> but does this mean that even with PEP 649 that forward references will > still be needed? Yes. Both of PEP 563 and PEP 649 solves not all forward reference issues. -- Inada Naoki -- https://mail.python.org/mailman/listinfo/python-list
Re: Bug in io.TextIOWrapper?
I checked TextIOWrapper source code and confirmed that it doesn't call encoder.write(text, finish=True) on close. Since TextIOWrapper allows random access, it is difficult to call it automatically. So please think it as just limitation rather than bug. Please use codec and binary file manually for now. -- https://mail.python.org/mailman/listinfo/python-list
Re: Bug in io.TextIOWrapper?
You can use file instead of BytesIO
2023年6月20日(火) 3:05 Peter J. Holzer via Python-list :
> On 2023-06-20 02:15:00 +0900, Inada Naoki via Python-list wrote:
> > stream.flush() doesn't mean final output.
> > Try stream.close()
>
> After close() the value isn't available any more:
>
> Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import io
> >>> buffer = io.BytesIO()
> >>> stream = io.TextIOWrapper(buffer, encoding='idna')
> >>> stream.write('abc.example.com')
> 15
> >>> stream.close()
> >>> buffer.getvalue()
> Traceback (most recent call last):
> File "", line 1, in
> ValueError: I/O operation on closed file.
>
> hp
>
> --
>_ | Peter J. Holzer| Story must make more sense than reality.
> |_|_) ||
> | | | h...@hjp.at |-- Charles Stross, "Creative writing
> __/ | http://www.hjp.at/ | challenge!"
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Bug in io.TextIOWrapper?
stream.flush() doesn't mean final output.
Try stream.close()
2023年6月20日(火) 1:40 Jon Ribbens via Python-list :
> io.TextIOWrapper() wraps a binary stream so you can write text to it.
> It takes an 'encoding' parameter, which it uses to look up the codec
> in the codecs registry, and then it uses the IncrementalEncoder and
> IncrementalDecoder classes for the appropriate codec.
>
> The IncrementalEncoder.encode() function is given the object to encode
> of course, and also an optional second parameter which indicates if
> this is the final output.
>
> The bug is that TextIOWrapper() never sets the second parameter to
> indicate that the output is complete - not even if you call close().
>
> Example:
>
> >>> import io
> >>> buffer = io.BytesIO()
> >>> stream = io.TextIOWrapper(buffer, encoding='idna')
> >>> stream.write('abc.example.com')
> 15
> >>> stream.flush()
> >>> buffer.getvalue()
> b'abc.example.'
>
> Obviously using the 'idna' wrapper as an encoding on a stream is a bit
> unlikely, but nevertheless any other codec which cares about the 'final'
> parameter will also have this problem.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Compiling python on windows with vs
Then, git doesn't enable Windows NTFS case sensitivity. You enabled NTFS case sensitivity on "C:\Users\user\K". And Windows enabled case sensitivity for all new directories under the directory. Since it is not default and minor setting, it is not a bug that current Python doesn't support building on case sensitive directory. But I think it is a nice improvement if next Python supports it. Regards, -- Inada Naoki -- https://mail.python.org/mailman/listinfo/python-list
Re: Compiling python on windows with vs
> Since Git enables Windows NTFS case sensitivity while checking out sources I didn't know that. Would you give us a link to this feature? As far as I know, `git config core.ignorecase` doesn't mean NTFS case sensitive. On Wed, Jun 14, 2023 at 1:57 AM Thomas Schweikle via Python-list < python-list@python.org> wrote: > Hi! > > Trying to compile python on windows leads to following error: > >_testimportmultiple.vcxproj -> > > C:\Users\sct-muc\Documents\Projekte\cpython\PCbuild\amd64\_testimportmultiple.pyd >_testmultiphase.c > Bibliothek > "C:\Users\sct-muc\Documents\Projekte\cpython\PCbuild\amd64\_testmultiphase.lib" > > und Objekt "C:\Users\sct-muc\Docume >nts\Projekte\cpython\PCbuild\amd64\_testmultiphase.exp" werden erstellt. >Code wird generiert. >Codegenerierung ist abgeschlossen. >_testmultiphase.vcxproj -> > > C:\Users\sct-muc\Documents\Projekte\cpython\PCbuild\amd64\_testmultiphase.pyd >_testconsole.c > C:\Users\sct-muc\Documents\Projekte\cpython\PC\_testconsole.c(13,10): > fatal error C1083: Datei (Include) kann nicht geöffnet werde > n: "..\modules\_io\_iomodule.h": No such file or directory > [C:\Users\sct-muc\Documents\Projekte\cpython\PCbuild\_testconsole.vcxpro > j] > > Fehler beim Buildvorgang. > > if I rename "Modules" to "modules" it will find > "..\modules\_io\_iomodule.h" but wont find "..\Modules\..." > > Since Git enables Windows NTFS case sensitivity while checking out > sources ... is it a bug or a "feature"? And: is there a simple > workaround available besides disabling case sensitivity (which will > break others)? > -- > Thomas > > -- > https://mail.python.org/mailman/listinfo/python-list > -- Inada Naoki -- https://mail.python.org/mailman/listinfo/python-list
