Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #17408 > unrolled thread

Pythonification of the asterisk-based collection packing/unpacking syntax

Back to article view | Back to comp.lang.python

Contents

  Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-17 06:38 -0800
    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-17 17:00 +0000
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Roy Smith <roy@panix.com> - 2011-12-17 12:14 -0500
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-18 04:18 +1100
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-17 12:11 -0800
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-17 23:20 +0000
    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-18 00:59 +0000
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-18 13:45 +1100
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-18 03:33 +0000
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Roy Smith <roy@panix.com> - 2011-12-17 22:59 -0500
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-18 15:05 +1100
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Evan Driscoll <edriscoll@wisc.edu> - 2011-12-17 21:03 -0600
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-18 08:46 +0000
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Evan Driscoll <edriscoll@wisc.edu> - 2011-12-17 21:08 -0600
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-18 14:42 +1100
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Evan Driscoll <edriscoll@wisc.edu> - 2011-12-17 22:43 -0600
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-18 16:00 +1100
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-18 06:13 -0800
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-18 17:03 +0000
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-18 09:40 -0800
    Re: Pythonification of the asterisk-based collection packing/unpacking syntax buck <workitharder@gmail.com> - 2011-12-17 20:52 -0800
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-18 16:21 +1100
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Evan Driscoll <edriscoll@wisc.edu> - 2011-12-17 23:33 -0600
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-18 07:31 +0000
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-18 19:43 +1100
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Roy Smith <roy@panix.com> - 2011-12-18 08:58 -0500
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-19 01:06 +1100
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Evan Driscoll <edriscoll@wisc.edu> - 2011-12-18 13:56 -0600
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Duncan Booth <duncan.booth@invalid.invalid> - 2011-12-19 15:23 +0000
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-18 08:36 +0000
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Evan Driscoll <edriscoll@wisc.edu> - 2011-12-18 13:47 -0600
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-19 01:26 +0000
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2011-12-18 18:16 -0800
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Andrew Berg <bahamutzero8825@gmail.com> - 2011-12-19 15:57 -0600
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Roy Smith <roy@panix.com> - 2011-12-19 19:30 -0500
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Andrew Berg <bahamutzero8825@gmail.com> - 2011-12-19 19:41 -0600
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2011-12-19 19:38 -0800
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Andrew Berg <bahamutzero8825@gmail.com> - 2011-12-19 22:04 -0600
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-20 20:51 +0000
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Ian Kelly <ian.g.kelly@gmail.com> - 2011-12-18 20:00 -0700
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-19 03:36 +0000
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-18 06:35 -0800
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Evan Driscoll <edriscoll@wisc.edu> - 2011-12-18 14:20 -0600
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2011-12-18 18:23 -0800
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-19 15:35 +1100
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2011-12-19 19:31 -0800
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-20 15:10 +1100
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-19 02:15 -0800
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2011-12-19 19:30 -0800
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-24 06:39 -0800
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2011-12-24 16:24 -0800
                      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2011-12-24 17:01 -0800
                        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-25 06:45 -0800
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-25 13:12 +0000
                      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-25 07:38 -0800
                        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-26 03:23 +1100
                          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-26 12:58 -0800
                            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-27 08:05 +1100
                              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-26 14:12 -0800
                                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-27 09:37 +1100
                        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-25 17:05 +0000
                          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-26 13:41 -0800
                            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-27 22:57 +0000
                              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-28 03:57 -0800
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2011-12-18 17:04 -0800
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2011-12-18 16:59 -0800
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-19 02:20 -0800
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2011-12-19 19:35 -0800
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-20 05:47 +0000
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2011-12-19 22:39 -0800
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Serhiy Storchaka <storchaka@gmail.com> - 2011-12-20 11:58 +0200
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-24 06:45 -0800
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-25 02:01 +1100
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-24 09:23 -0800
                      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-25 04:51 +1100
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-25 12:50 +0000
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-25 06:59 -0800
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-24 06:41 -0800
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Neal Becker <ndbecker2@gmail.com> - 2011-12-21 10:48 -0500
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-24 06:47 -0800
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-25 01:57 +1100
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-24 09:21 -0800
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-25 13:13 +0000
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-25 07:47 -0800
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-27 23:10 +0000
                      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2011-12-27 17:11 -0800
                        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-28 04:05 -0800
                      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-28 15:06 +1100
                        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-28 06:25 +0000
                          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-28 18:08 +1100
                            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-28 04:08 -0800
                              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Lie Ryan <lie.1296@gmail.com> - 2011-12-29 09:29 +1100
                                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-29 03:55 -0800
                                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-29 13:23 +0000
                                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-29 06:20 -0800
                                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Lie Ryan <lie.1296@gmail.com> - 2011-12-30 10:24 +1100
                                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-30 10:30 +1100
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Ethan Furman <ethan@stoneleaf.us> - 2011-12-21 08:33 -0800
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Evan Driscoll <edriscoll@wisc.edu> - 2011-12-17 23:54 -0600
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-18 06:23 -0800
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2011-12-18 16:57 -0800
    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Neal Becker <ndbecker2@gmail.com> - 2011-12-22 06:49 -0500
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-22 13:12 +0000
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-23 00:30 +1100
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Hans Mulder <hansmu@xs4all.nl> - 2011-12-22 15:13 +0100
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-23 01:30 +1100
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Mel Wilson <mwilson@the-wire.com> - 2011-12-22 10:06 -0500
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-24 06:54 -0800
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-25 12:45 +0000
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-25 06:55 -0800
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-25 16:15 +0000
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-26 12:39 -0800
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-27 08:01 +1100
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-26 13:51 -0800
                      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-27 09:27 +1100
                        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-26 15:44 -0800
                          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-27 11:52 +1100
                            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-27 02:01 -0800
                              Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2012-01-02 18:38 -0800
                                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-02 21:39 -0800
                                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2012-01-02 23:01 -0800
                                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2012-01-03 03:21 -0800
                      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-27 23:07 +0000
                        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-28 04:04 -0800

Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

#17497

On Sun, 18 Dec 2011 20:00:59 -0700, Ian Kelly wrote:

> On Sun, Dec 18, 2011 at 6:26 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> On Sun, 18 Dec 2011 13:47:46 -0600, Evan Driscoll wrote:
>>
>> [...]
>>> so unless you're opposed to using an editor more advanced than
>>> Notepad, you'll type in "varargs", it'll turn purple or whatever, and
>>> you'll go "oh that's a keyword."
>>
>> Not everybody uses editors more advanced than Notepad. Even those who
>> do may not have an editor that understands Python keywords, or has an
>> obsolete list of keywords (my editor of choice doesn't know about
>> NotImplementedError).
> 
> Probably because NotImplementedError is not a keyword.

Poor choice of words on my part. My editor colours built-ins like 
ValueError, TypeError, len, sum, etc., but not NotImplementedError.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#17461

On Dec 18, 6:33 am, Evan Driscoll <edrisc...@wisc.edu> wrote:
> On 12/17/2011 22:52, buck wrote:> Try these on for size.
>
> >      head, @tuple tail = sequence
> >      def foo(@list args, @dict kwargs): pass
> >      foo(@args, @kwargs)
>
> > For backward compatibility, we could say that the unary * is identical to @list and unary ** is identical to @dict.
>
> I like this idea much more than the original one. In addition to the
> arguments buck puts forth, which I find compelling, I have one more: you
> go to great length to say "this isn't really type checking in any sense"
> (which is true)... but then you go forth and pick a syntax that looks
> almost exactly like how you name types in many languages! (In fact,
> except for the fact that it's inline, the 'object :: type' syntax is
> *exactly* how you name types in Haskell.)

No, its not type *checking*, its type *declaration*. I tried to go to
great lengths to point that out, but it appears I did not do a very
good job :). Type declaration is exactly what I want, and insofar this
syntax has already found adoptation elsewhere, ill consider that a
plus.

> I have a bigger objection with the general idea, however.It seems very
> strange that you should have to specify types to use it. If the */**
> syntax were removed, that would make the proposed syntax very very
> unusual for Python. I could be missing something, but I can think of any
> other place where you have to name a type except where the type is an
> integral part of what you're trying to do. (I would not say that
> choosing between tuples and lists are an integral part of dealing with
> vararg functions.) If */** were to stick around, I could see 99% of
> users continuing to use them. And then what has the new syntax achieved?

Good point; technically the askeriskes could be kept for backwards
compatibility, but that would break 'there should only be one way to
do it'. Indeed it would be unusual for python to have to explicitly
name a type, but implicitly ** does very much the same. Its just a
cryptic way of saying 'dict please'.

> You can fix this if you don't require the types and just allow the user
> to say "def foo(@args)" and "foo(@args)". Except... that's starting to
> look pretty familiar... (Not to mention if you just omit the type from
> the examples above you need another way to distinguish between args and
> kwargs.)

Yes, one could opt for a syntax where the collection type is optional
and a sensible default is chosen, But to me that would largely defeat
the point; I very much like the added verbosity and explicitness. args-
tuple and kwargs-dict; that just has a much better ring to it than
star-star-kwargs, or whatever other cryptic symbol you use.

> I have one more suggestion.
>
> I do have one more thing to point out, which is that currently the
> Python vararg syntax is very difficult to Google for. In the first pages
> of the four searches matching "python (function)? (star | asterisk)",
> there was just one relevant hit on python.org which wasn't a bug report.
> I certainly remember having a small amount of difficulty figuring out
> what the heck * and ** did the first time I encountered them.
>
> This would suggest perhaps some keywords might be called for instead of
> operators. In the grand scheme of things the argument packing and
> unpacking are not *all* that common, so I don't think the syntactic
> burden would be immense. The bigger issue, of course, would be picking
> good words.
>
> This also helps with the issue above. Let's say we'll use 'varargs' and
> 'kwargs', though the latter too well-ingrained in code to steal. (I
> don't want to get too much into the debate over *what* word to choose.
> Also these don't match the 'head, *tail = l' syntax very well.) Then we
> could say:
>   def foo(varargs l, kwargs d):
>       bar(varargs l, kwargs d)
> and varargs would be equivalent to * and kwargs would be equivalent to
> **. But then you could also say
>   def foo(varargs(list) l, kwargs(dict) d)

I agree; I had the same experience. But according to others our
opinion is wrong, and we should just become better at using google.

[toc] | [prev] | [next] | [standalone]

#17477

[Multipart message — attachments visible in raw view] — view raw

On 12/18/2011 8:35, Eelco wrote:
> No, its not type *checking*, its type *declaration*. I tried to go to
> great lengths to point that out, but it appears I did not do a very
> good job :). Type declaration is exactly what I want, and insofar this
> syntax has already found adoptation elsewhere, ill consider that a
> plus.
You say it's found adoption elsewhere, but I think it's that adoption
which makes it a *bad* idea, because it does something entirely
different in those situations. Other languages are using that syntax for
something which is statically checked -- you are proposing that syntax
for a dynamic conversion.

look pretty familiar... (Not to mention if you just omit the type from
the examples above you need another way to distinguish between args and
kwargs.)


> Yes, one could opt for a syntax where the collection type is optional
> and a sensible default is chosen, But to me that would largely defeat
> the point; I very much like the added verbosity and explicitness. args-
> tuple and kwargs-dict; that just has a much better ring to it than
> star-star-kwargs, or whatever other cryptic symbol you use.
My problem with it is that it in some sense is forcing me to make a
decision I don't care about. Yes, what we have now is less flexible, but
I have *never* said "man, I wish this *args parameter were a list
instead of a tuple". So at least for me, making me say "args::tuple" or
"@tuple args" or whatever is just changing the syntax a bit and adding
several more characters for me to type.

Evan

[toc] | [prev] | [next] | [standalone]

#17491

Evan Driscoll <edrisc...@wisc.edu> wrote:
> My problem with it is that it in some sense is forcing me to make a
> decision I don't care about. Yes, what we have now is less flexible, but
> I have *never* said "man, I wish this *args parameter were a list
> instead of a tuple".

And if you _did_, then one of the first lines in your function would
be:

    args = list(args)

Which is obvious to everyone, doesn't modify existing behaviour,
doesn't force everyone without a fetish for change to add unnecessary
cruft to their function signature...

Except, OMG, list() is RETURNING A LIST, which is an OBVIOUS type
constraint. I propose that:

    args = @set list(args)

Will coerce args into a list and then give me a set in return.

[toc] | [prev] | [next] | [standalone]

#17498

On Mon, Dec 19, 2011 at 1:23 PM, alex23 <wuwei23@gmail.com> wrote:
> Except, OMG, list() is RETURNING A LIST, which is an OBVIOUS type
> constraint. I propose that:
>
>    args = @set list(args)
>
> Will coerce args into a list and then give me a set in return.

Point to note:

list,set = set,list  # Request a death sentence from the next maintainer

is perfectly legal code. Now, what does your "args=" line do?

ChrisA

[toc] | [prev] | [next] | [standalone]

#17551

On Dec 19, 2:35 pm, Chris Angelico <ros...@gmail.com> wrote:
> Point to note:
>
> list,set = set,list  # Request a death sentence from the next maintainer
>
> is perfectly legal code. Now, what does your "args=" line do?
>
> ChrisA

Why are you directing this at my mocking of the OPs idea when the same
issue is present in his proposal?

[toc] | [prev] | [next] | [standalone]

#17554

On Tue, Dec 20, 2011 at 2:31 PM, alex23 <wuwei23@gmail.com> wrote:
> On Dec 19, 2:35 pm, Chris Angelico <ros...@gmail.com> wrote:
>> Point to note:
>>
>> list,set = set,list  # Request a death sentence from the next maintainer
>>
>> is perfectly legal code. Now, what does your "args=" line do?
>>
>> ChrisA
>
> Why are you directing this at my mocking of the OPs idea when the same
> issue is present in his proposal?

Because it was after reading your post that I saw reason to write
that, and it tied in better with your post than any other. No other
reason.

ChrisA

[toc] | [prev] | [next] | [standalone]

#17506

On Dec 19, 3:23 am, alex23 <wuwe...@gmail.com> wrote:
> Evan Driscoll <edrisc...@wisc.edu> wrote:
> > My problem with it is that it in some sense is forcing me to make a
> > decision I don't care about. Yes, what we have now is less flexible, but
> > I have *never* said "man, I wish this *args parameter were a list
> > instead of a tuple".
>
> And if you _did_, then one of the first lines in your function would
> be:
>
>     args = list(args)
>
> Which is obvious to everyone, doesn't modify existing behaviour,
> doesn't force everyone without a fetish for change to add unnecessary
> cruft to their function signature...

Its obvious you end up with a list (assuming args is an iterable);
knowing what args was to begin with suffers from the same problems.

> Except, OMG, list() is RETURNING A LIST, which is an OBVIOUS type
> constraint. I propose that:
>
>     args = @set list(args)
>
> Will coerce args into a list and then give me a set in return.

?
What does that have to do with collection packing/unpacking?

[toc] | [prev] | [next] | [standalone]

#17542

On Dec 19, 8:15 pm, Eelco <hoogendoorn.ee...@gmail.com> wrote:
> What does that have to do with collection packing/unpacking?

It's mocking your insistance that collection unpacking is a type
constraint.

[toc] | [prev] | [next] | [standalone]

#17843

On Dec 20, 4:30 am, alex23 <wuwe...@gmail.com> wrote:
> On Dec 19, 8:15 pm, Eelco <hoogendoorn.ee...@gmail.com> wrote:
>
> > What does that have to do with collection packing/unpacking?
>
> It's mocking your insistance that collection unpacking is a type
> constraint.

This is really going to be the last time I waste any words on this:

The sentence 'collection unpacking is a type constraint' is entirely
nonsensical. A type constraint is a linguistical construct that can be
applied in many ways; typically, to narrow down the semantics of use
of the symbol to which the type constraint is applied.

In case of python, collection PACKING (not unpacking) is signaled by a
construct that can be viewed as a type constraint. But if you dont
want to fortify your view of the syntax by looking at what it is
actually going on, ill repeat again; lets keep things simple, and not
analyze it in detail.

So here it is again, in terms every 5 year old can understand. Id like
to do the exact same thing python is already doing. Except with a few
more, and different symbols, to enable one to express a few different
variants of behavior. Clear enough?

[toc] | [prev] | [next] | [standalone]

#17869

On Dec 25, 12:39 am, Eelco <hoogendoorn.ee...@gmail.com> wrote:
> This is really going to be the last time I waste any words on this

Oh hey, don't feel you actually have to justify the bullshit you're
talking for my sake.

> In case of python, collection PACKING (not unpacking) is signaled by a
> construct that can be viewed as a type constraint.

_But no one does view it that way because it isn't_. No more so than
[] taking a string separated list of arguments and return a list is a
type constraint. _That's it's behaviour_.

We have a language construct that returns a tuple, because in the
context of what tuples are in Python, that makes sense. There are
_plenty_ of such constructs. You have still yet to show what adding
all of this ridiculous shit to a function signature provides that
coercing the resulting tuple to your own type doesn't.

> So here it is again, in terms every 5 year old can understand. Id like
> to do the exact same thing python is already doing. Except with a few
> more, and different symbols, to enable one to express a few different
> variants of behavior. Clear enough?

That you're a condescending douchebag with nothing of value to
contribute?

Crystal.

[toc] | [prev] | [next] | [standalone]

#17871

On Dec 24, 6:24 pm, alex23 <wuwe...@gmail.com> wrote:

> That you're a condescending douchebag with nothing of value to
> contribute?
>
> Crystal.

Take it from me Eelco. Once Alex drops into your thread and starts
name calling, it's over my friend.

[toc] | [prev] | [next] | [standalone]

#17908

On Dec 25, 2:01 am, Rick Johnson <rantingrickjohn...@gmail.com> wrote:
> On Dec 24, 6:24 pm, alex23 <wuwe...@gmail.com> wrote:
>
> > That you're a condescending douchebag with nothing of value to
> > contribute?
>
> > Crystal.
>
> Take it from me Eelco. Once Alex drops into your thread and starts
> name calling, it's over my friend.

Yes, he has quite worn out my patience; whats over is our (attempts
at) two sided communication, but I hope to continue the constructive
lines of argument in this thread.

[toc] | [prev] | [next] | [standalone]

#17887

On Sat, 24 Dec 2011 06:39:39 -0800, Eelco wrote:

> On Dec 20, 4:30 am, alex23 <wuwe...@gmail.com> wrote:
>> On Dec 19, 8:15 pm, Eelco <hoogendoorn.ee...@gmail.com> wrote:
>>
>> > What does that have to do with collection packing/unpacking?
>>
>> It's mocking your insistance that collection unpacking is a type
>> constraint.
> 
> This is really going to be the last time I waste any words on this:

If only that were true, but after sending this post, you immediately 
followed up with FIVE more posts on this subject in less than half an 
hour.


> The sentence 'collection unpacking is a type constraint' is entirely
> nonsensical. 

How true. Given that you have now acknowledged this fact, can you please 
stop insisting that collection unpacking is a type constraint?


> A type constraint is a linguistical construct that can be
> applied in many ways; typically, to narrow down the semantics of use of
> the symbol to which the type constraint is applied.

Traceback (most recent call last):
RuntimeError: maximum recursion depth exceeded


> In case of python, collection PACKING (not unpacking) is signaled by a
> construct that can be viewed as a type constraint.

Only by doing sufficient violence to the concept of type constraint that 
it could mean *anything*.

Earlier, I insisted that a constraint is a rule that applies to input, 
not output. I haven't seen anyone, including yourself, dispute that.

Normally we would say that in the statement:

    y = list(x)

there is a constraint on x, namely that it is some sort of iterable 
object (otherwise an exception will be raised), but it would be an abuse 
of language to say that there is a type constraint on y. y ends up being 
a list, true, but that isn't a constraint on y, it is an outcome.

In normal usage, "constraint" refers to pre-conditions, not post-
conditions. There are no pre-conditions on y in the above. It may not 
even exist. Contrast it with this example:

    y += list(x)

where there are constraints on y: it must exist, and it must be a list, 
or something which can be added to a list.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#17912

On Dec 25, 2:12 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Sat, 24 Dec 2011 06:39:39 -0800, Eelco wrote:
> > On Dec 20, 4:30 am, alex23 <wuwe...@gmail.com> wrote:
> >> On Dec 19, 8:15 pm, Eelco <hoogendoorn.ee...@gmail.com> wrote:
>
> >> > What does that have to do with collection packing/unpacking?
>
> >> It's mocking your insistance that collection unpacking is a type
> >> constraint.
>
> > This is really going to be the last time I waste any words on this:
>
> If only that were true, but after sending this post, you immediately
> followed up with FIVE more posts on this subject in less than half an
> hour.

Did I waste any more words on collection packing and type constraints?
No, I did not. (though I am about to, and am willing to do so for
every question that seems genuinely aimed at engaging me on the
matter)

Did I intend to say that I was going to let a single troll shut down
my entire topic? No, I did not.

> > In case of python, collection PACKING (not unpacking) is signaled by a
> > construct that can be viewed as a type constraint.
>
> Only by doing sufficient violence to the concept of type constraint that
> it could mean *anything*.
>
> Earlier, I insisted that a constraint is a rule that applies to input,
> not output. I haven't seen anyone, including yourself, dispute that.
>
> Normally we would say that in the statement:
>
>     y = list(x)
>
> there is a constraint on x, namely that it is some sort of iterable
> object (otherwise an exception will be raised), but it would be an abuse
> of language to say that there is a type constraint on y. y ends up being
> a list, true, but that isn't a constraint on y, it is an outcome.
>
> In normal usage, "constraint" refers to pre-conditions, not post-
> conditions. There are no pre-conditions on y in the above. It may not
> even exist. Contrast it with this example:
>
>     y += list(x)
>
> where there are constraints on y: it must exist, and it must be a list,
> or something which can be added to a list.

Yes, indeed it would be abuse of language to call this a type
constraint, since the fact that y is a list is indeed an outcome of
whatever happens to pop out at the right hand side. One could redefine
the identifier list to return any kind of object.

How is 'head, *tail = sequence' or semantically entirely equivalently,
'head, tail::list = sequence' any different then? Of course after
interpretation/compilation, what it boils down to is that we are
constructing a list and binding it to the identifier tail, but that is
not how it is formulated in python as a language (all talk of types is
meaningless after compilation; machine code is untyped). We dont have
something of the form 'tail = list_tail(sequence)'. Rather, we
annotate the identifier 'tail' with an attribute that unquestionably
destinates it to become a list*. It is no longer that 'tail' will just
take anything that pops out of the expression on the right hand side;
rather, the semantics of what will go on at right hand side is coerced
by the constraint placed on 'tail'.

But again, if you dont wish to view this as a type constraint, I wont
lose any sleep over that. In that case this line of argument was
simply never directed at you. It was directed at people who would
reasonably argue that 'tail::tuple is a type constraint and thats
unpythonic / type constraints have been considered and rejected'. If
you dont think it looks like a type constraint: fine. The simpler
argument is that whatever it is, its just a more verbose and flexible
variant of a construct that python already has.

*(I call that a 'type constraint', because that is what it literally
is; if you can make a case that this term has acquired a different
meaning in practice, and that there is another term in common use for
this kind of construct; please enlighten me. Until that time, im going
to ask you to take 'type constraint' by its literal meaning; a
coercion of the type of a symbol, rather than whatever particular
meaning it has acquired for you (it might help if you explained that).
Im not sure if it was you that brought that up, but let me reiterate
that I dont mean a 'type cast', which is a runtime concept. A 'type
constraint' is purely a linguistic construct that will be 'compiled
out')

[toc] | [prev] | [next] | [standalone]

#17919

On Mon, Dec 26, 2011 at 2:38 AM, Eelco <hoogendoorn.eelco@gmail.com> wrote:
> Until that time, im going
> to ask you to take 'type constraint' by its literal meaning; a
> coercion of the type of a symbol, rather than whatever particular
> meaning it has acquired for you (it might help if you explained that).
> Im not sure if it was you that brought that up, but let me reiterate
> that I dont mean a 'type cast', which is a runtime concept. A 'type
> constraint' is purely a linguistic construct that will be 'compiled
> out')

The dictionary definition of constraint is "a limitation or
restriction", and you're right that it can be "compiled out". In fact,
that is probably the best definition. Assuming everything is written
correctly, you should be able to eliminate all constraints and the
code will still function correctly*; but having the constrains means
that certain illegal operations will throw errors.

Here's two examples of tuple unpacking, one with a type constraint,
the other without:

a, b = ('hello', [1,2,3] )
a, b::list = ('hello', [1,2,3] )

The constraint on the second line means that, if the second element is
not a list, the interpreter should throw an error. It does NOT mean to
completely change the meaning of the statement to _make_ the last
argument into a list. That is not the job of a constraint.

ChrisA

* In databasing, it's not uncommon to have code depend on error
responses for correct operation; for instance, one implementation of
UPSERT is to attempt an INSERT, and if it fails due to a unique key
constraint, do the UPDATE instead. The same is also done in Python -
eg using an exception to terminate a loop - but in the context of this
discussion, assume that errors indicate errors.

[toc] | [prev] | [next] | [standalone]

#17979

On Dec 25, 5:23 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Mon, Dec 26, 2011 at 2:38 AM, Eelco <hoogendoorn.ee...@gmail.com> wrote:
> > Until that time, im going
> > to ask you to take 'type constraint' by its literal meaning; a
> > coercion of the type of a symbol, rather than whatever particular
> > meaning it has acquired for you (it might help if you explained that).
> > Im not sure if it was you that brought that up, but let me reiterate
> > that I dont mean a 'type cast', which is a runtime concept. A 'type
> > constraint' is purely a linguistic construct that will be 'compiled
> > out')
>
> The dictionary definition of constraint is "a limitation or
> restriction", and you're right that it can be "compiled out". In fact,
> that is probably the best definition. Assuming everything is written
> correctly, you should be able to eliminate all constraints and the
> code will still function correctly*; but having the constrains means
> that certain illegal operations will throw errors.
>
> Here's two examples of tuple unpacking, one with a type constraint,
> the other without:
>
> a, b = ('hello', [1,2,3] )
> a, b::list = ('hello', [1,2,3] )
>
> The constraint on the second line means that, if the second element is
> not a list, the interpreter should throw an error. It does NOT mean to
> completely change the meaning of the statement to _make_ the last
> argument into a list. That is not the job of a constraint.

Thank you for providing clarification on what a 'type constraint'
means to you. That clears things up a bit.

What you are talking about goes by the name of a 'dynamic type CHECK';
some kind of syntactic sugar for something like
'assert(type(obj)==sometype)'. Like a 'type cast', this is also a
runtime concept. How you manage to confuse that with what I am talking
about, given that ive stated many times I am not talking about a
runtime construct but a compile-time construct, is quite beyond me.
(not to mention that ive quite explicitly stated what I mean by 'type
constraint' many times now).

By contrast, here is the first google hit for 'type constraint'.

http://msdn.microsoft.com/en-us/library/d5x73970.aspx

Note that this is a different application of the concept of a type
constraint, but nonetheless,  the concept is as I stated it: a
constraint to the type of a symbol to modify its compile-time
semantics. To cite from its first paragraph:

"...you can apply restrictions to the kinds of types ... by using a
type that is not allowed by a constraint, the result is a COMPILE-TIME
ERROR" (emphasis mine)

[toc] | [prev] | [next] | [standalone]

#17981

On Tue, Dec 27, 2011 at 7:58 AM, Eelco <hoogendoorn.eelco@gmail.com> wrote:
> What you are talking about goes by the name of a 'dynamic type CHECK';
> some kind of syntactic sugar for something like
> 'assert(type(obj)==sometype)'. Like a 'type cast', this is also a
> runtime concept...
>
> By contrast, here is the first google hit for 'type constraint'.
>
> http://msdn.microsoft.com/en-us/library/d5x73970.aspx
>
> "...you can apply restrictions to the kinds of types ... by using a
> type that is not allowed by a constraint, the result is a COMPILE-TIME
> ERROR" (emphasis mine)

A constraint can be applied at compile time or at run time. It'd be
valid to apply them at edit time, if you so chose - your editor could
refuse to save your file until you fix the problem. Doesn't mean a
thing. Python, by its nature, cannot do compile-time type checking.
Under no circumstances, however, does this justify the use of the term
"constraint" to mean "utterly different semantics of the same code".

ChrisA

[toc] | [prev] | [next] | [standalone]

#17984

On Dec 26, 10:05 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Tue, Dec 27, 2011 at 7:58 AM, Eelco <hoogendoorn.ee...@gmail.com> wrote:
> > What you are talking about goes by the name of a 'dynamic type CHECK';
> > some kind of syntactic sugar for something like
> > 'assert(type(obj)==sometype)'. Like a 'type cast', this is also a
> > runtime concept...
>
> > By contrast, here is the first google hit for 'type constraint'.
>
> >http://msdn.microsoft.com/en-us/library/d5x73970.aspx
>
> > "...you can apply restrictions to the kinds of types ... by using a
> > type that is not allowed by a constraint, the result is a COMPILE-TIME
> > ERROR" (emphasis mine)
>
> A constraint can be applied at compile time or at run time. It'd be
> valid to apply them at edit time, if you so chose - your editor could
> refuse to save your file until you fix the problem. Doesn't mean a
> thing.

A constraint in the sense that I have explained many times now, can in
no way, shape or form be applied at run time. Youd have better luck
applying a consternation to a squirrel. Perhaps you meant 'type check'
again? But then again, that makes no sense whatsoever at compile-
time... Im starting to doubt if there is any sense to be found here at
all.

Anyway, ill take your further silence on the matter as a 'sorry I
derailed your thread with my confusion of terminology'

> Python, by its nature, cannot do compile-time type checking.

Python can do whatever its designers have put into it. In this case,
that includes the emission of different code based on a (type)
annotation at the point of declaration of an identifier (only in the
particular circumstance of collection unpacking though, as far as I am
aware).

> Under no circumstances, however, does this justify the use of the term
> "constraint" to mean "utterly different semantics of the same code".

Thank you for your theory on justice. Im sure its fascinating, but
until you get around to actually explaining it, im going to have to be
conservative and stick with the jargon in common use though, sorry.

[toc] | [prev] | [next] | [standalone]

#17987

On Tue, Dec 27, 2011 at 9:12 AM, Eelco <hoogendoorn.eelco@gmail.com> wrote:
> On Dec 26, 10:05 pm, Chris Angelico <ros...@gmail.com> wrote:
>> A constraint can be applied at compile time or at run time. It'd be
>> valid to apply them at edit time, if you so chose - your editor could
>> refuse to save your file until you fix the problem. Doesn't mean a
>> thing.
>
> A constraint in the sense that I have explained many times now, can in
> no way, shape or form be applied at run time. Youd have better luck
> applying a consternation to a squirrel. Perhaps you meant 'type check'
> again? But then again, that makes no sense whatsoever at compile-
> time... Im starting to doubt if there is any sense to be found here at
> all.

A constraint failure causes an error at the time it's discovered.
1) Your editor pops up a message the instant you type something with
such an error, and forces you to correct it before going on.
2) Your compiler refuses to produce byte-code for the module.
3) When the line of code is executed, an exception is thrown.
All of these are valid ways of handling a constraint. Here is a Python
example of a type constraint:

def foo(arg):
    if not isinstance(arg,list): raise "This won't work."

If you call it with something that's not a list, you get an error.
Call it with a list, and execution continues normally. That's a
constraint. Of course, it might not be a _type_ constraint:

def foo(arg):
   if arg>5: raise "This won't work either." # and yes, that's oddly
truer in Python 3

(Aside: In Pike, I can actually put that into a type constraint
(declare the argument to be int(5..) for instance). This, however, is
not germane to the conversation.)

> Anyway, ill take your further silence on the matter as a 'sorry I
> derailed your thread with my confusion of terminology'

Like Mary Poppins, I never apologize for derailing threads :)

>> Python, by its nature, cannot do compile-time type checking.
>
> Python can do whatever its designers have put into it. In this case,
> that includes the emission of different code based on a (type)
> annotation at the point of declaration of an identifier (only in the
> particular circumstance of collection unpacking though, as far as I am
> aware).

Of course, but how can Python, without a completely different
structure, do compile-time checking of object types? Everything can be
monkey-patched at run-time. Anything could be affected by any function
call. It's impossible to say for certain, at compile time, what data
type anything will have.

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

Back to top | Article view | comp.lang.python

csiph-web