[Python-ideas] Re: infile and outfile parameters for the input function
02.05.22 22:55, sam.z.e...@gmail.com пише:
```
with open('/dev/tty', 'r+') as file:
name = input('Name: ', infile=file, outfile=file)
print(name)
```
How does it differ from just:
```
file.write('Name: ')
name = file.readline()
```
?
___
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/I4FOEOKERM4ZS4TINQFJ2AJK4B3ZLE2H/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: infile and outfile parameters for the input function
On Tue, 3 May 2022 at 17:28, Serhiy Storchaka wrote:
>
> 02.05.22 22:55, sam.z.e...@gmail.com пише:
> > ```
> > with open('/dev/tty', 'r+') as file:
> > name = input('Name: ', infile=file, outfile=file)
> >
> > print(name)
> > ```
>
> How does it differ from just:
> ```
> file.write('Name: ')
> name = file.readline()
> ```
> ?
>
At the very least, I would expect the write to be flushed before the
read happens (which wouldn't necessarily be the default when the
newline is omitted, as in this case); and depending on configuration,
something like GNU Readline might be active when calling input() that
wouldn't be active when simply reading a line from an arbitrary file
descriptor.
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/FXFNYB5TCYHU3IFENIUS43ZQEQNG6M5W/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto assignment of attributes
On Tue, 3 May 2022 at 03:04, Steven D'Aprano wrote:
>
> On Mon, May 02, 2022 at 07:44:14PM +0100, Paul Moore wrote:
>
> > I have classes with 20+ parameters (packaging metadata). You can argue
> > that a dataclass would be better, or some other form of refactoring,
> > and you may actually be right. But it is a legitimate design for that
> > use case.
>
> Indeed. 20+ parameters is only a code smell, it's not *necessarily*
> wrong. Sometimes you just need lots of parameters, even if it is ugly.
>
> For reference, open() only takes 8, so 20 is a pretty wiffy code smell,
> but it is what it is.
It's worth noting that dataclasses with lots of attributes by default
generate constructors that require all of those as parameters. So it's
a code smell yes, but by that logic so are dataclasses with many
attributes (unless you write a bunch of custom code). Genuine question
- what *is* a non-smelly way of writing a dataclass with 24
attributes?
I've written about 20 variations on this particular class so far, and
none of them feel "right" to me :-(
> > Of course the real problem is that you often don't want to
> > *quite* assign the argument unchanged - `self.provides_extras =
> > set(provides_extras or [])` or `self.requires_python = requires_python
> > or specifiers.SpecifierSet()` are variations that break the whole
> > "just assign the argument unchanged" pattern.
>
> Indeed. Once we move out of that unchanged assignment pattern, we need
> to read more carefully rather than skim
>
> self._spam = (spam or '').lower().strip()
>
> but you can't replace that with auto assignment.
Precisely.
> > As a variation on the issue, which the @ syntax *wouldn't* solve, in
> > classmethods for classes like this, I often find myself constructing
> > dictionaries of arguments, copying multiple values from one dict to
> > another, sometimes with the same sort of subtle variation as above:
> >
> > @classmethod
> > def from_other_args(cls, a, b, c, d):
> > kw = {}
> > kw["a"] = a
> > kw["b"] = b
> > kw["c"] = c
> > kw["d"] = d
> > return cls(**kw)
>
> You may find it easier to make a copy of locals() and delete the
> parameters you don't want, rather than retype them all like that:
>
> params = locals().copy()
> for name in ['cls', 'e', 'g']:
> del params[name]
> return cls(**params)
>
>
> > Again, in "real code", not all of these would be copied, or some would
> > have defaults, etc. The pattern's the same, though - enough args
> > arecopied to make the idea of marking them with an @ seem attractive.
>
> But the @ proposal here won't help. If you mark them with @, won't they
> be auto-assigned onto cls?
Again, precisely.
My point here is that the @ proposal is, in my experience, useful in
far fewer situations than people are claiming. What *is* common (again
in my experience) is variations on a pattern that can be described as
"lots of repetitive copying of values from one location to another,
possibly with minor modifications". Having a way of addressing the
broader problem *might* be of sufficient use to be worth pursuing, and
it might even be possible to do something useful in a library, not
needing new syntax.
On the other hand, the @ syntax as proposed *doesn't* address enough
use cases (for me!) to be worthwhile, especially not if new syntax is
needed rather than just something like a decorator.
Paul
___
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/CD3HRBE2Q6WIKOJDE5GCLFVVHMGR42VZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto assignment of attributes
On Mon, May 2, 2022 at 11:48 AM Steven D'Aprano wrote:
> On Mon, May 02, 2022 at 10:34:56AM -0600, Pablo Alcain wrote:
>
> > For what it's worth,
> > the choice of the `@` was because of two different reasons: first,
> because
> > we were inspired by Ruby's syntax (later on learned that CoffeeScript and
> > Crystal had already taken the approach we are proposing) and because the
> > `@` token is already used as an infix for `__matmul__` (
> > https://peps.python.org/pep-0465/). I believe it's the only usage that
> it
> > has, so it probably won't be that confusing to give it this new semantic
> as
> > well.
>
> Did you forget decorators?
>
totally forgot decorators, my bad!
>
> What other languages support this feature, and what syntax do they use?
>
you mean languages other than those two? I haven't found any. In case you
mean the syntax for those two, I know a tiny bit Crystal's. It leverages
the fact that they use `@` for referring to `self`, as in Ruby.
so you would be able to write something like this:
```
class Person
def initialize(@name : String)
end
def greet
print("Hello, ", @name)
end
end
p = Person.new "Terry"
p.greet
```
>
> Personally, I don't like the idea of introducing syntax which looks
> legal in any function call at all, but is only semantically meaningful
> in methods, and not all methods. Mostly only `__init__`.
Yes, it's a good point. Allowing functions in the wild to use this syntax
would simplify the usage for monkeypatching... but how often would you want
to monkeypatch an `__init__`? and how often would you want to use the
auto-assign outside of the `__init__`? i believe that it's too little. so
in that case, maybe we can make it legal only in all methods. I agree, if
we forego monkeypatching, that semantically it wouldn't be meaningful in
functions; but, in methods, I think that semantically it would make sense
apart from the `__init__`; the thing is that probably it wouldn't be that
useful.
>
> How would this feature work with immutable classes where you want to
> assign attributes to the instance in the `__new__` method?
>
> I fear that this is too magical, too cryptic, for something that people
> only use in a tiny fraction of method. 17% of `__init__` methods is
> probably less than 1% of methods, which means that it is going to be a
> rare and unusual piece of syntax.
>
> Beginners and casual coders (students, scientists, sys admins, etc,
> anyone who dabbles in Python without being immersed in the language) are
> surely going to struggle to recognise where `instance.spam` gets
> assigned, when there is no `self.spam = spam` anywhere in the class or
> its superclasses. There is nothing about "@" that hints that it is an
> assignment.
>
> (Well, I suppose there is that assignment and at-sign both start with A.)
>
> I realise that this will not satisfy those who want to minimize the
> amount of keystrokes, but remembering that code is read perhaps 20-100
> times more than it is written, perhaps we should consider a keyword:
>
> def __init__(self, auto spam:int, eggs:str = ''):
> # spam is automatically bound to self.spam
> self.eggs = eggs.lower()
>
> I dunno... I guess because of that "code is read more than it is
> written" thing, I've never felt that this was a major problem needing
> solving. Sure, every time I've written an __init__ with a bunch of
> `self.spam = spam` bindings, I've felt a tiny pang of "There has to be a
> better way!!!".
>
> But **not once** when I have read that same method later on have I
> regretted that those assignments are explicitly written out, or wished
> that they were implicit and invisible.
>
> Oh, by the way, if *all* of the parameters are to be bound:
>
> def __init__(self, spam, eggs, cheese, aardvark):
> vars(self).update(locals())
> del self.self
>
> Still less magical and more explicit than this auto-assignment proposal.
>
>
>
> --
> 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/C5I33AB2WLW77I77QAJFKZFBJOVNJ7RR/
> 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/JOFVYZG5CSV4C4GVE3QCAKBAENAYROMO/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto assignment of attributes
On Tue, May 3, 2022 at 6:36 AM Paul Moore wrote:
> On Tue, 3 May 2022 at 03:04, Steven D'Aprano wrote:
> >
> > On Mon, May 02, 2022 at 07:44:14PM +0100, Paul Moore wrote:
> >
> > > I have classes with 20+ parameters (packaging metadata). You can argue
> > > that a dataclass would be better, or some other form of refactoring,
> > > and you may actually be right. But it is a legitimate design for that
> > > use case.
> >
> > Indeed. 20+ parameters is only a code smell, it's not *necessarily*
> > wrong. Sometimes you just need lots of parameters, even if it is ugly.
> >
> > For reference, open() only takes 8, so 20 is a pretty wiffy code smell,
> > but it is what it is.
>
> It's worth noting that dataclasses with lots of attributes by default
> generate constructors that require all of those as parameters. So it's
> a code smell yes, but by that logic so are dataclasses with many
> attributes (unless you write a bunch of custom code). Genuine question
> - what *is* a non-smelly way of writing a dataclass with 24
> attributes?
>
> I've written about 20 variations on this particular class so far, and
> none of them feel "right" to me :-(
>
> > > Of course the real problem is that you often don't want to
> > > *quite* assign the argument unchanged - `self.provides_extras =
> > > set(provides_extras or [])` or `self.requires_python = requires_python
> > > or specifiers.SpecifierSet()` are variations that break the whole
> > > "just assign the argument unchanged" pattern.
> >
> > Indeed. Once we move out of that unchanged assignment pattern, we need
> > to read more carefully rather than skim
> >
> > self._spam = (spam or '').lower().strip()
> >
> > but you can't replace that with auto assignment.
>
> Precisely.
>
> > > As a variation on the issue, which the @ syntax *wouldn't* solve, in
> > > classmethods for classes like this, I often find myself constructing
> > > dictionaries of arguments, copying multiple values from one dict to
> > > another, sometimes with the same sort of subtle variation as above:
> > >
> > > @classmethod
> > > def from_other_args(cls, a, b, c, d):
> > > kw = {}
> > > kw["a"] = a
> > > kw["b"] = b
> > > kw["c"] = c
> > > kw["d"] = d
> > > return cls(**kw)
> >
> > You may find it easier to make a copy of locals() and delete the
> > parameters you don't want, rather than retype them all like that:
> >
> > params = locals().copy()
> > for name in ['cls', 'e', 'g']:
> > del params[name]
> > return cls(**params)
> >
> >
> > > Again, in "real code", not all of these would be copied, or some would
> > > have defaults, etc. The pattern's the same, though - enough args
> > > arecopied to make the idea of marking them with an @ seem attractive.
> >
> > But the @ proposal here won't help. If you mark them with @, won't they
> > be auto-assigned onto cls?
>
> Again, precisely.
>
> My point here is that the @ proposal is, in my experience, useful in
> far fewer situations than people are claiming. What *is* common (again
> in my experience) is variations on a pattern that can be described as
> "lots of repetitive copying of values from one location to another,
> possibly with minor modifications". Having a way of addressing the
> broader problem *might* be of sufficient use to be worth pursuing, and
> it might even be possible to do something useful in a library, not
> needing new syntax.
>
It's a good point. We have been thinking a bit about how to measure the
"usefulness" of the proposal. What we have so far is mainly an intuition
driven by code that we and colleagues developed and a couple of statistics (
https://github.com/quimeyps/analize_autoassign in case anyone reading this
doesn't have the link nearby). Although I think that code analysis can be a
way to find out the usefulness of the proposal, the statistics that we have
so far feel a bit coarse-grained to be honest. So any idea on what would be
good metrics to answer the question of "how ofthen the syntax would be
useful" will be more than welcome!
>
> On the other hand, the @ syntax as proposed *doesn't* address enough
> use cases (for me!) to be worthwhile, especially not if new syntax is
> needed rather than just something like a decorator.
>
> Paul
> ___
> 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/CD3HRBE2Q6WIKOJDE5GCLFVVHMGR42VZ/
> 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-idea
[Python-ideas] Re: Auto assignment of attributes
On 5/2/22 23:21, Christopher Barker wrote: > But yes, there are many use cases not suited to dataclasses. The question is how many of these would > rap parge benefit from auto-assigning syntax? How did you get to "rap parge" from "reap the" ? On 5/2/22 20:32, Christopher Barker wrote: > Anyway, I think thee we conversation has moved beyond this. And "thee we" from "that the" ? Do we get bonus points if we break the code? ;-) -- ~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/U7YHFKV7SBUCQTXM3F3A7SP3M7VIKSBZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: infile and outfile parameters for the input function
On Mon, May 02, 2022 at 08:23:31PM -0700, Christopher Barker wrote: > On Mon, May 2, 2022 at 11:18 AM Steven D'Aprano > > > why one couldn't just use the redirect_stdout context manager. > > > > (Plus not-yet-existing, but hopefully soon, redirect_stdin.) > > > I have no use for this but thread safety could be an issue. No more of an issue than it is for other context managers, or for setting sys.stdio directly. > I have no idea if that’s an issue for the kinds of programs this might be > used in, but always good to keep in mind. > > Also — is it that hard to write raw_input()? I feared this would happen... mea culpa. I wrote: **Long before we had context managers**, I manually redirected stdin and stdout to programmatically feed input and capture output from `raw_input`. Emphasis added. When I wrote it I feared that people wouldn't remember that "before we had context managers" was like Python 2.4 or older (by memory), and so what we call input today was called raw_input back then. So I don't need to *write* raw_input, because it already exists :-) But what I do need is a nice and reliable way to feed values into input as if they were typed by the user, and to capture the output of input. -- 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/R6DTLF7G2PCZJV7BAO2GYQMM66C4AFDF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto assignment of attributes
Sorry - auto-correct is not my friend :-( -CHB On Tue, May 3, 2022 at 12:07 PM Ethan Furman wrote: > On 5/2/22 23:21, Christopher Barker wrote: > > > But yes, there are many use cases not suited to dataclasses. The > question is how many of these would > > rap parge benefit from auto-assigning syntax? > > How did you get to "rap parge" from "reap the" ? > > > On 5/2/22 20:32, Christopher Barker wrote: > > > Anyway, I think thee we conversation has moved beyond this. > > And "thee we" from "that the" ? > > Do we get bonus points if we break the code? ;-) > > -- > ~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/U7YHFKV7SBUCQTXM3F3A7SP3M7VIKSBZ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- 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/3ZDY2Q33AQJOOT65NVVYVPANHPL2GE4R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto assignment of attributes
Autocarrot! -- Eric > On May 3, 2022, at 8:32 PM, Christopher Barker wrote: > > > > Sorry - auto-correct is not my friend :-( > > -CHB > >> On Tue, May 3, 2022 at 12:07 PM Ethan Furman wrote: >> On 5/2/22 23:21, Christopher Barker wrote: >> >> > But yes, there are many use cases not suited to dataclasses. The question >> is how many of these would >> > rap parge benefit from auto-assigning syntax? >> >> How did you get to "rap parge" from "reap the" ? >> >> >> On 5/2/22 20:32, Christopher Barker wrote: >> >> > Anyway, I think thee we conversation has moved beyond this. >> >> And "thee we" from "that the" ? >> >> Do we get bonus points if we break the code? ;-) >> >> -- >> ~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/U7YHFKV7SBUCQTXM3F3A7SP3M7VIKSBZ/ >> Code of Conduct: http://python.org/psf/codeofconduct/ > -- > 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/3ZDY2Q33AQJOOT65NVVYVPANHPL2GE4R/ > 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/REOE63KAZYHBGO3QS6Z67CPRP22JYJE7/ Code of Conduct: http://python.org/psf/codeofconduct/
