[Python-ideas] Re: writelines2?

[Steven D'Aprano]

On Tue, Jul 13, 2021 at 09:54:27AM -0400, Eric V. Smith wrote:

> I'm skeptical that people who won't read the documentation for 
> writelines will either read the documentation for writelines2, or 
> intuitively understand how it's different from writelines, or would know 
> there's a kwarg parameter to writelines.

Of course they won't. They'll just go on Twitter to bitch about what a 
horrible language Python is, because it's not "intuitive", until 
somebody points them to a few dozen StackOverflow posts that point out 
how to use it correctly.

*wink*

In this case I agree that the current API is a little surprising, but it 
seems to me that adding a kw parameter or a new method is an easy way to 
solve that. No, people who don't read the docs won't intuit their 
existence, but so long as *one* person reads the docs, the knowledge 
will slowly spread via mailing lists, StackOverflow, code reviews, etc.


> It seems your proposal would only matter if the argument were a list?

writelines doesn't require a list, it takes any iterable that yields 
strings.

(The docs are misleading: it still says "list".)

The current behaviour would have to remain the same, so the items 
would be written directly, whether or not they end with a newline. With 
the parameter, writelines would write a newline after each item in the 
iterable.



-- 
Steve
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/AOYVP5XFOJRVWRSMATKQFB5YFOQC7ZTF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[Chris Angelico]

On Wed, Jul 14, 2021 at 11:22 AM Steven D'Aprano  wrote:
>
> On Tue, Jul 13, 2021 at 10:27:55PM +0300, Serhiy Storchaka wrote:
>
> > The writelines method is the part of interface. Adding new parameter or
> > new method to interface is a major breaking change. It will make invalid
> > all existing user code which implements this interface.
>
> I think that statement is a bit strong. How will it break existing code?
> The code will still work exactly the same as before.
>
> We added the BufferedIOBase.readinto1 method in Python 3.5, before that
> we added 'x' mode and `opener=None` parameter to FileIO in 3.3.
>
> https://docs.python.org/3/library/io.html#io.BufferedIOBase.readinto1
>
> https://docs.python.org/3/library/io.html#io.FileIO
>
> In 3.7 we allowed the BytesIO.read1 size parameter to be optional:
>
> https://docs.python.org/3/library/io.html#io.BytesIO.read1
>
> There are other changes to the IO interfaces through to Python 3.7. If
> that didn't break code, I don't see why this change would.
>
> I think that adding a new method or a keyword-only arg to writelines in
> 3.11 would be fine.
>

Breakage has to be justified. The value of readinto1 is more
significant than a change to writelines(), which - I'll be honest - is
an API that I've never bothered with. It's usually easiest to just
write().

But OTOH, the breakage here wouldn't be very significant. In theory,
it means adding the functionality to every file-like object. In
practice, nobody knows what "file-like object" really means, other
than "has that one method of file objects that I'm going to be
calling", so if other objects don't have this method or arg, it won't
hurt.

I'm -0 on this.

ChrisA
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/EUUNVMEH2Y4OCM4GDKEOYCSWE63JUCBP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[Steven D'Aprano]

On Tue, Jul 13, 2021 at 08:59:21AM -0700, Guido van Rossum wrote:
> Let's leave poor writelines alone. It's an old API, if you want something
> different, there are a zillion other ways (e.g. print(*x, sep="\n") ).
> 
> I wonder how much research the OP did before they claimed "writelines is a
> very big misnomer to many python developers".

I don't know about research, but the API certainly fools me. I don't 
consider the delimiter at the end of the line (the newline) to be part 
of the line, so whenever I used readlines and writelines I am invariably 
surprised by the fact that writelines requires the newlines to already 
be there.

I'm also surprised that there's a readline but no writeline :-)


-- 
Steve
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/NNY75OMPDYHG2RSCUGDJSY7PWGF4JFEN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[Steven D'Aprano]

On Tue, Jul 13, 2021 at 10:27:55PM +0300, Serhiy Storchaka wrote:

> The writelines method is the part of interface. Adding new parameter or
> new method to interface is a major breaking change. It will make invalid
> all existing user code which implements this interface.

I think that statement is a bit strong. How will it break existing code? 
The code will still work exactly the same as before.

We added the BufferedIOBase.readinto1 method in Python 3.5, before that 
we added 'x' mode and `opener=None` parameter to FileIO in 3.3.

https://docs.python.org/3/library/io.html#io.BufferedIOBase.readinto1

https://docs.python.org/3/library/io.html#io.FileIO

In 3.7 we allowed the BytesIO.read1 size parameter to be optional:

https://docs.python.org/3/library/io.html#io.BytesIO.read1

There are other changes to the IO interfaces through to Python 3.7. If 
that didn't break code, I don't see why this change would.

I think that adding a new method or a keyword-only arg to writelines in 
3.11 would be fine.



-- 
Steve
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/ZCBLZG6EIPRFGFQ4GDCTAXABGLTPRBAG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[Steven D'Aprano]

On Tue, Jul 13, 2021 at 09:05:54AM -0700, Christopher Barker wrote:

> indeed. so if this idea is to be done (and there's something to be said for
> it), I think a similar option should be added to readlines as well --
> striping the newline.

I don't think that's as useful as you may expect. When processing lines 
of text, we often want to strip *any* trailing whitespace, not just 
newlines. So even if you strip the newline, you probably will still need 
to strip trailing whitespace. So why bother with stripping the newline? 
I think it will be extremely niche to want one but not the other.


> A couple other notes:
> 
> This would highlight the whole "a string is an iterable of strings" problem
> :-( -- should strings be special cased? I think not, that's an issue that
> Python programmers have to learn at one point or another anyway.

Sorry, have I missed something? How is this relevant? We're talking 
about a list of strings.


> As for whether it always puts in a newline, or if you can specify what you
> want to put in , I vote for the newline -- newlines are not the same on all
> platforms (though TextIO does translate), but I think it would get a bit
> confusing if someone explicitly put in "\n| and got "\r\n".

A precedent is str.splitlines:

splitlines(self, /, keepends=False)
Return a list of the lines in the string, breaking at line 
boundaries.

Line breaks are not included in the resulting list unless 
keepends is given and true.

except writelines (and readlines) would presumably reverse the default.

* readlines default to keeping the newlines
* writelines default to not appending newlines


> And the name IS writeLINES -- so why would anyone expect to use it for
> anything else -- we still have str.join() after all.

Repurposing functions to do something different from what the designers 
imagined is very common.


-- 
Steve
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/RMAHTFVD2V7RRW3XKEIPCK2CSTWHOLX2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: builtins for running context managers

[Thomas Grainger]

Like the nodeback interface, it's (err, val)

On Tue, 13 Jul 2021, 21:31 Ethan Furman,  wrote:

> On 7/13/21 12:43 PM, Thomas Grainger wrote:
>
>  > I used the order I did because it's idiomatic to return the value the
> user needs
>  > followed by the value the user wants.
>
> citation?
>
> --
> ~Ethan~
> ___
> Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/SBUNQOCAQTBWIGRUIP5BMMEEYEN7Y4F4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/LJLJZRGOZREPMFDOGTGAW36PKZ23YXMG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: builtins for running context managers

[Ethan Furman]

On 7/13/21 12:43 PM, Thomas Grainger wrote:

> I used the order I did because it's idiomatic to return the value the user 
needs
> followed by the value the user wants.

citation?

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/SBUNQOCAQTBWIGRUIP5BMMEEYEN7Y4F4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: builtins for running context managers

[Thomas Grainger]

also https://www.python.org/dev/peps/pep-0343/ probably needs updating - but 
I'm not sure exactly what the code is
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/PBTL5T2NQGRBNREW6Z74AGB43ZV63P7V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: builtins for running context managers

[Thomas Grainger]

I used the order I did because it's idiomatic to return the value the user
needs followed by the value the user wants.

On Tue, 13 Jul 2021, 20:24 Serhiy Storchaka,  wrote:

> 13.07.21 18:59, Thomas Grainger пише:
> > given that it's hard to implement this correctly I think there should be
> a builtins.enter and builtins.aenter for use like this:
> >
> >
> > ```
> > @dataclasses.dataclass
> > class WrapCmgr:
> > _cmgr: ContextManager[T]
> >
> > def __enter__(self) -> Wrapped[T]:
> > exit, value = enter(self._cmgr)
> > self.__exit = exit
> > return wrap(value)
> >
> > def __exit__(self, \, t: Type[BaseException] | None, v:
> BaseException, tb: types.TracebackType) -> bool:
> > return self.__exit(t, v, tb)
> > ```
>
> I considered similar idea when worked on issue12022 and issue44471. The
> only difference is that I added the helper in the operator module, and
> my operator.enter() returned the value and the callback in the different
> order.
>
> def enter(cm):
> # We look up the special methods on the type to match the with
> # statement.
> cls = type(cm)
> try:
> enter = cls.__enter__
> exit = cls.__exit__
> except AttributeError:
> raise TypeError(f"'{cls.__module__}.{cls.__qualname__}' object
> does "
> f"not support the context manager protocol")
> from None
> callback = _MethodType(exit, cm)
> return enter(cm), callback
>
> I still investigate possible consequences and alternatives.
>
> Since we need to save the callback as an object attribute in any case,
> one of alternatives is using ExitStack instead of introducing new API.
> It is more heavyweight, but if implemented in C the difference can be
> reduced.
>
> Other alternative is to expose _PyObject_LookupSpecial() at Python
> level. It would be useful not only for __enter__ and __exit__, but for
> other special methods.
>
> ___
> Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/FAQAGFAFVVAKPAU3U6AMFTKUMZCLK2GY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/JT3NJWCSDXGQH32FGT5SDP7N7EQEOA2O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[Serhiy Storchaka]

13.07.21 14:15, sandhoners...@gmail.com пише:
> My suggestion is to have either a writelines2 or a newline kwarg which does 
> put new lines automatically at the end of every line written

The writelines method is the part of interface. Adding new parameter or
new method to interface is a major breaking change. It will make invalid
all existing user code which implements this interface.

___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/J3ZDZ4TO2IQBZNL2BWMQNZU2ENIJS46J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: builtins for running context managers

[Serhiy Storchaka]

13.07.21 18:59, Thomas Grainger пише:
> given that it's hard to implement this correctly I think there should be a 
> builtins.enter and builtins.aenter for use like this:
> 
> 
> ```
> @dataclasses.dataclass
> class WrapCmgr:
> _cmgr: ContextManager[T]
> 
> def __enter__(self) -> Wrapped[T]:
> exit, value = enter(self._cmgr)
> self.__exit = exit
> return wrap(value)
> 
> def __exit__(self, \, t: Type[BaseException] | None, v: BaseException, 
> tb: types.TracebackType) -> bool:
> return self.__exit(t, v, tb)
> ```

I considered similar idea when worked on issue12022 and issue44471. The
only difference is that I added the helper in the operator module, and
my operator.enter() returned the value and the callback in the different
order.

def enter(cm):
# We look up the special methods on the type to match the with
# statement.
cls = type(cm)
try:
enter = cls.__enter__
exit = cls.__exit__
except AttributeError:
raise TypeError(f"'{cls.__module__}.{cls.__qualname__}' object
does "
f"not support the context manager protocol")
from None
callback = _MethodType(exit, cm)
return enter(cm), callback

I still investigate possible consequences and alternatives.

Since we need to save the callback as an object attribute in any case,
one of alternatives is using ExitStack instead of introducing new API.
It is more heavyweight, but if implemented in C the difference can be
reduced.

Other alternative is to expose _PyObject_LookupSpecial() at Python
level. It would be useful not only for __enter__ and __exit__, but for
other special methods.

___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/FAQAGFAFVVAKPAU3U6AMFTKUMZCLK2GY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Deprecation APIs and language tooling

[Stephen J. Turnbull]

Sergei Lebedev writes:

 > The proliferation of deprecation APIs itself is not a problem, but it does
 > make it difficult (if not impossible) for language tooling to consume that
 > deprecation information and help users of these libraries write better
 > code.

We don't know that it's not a problem, though.

To get this discussion properly kicked off, the first thing that
should be checked is what is common and what is not in the many
existing APIs, and make proposals about the odd features (whether to
include them in the standard API or not), as well as reconciling
similar features that are implemented differently.  At the other end,
the 'deprecations' module, on PyPI I guess (searching for "deprecation
doc" found at the readthedocs manual, not the package itself), seems
to be a minimal API likely to be a common core.  (However the
restriction that the deprecation date has to be set to set the target
removal date seems odd to me.)

 > Imagine, if there was a standard way to flag something as
 > deprecated.

But there *is* a stdlib way to flag something as deprecated
(DeprecationWarning), but issuing those warnings is a user option, off
by default.  The reasons why that standard API is not used, but every
library auther prefers a module-specific API, need to be addressed.
And somebody cared enough about 'deprecations' to bring it to version
2.06, which suggests they're using it quite a bit.

 > What do you think? Is anyone interested in discussing this further
 > and perhaps sketching an API which could work reasonably well for
 > library authors as well as for tooling?

I'll lurk in the discussion, but this is not something I've felt a
need for in the past.  It's not the place where you'd expect to see
this discussion, but in the mypy issue you mention, Guido's specific
invitation to do exactly this apparently met with complete silence,
which is not a good sign (but not necessarily a bad one, either).

One general comment: I expect that something that works for consumers
of deprecation information wouldt work for library authors, too.  The
problem is the API for filtering out unwanted information (eg,
deprecations in imported libraries you're unable or unwilling to
vendor, removals far enough in the future you're happy to postpone the
work), without too much work on the consumer's side (most consumers
will not be willing to do more than "on" vs "off", and currently they
prefer "off" for DeprecationWarning itself).

Steve

___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/HGTR32Q2YHFOTX4UTQDAEG3DZBSMHNDC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python Documentation in Bengali (translation)

[Julien Palard via Python-ideas]

Hi,

Le 7/11/21 à 6:19 PM, sharifmehed...@outlook.com a écrit :
> I am preparing a team to start translating python documentation to Bengali.
>
> I'd appreciate some reference materials, comments and ideas about this.

Looks like [1] Kushal Das is the current contact for Bengali
translation. There's a repo [2] for it, but it looks like nothing has
been done yet.

A good place to start is to use my Python docs translation cookiecutter
[3], and/or read the Starting a new translation paragraph [4] from the
devguide.

[1]: https://devguide.python.org/documenting/#translating
[2]: https://github.com/python/python-docs-bn-in
[3]: https://github.com/JulienPalard/python-docs-cookiecutter
[4]: https://devguide.python.org/documenting/#starting-a-new-translation
--
[Julien Palard](https://mdk.fr)

___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/D6FFBPC2PYWW7PC4N6FIXGBJWORWIT5H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[David Mertz]

I've written something like this far too many times:

lines = (line.rstrip('\n') for line in open(frame).readlines())

It's not unworkable, but it's definitely common to want the lines without
the newlines. The corresponding .writelines() hits me less, but it's still
a concern.

I slightly shorter and more intuitive spelling would be convenient. On the
model of print(), it seems like a 'sep=' argument would make sense, while
being backwards compatible. Obviously the default would need to be current
behavior.

On Tue, Jul 13, 2021, 10:08 AM Christopher Barker 
wrote:

> On Tue, Jul 13, 2021 at 9:00 AM <2qdxy4rzwzuui...@potatochowder.com>
> wrote:
>
>> As it stands, writelines is consistent with readlines.  Both preserve
>> newlines.
>>
>
> indeed. so if this idea is to be done (and there's something to be said
> for it), I think a similar option should be added to readlines as well --
> striping the newline.
>
> A couple other notes:
>
> This would highlight the whole "a string is an iterable of strings"
> problem :-( -- should strings be special cased? I think not, that's an
> issue that Python programmers have to learn at one point or another anyway.
>
> As for whether it always puts in a newline, or if you can specify what you
> want to put in , I vote for the newline -- newlines are not the same on all
> platforms (though TextIO does translate), but I think it would get a bit
> confusing if someone explicitly put in "\n| and got "\r\n".
>
> And the name IS writeLINES -- so why would anyone expect to use it for
> anything else -- we still have str.join() after all.
>
> -CHB
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/TWZHPL7ZP3MQTIAAQTEAOWZW43P3LIW3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/UC2B7WUOVOH7FCJ3SRNPLYK7FYZ25EMA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[Eric V. Smith]

Ignore me on this, I wasn't focusing on the function at hand.

Eric

On 7/13/2021 10:18 AM, Eric V. Smith wrote:

On 7/13/2021 9:52 AM, Thomas Güttler wrote:



Am Di., 13. Juli 2021 um 15:02 Uhr schrieb >:


Right now, writelines is a very big misnomer to many python
developers, especially beginners who would expect writelines to
put new lines at the end of every element in the list

My suggestion is to have either a writelines2 or a newline kwarg
which does put new lines automatically at the end of every line
written


I like the idea of having a kwarg for writelines 
.


Do you want a boolean like "append_newlines=True" or a string like 
"append_string='\n'"


But it only applies if the argument is iterable, right?

That is, it would have no effect on something like:

fl.writelines(3, append_newlines=True)

Assuming so, the parameter would need to have some more appropriate 
name, like append_newlines_if_iterable.


Personally, I don't think this has any chance of being accepted, but 
that's me. There are numerous ways to achieve this already, and we 
don't need another one.


Eric


___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/OTRRFIP4SVN6BF43ARLO43DNVDBCMZXI/
Code of Conduct: http://python.org/psf/codeofconduct/


--
Eric V. Smith

___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/OKOBVXLASVJLWZMXHEVMJOEEB5M6KYFZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[Guido van Rossum]

Let's leave poor writelines alone. It's an old API, if you want something
different, there are a zillion other ways (e.g. print(*x, sep="\n") ).

I wonder how much research the OP did before they claimed "writelines is a
very big misnomer to many python developers".

On Tue, Jul 13, 2021 at 8:46 AM MRAB  wrote:

> On 2021-07-13 15:11, sandhoners...@gmail.com wrote:
> > Maybe (to be consistent with other functions like print), end= since
> that would allow even custom line endings
> >
> I'm not sure about the name 'end'. The 'print' function has 'end', but
> it's printed only at the end(!); .writelines would write it after every
> line.
> ___
> Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/2SYIBL275IIHMSPAT6J4K3TIA7HXEKV5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


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

___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/RBWD6GIK5JTAM4PDWU6X6O4JWTOXZWUD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[2QdxY4RzWzUUiLuE]

On 2021-07-13 at 14:11:15 -,
sandhoners...@gmail.com wrote:

> Maybe (to be consistent with other functions like print), end= since
> that would allow even custom line endings

As it stands, writelines is consistent with readlines.  Both preserve
newlines.

All else being equal, the following copies a file:

input_file = open(input_pathname, 'r')
output_file = open(output_pathname, 'w')
lines = input_file.readlines()
output_file.writelines(lines)
input_file.close()
output_file.close()

___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/PZVKOJSCDQSCSKGFYU2AX7KAWLZ373LC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] builtins for running context managers

[Thomas Grainger]

currently lots of code manages contexts incorrectly by doing:

```
@dataclasses.dataclass
class WrapCmgr:
_cmgr: ContextManager[T]

def __enter__(self) -> Wrapped[T]:
return wrap(_cmgr.__enter__())

def __exit__(self, \, t: Type[BaseException] | None, v: BaseException, tb: 
types.TracebackType) -> bool:
return _cmgr.__exit__(t, v, tb)
```


since https://bugs.python.org/issue44471 using `with WrapCmgr(cmgr()):` 
incorrectly raises an AttributeError rather than a TypeError

and https://www.python.org/dev/peps/pep-0343/ still includes this bug, raising 
an AttributeError

```
mgr = (EXPR)
exit = type(mgr).__exit__  # Not calling it yet
value = type(mgr).__enter__(mgr)
```

contextlib.ExitStack also had this bug https://bugs.python.org/issue12022

given that it's hard to implement this correctly I think there should be a 
builtins.enter and builtins.aenter for use like this:


```
@dataclasses.dataclass
class WrapCmgr:
_cmgr: ContextManager[T]

def __enter__(self) -> Wrapped[T]:
exit, value = enter(self._cmgr)
self.__exit = exit
return wrap(value)

def __exit__(self, \, t: Type[BaseException] | None, v: BaseException, tb: 
types.TracebackType) -> bool:
return self.__exit(t, v, tb)
```
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/GV5ZCOT3UHLDEMPOCWWDTSDARIB7SYYN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[MRAB]

On 2021-07-13 15:18, Eric V. Smith wrote:

On 7/13/2021 9:52 AM, Thomas Güttler wrote:



Am Di., 13. Juli 2021 um 15:02 Uhr schrieb >:


Right now, writelines is a very big misnomer to many python
developers, especially beginners who would expect writelines to
put new lines at the end of every element in the list

My suggestion is to have either a writelines2 or a newline kwarg
which does put new lines automatically at the end of every line
written


I like the idea of having a kwarg for writelines 
.


Do you want a boolean like "append_newlines=True" or a string like 
"append_string='\n'"


But it only applies if the argument is iterable, right?

That is, it would have no effect on something like:

fl.writelines(3, append_newlines=True)


That raises an exception, and I wouldn't expect that to change.

Assuming so, the parameter would need to have some more appropriate 
name, like append_newlines_if_iterable.


Personally, I don't think this has any chance of being accepted, but 
that's me. There are numerous ways to achieve this already, and we don't 
need another one.



___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/MFCBTDEOQAF33APIVHSRTQ7AYR5HF2YH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[MRAB]

On 2021-07-13 15:11, sandhoners...@gmail.com wrote:

Maybe (to be consistent with other functions like print), end= since that would 
allow even custom line endings

I'm not sure about the name 'end'. The 'print' function has 'end', but 
it's printed only at the end(!); .writelines would write it after every 
line.

___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/2SYIBL275IIHMSPAT6J4K3TIA7HXEKV5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[Paul Moore]

On Tue, 13 Jul 2021 at 15:56, Jonathan Fine  wrote:
>
> The interactive help message for writelines gives no help. I've made an 
> enhancement request to b.p.o.
>
> help(open('/dev/zero').writelines) gives no help
> https://bugs.python.org/issue44623
>
> Please take a look.

Works for me on Python 3.9:

>>> help(open("nul").writelines)
Help on built-in function writelines:

writelines(lines, /) method of _io.TextIOWrapper instance
Write a list of lines to stream.

Line separators are not added, so it is usual for each of the
lines provided to have a line separator at the end.
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/EPRIT27NWJBDX2LGDJO2ZLP7FSN6V6KN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[Jonathan Fine]

The interactive help message for writelines gives no help. I've made an
enhancement request to b.p.o.

help(open('/dev/zero').writelines) gives no help
https://bugs.python.org/issue44623

Please take a look.

-- 
Jonathan
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/6K7TGQHWO6SE3TWRAZ7AK5H6O372W77T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[sandhoners123]

It would produce a\nb\nc\n. Essentially it would put \n after every value 
gotten from a iterator
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/76C36GBCACKJOMPR32MIRULUR5MGKK3N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[Eric V. Smith]

On 7/13/2021 7:15 AM, sandhoners...@gmail.com wrote:

Right now, writelines is a very big misnomer to many python developers, 
especially beginners who would expect writelines to put new lines at the end of 
every element in the list

My suggestion is to have either a writelines2 or a newline kwarg which does put 
new lines automatically at the end of every line written

I'm skeptical that people who won't read the documentation for 
writelines will either read the documentation for writelines2, or 
intuitively understand how it's different from writelines, or would know 
there's a kwarg parameter to writelines.


It seems your proposal would only matter if the argument were a list? Or 
does it include tuples and other iterables? If lists, I assume that:


fl.writelines2(['a', 'b', 'c'])

would produce 3 lines:

a
b
c

But what would:

fl.writelines2('abc')

produce? It's an iterable.

Eric

___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/QGXTUTTBEDZ7ABBTAPNSKWHQM73ZDTIZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[Eric V. Smith]

On 7/13/2021 9:52 AM, Thomas Güttler wrote:



Am Di., 13. Juli 2021 um 15:02 Uhr schrieb >:


Right now, writelines is a very big misnomer to many python
developers, especially beginners who would expect writelines to
put new lines at the end of every element in the list

My suggestion is to have either a writelines2 or a newline kwarg
which does put new lines automatically at the end of every line
written


I like the idea of having a kwarg for writelines 
.


Do you want a boolean like "append_newlines=True" or a string like 
"append_string='\n'"


But it only applies if the argument is iterable, right?

That is, it would have no effect on something like:

fl.writelines(3, append_newlines=True)

Assuming so, the parameter would need to have some more appropriate 
name, like append_newlines_if_iterable.


Personally, I don't think this has any chance of being accepted, but 
that's me. There are numerous ways to achieve this already, and we don't 
need another one.


Eric

___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/OTRRFIP4SVN6BF43ARLO43DNVDBCMZXI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[sandhoners123]

Maybe (to be consistent with other functions like print), end= since that would 
allow even custom line endings
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/X3XIKS5J3XMLQLKINQHS6ZLXCIKBWFF2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[Thomas Güttler]

Am Di., 13. Juli 2021 um 15:02 Uhr schrieb :

> Right now, writelines is a very big misnomer to many python developers,
> especially beginners who would expect writelines to put new lines at the
> end of every element in the list
>
> My suggestion is to have either a writelines2 or a newline kwarg which
> does put new lines automatically at the end of every line written
>
>
I like the idea of having a kwarg for writelines
.

Do you want a boolean like "append_newlines=True" or a string like
"append_string='\n'"

Regards,
  Thomas
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/KXJD6XCKV3AMUQMDRL2RVFLMV76KXRFQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] writelines2?

[sandhoners123]

Right now, writelines is a very big misnomer to many python developers, 
especially beginners who would expect writelines to put new lines at the end of 
every element in the list

My suggestion is to have either a writelines2 or a newline kwarg which does put 
new lines automatically at the end of every line written
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/A5FT7SVZBYAJJTIWQFTFUGNSKMVQNPVF/
Code of Conduct: http://python.org/psf/codeofconduct/