Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #104889
| From | BartC <bc@freeuk.com> |
|---|---|
| Newsgroups | comp.lang.python |
| Subject | Re: Encapsulation in Python |
| Date | 2016-03-15 00:54 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <nc7man$obt$1@dont-email.me> (permalink) |
| References | (11 earlier) <mailman.133.1457994074.12893.python-list@python.org> <nc7ef9$sgf$1@dont-email.me> <mailman.137.1457997645.12893.python-list@python.org> <nc7it9$ejq$1@dont-email.me> <mailman.138.1458000749.12893.python-list@python.org> |
On 15/03/2016 00:12, Chris Angelico wrote:
> On Tue, Mar 15, 2016 at 10:56 AM, BartC <bc@freeuk.com> wrote:
>> switch c
>> when 'A'..'Z','a'..'z','_' then
>> ++name
>> Anything so terrible about that that Python needs to keep well clear of or
>> that you think its users should be deprived of?
>
> Yes: the complete lack of colons at the ends of lines that introduce
> suites. This is utterly unacceptable in Python!
>
> Seriously though - the one thing that I'm very concerned about here is
> your brackets one.
Yeah, I'm not sure about that either. I'd already written:
when '(', ')', ....
when I thought having a string constant here would be neat, and
implemented that just before posting.
> In Python, there's no reason to restrict 'switch'
> to integers, so I would expect its semantics to be based on either
> equality comparisons or inequality comparisons
I use two forms of switch: one for integers only (very fast), and the
other for any other values, which does tests in sequence.
> (possibly with a
> requirement that all values be hashable); you could have something
> like "when in <string>" but a simple "when <string>" would look to me
> like it's testing for that entire string. (Don't forget that, in
> Python, there's no difference between 'single quoted strings' and
> "double quoted strings", as there is in C-like languages.)
>
> Although... come to think of it, you could actually define it the
> other way around: the 'when' statement checks if the current switch
> object is contained within any of its arguments. Coupled with a
> range-like object with its own literal syntax, that would pretty much
> give you what you're looking at there. However, you'd need to have an
> awkward notation for the cases where you _are_ looking for equality:
>
> switch c:
> when 'A'..'Z', 'a'..'z', ['_']:
> ++name
>
> Or, in a long tree:
>
> switch c:
> when [1]:
> ...
> when [2]:
> ...
> when [3]:
> ...
>
> Which could work. It'd be well-defined, and not unreasonable. It
> would, however, be entirely predicated on a "comparison range" object
> with a literal syntax:
>
> class Range:
> def __init__(self, start, stop):
> self.start = start
> self.stop = stop
> def __contains__(self, obj):
> return self.start <= obj <= self.stop
> def __repr__(self):
> return "%r..%r" % (self.start, self.stop)
>
> But that's not overly hard either.
The tests I do for the more general switch are either equality, or 'in'
for certain combinations of types (mainly testing integers for
membership of ranges and sets. Sets are Pascal-style bit-sets).
I've also looked at the problem of when the choice might be ambiguous:
case x # general 'switch'
when y then
...
What happens when y is a list; should it do x==y or x in y? (Or both?)
I haven't solved that yet but it's never come up. When x is anything
other than an int, you invariably want an equality test.
--
Bartc
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Encapsulation in Python Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-10 08:27 -0700
Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-10 16:45 -0800
Re: Encapsulation in Python Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-11 08:47 -0700
Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-11 18:39 -0800
Re: Encapsulation in Python Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-12 09:44 -0700
Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-12 19:11 -0800
Re: Encapsulation in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-13 21:11 +1100
Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-14 10:32 -0700
Re: Encapsulation in Python Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-14 15:09 -0600
Re: Encapsulation in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-14 21:23 +0000
Re: Encapsulation in Python BartC <bc@freeuk.com> - 2016-03-14 22:07 +0000
Re: Encapsulation in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-14 22:20 +0000
Re: Encapsulation in Python BartC <bc@freeuk.com> - 2016-03-14 22:40 +0000
Re: Encapsulation in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-14 23:19 +0000
Re: Encapsulation in Python BartC <bc@freeuk.com> - 2016-03-14 23:56 +0000
Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-15 11:12 +1100
Re: Encapsulation in Python BartC <bc@freeuk.com> - 2016-03-15 00:54 +0000
Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-15 11:58 +1100
Re: Encapsulation in Python BartC <bc@freeuk.com> - 2016-03-15 01:22 +0000
Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-15 13:02 +1100
Re: Encapsulation in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 00:28 +0000
Re: Encapsulation in Python BartC <bc@freeuk.com> - 2016-03-15 01:10 +0000
Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-15 12:23 +1100
Re: Encapsulation in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 04:41 +0000
Re: Encapsulation in Python rurpy@yahoo.com - 2016-03-14 17:17 -0700
Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-15 11:25 +1100
Re: Encapsulation in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-15 13:06 +1100
Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-15 13:14 +1100
Re: Encapsulation in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-15 13:40 +1100
Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-14 21:08 -0700
Re: Encapsulation in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 00:47 +0000
Re: Encapsulation in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-15 13:46 +1100
Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-15 11:56 +1100
Re: Encapsulation in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 04:36 +0000
Re: Encapsulation in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-15 13:01 +1100
Re: Encapsulation in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 04:45 +0000
Re: Encapsulation in Python Christian Gollwitzer <auriocus@gmx.de> - 2016-03-15 22:02 +0100
Re: Encapsulation in Python BartC <bc@freeuk.com> - 2016-03-16 00:39 +0000
Re: Encapsulation in Python BartC <bc@freeuk.com> - 2016-03-16 22:58 +0000
Re: Encapsulation in Python sohcahtoa82@gmail.com - 2016-03-14 11:11 -0700
Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-14 23:09 -0700
Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-11 18:56 -0800
Re: Encapsulation in Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-03-12 13:52 +1300
Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-12 08:49 -0800
Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-13 08:10 +1100
Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-12 19:36 -0800
Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-13 15:05 +1100
Re: Encapsulation in Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-03-14 12:35 +1300
Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-14 15:55 -0700
csiph-web