Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

[Peter Ludemann via Python-Dev]

On 10 November 2017 at 19:17, Greg Ewing 
wrote:

> Ethan Furman wrote:
>
>> Contriwise, "annotation_strings" sounds like a different type of
>> annotation -- they are now being stored as strings, instead of something
>> else.
>>
>
> How about "annotations_as_strings"?


That feels unambiguous. "annotations_to_str" is shorter, given that "str"
is a type in Python, and "to" says that it's converting *to* string (it's
given *as* an expression).
​

>
>
> --
> Greg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/pludemann
> %40google.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The current dict is not an "OrderedDict"

[Peter Ludemann via Python-Dev]

Does it matter whether the dict order after pop/delete is explicitly
specified, or just specified that it's deterministic?

On 7 November 2017 at 11:28, Antoine Pitrou  wrote:

> On Wed, 8 Nov 2017 06:19:46 +1100
> Chris Angelico  wrote:
> >
> > I've used a good few dictionary objects in my time, but most of them
> > have literally never had any items deleted from them.
>
> Well... It really depends what kind of problem you're solving.  I
> certainly delete or pop items from dicts quite often.
>
> Let's not claim that deleting items from a dict is a rare or advanced
> feature.  It is not.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> pludemann%40google.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

[Peter Ludemann via Python-Dev]

Isn't ordered dict also useful for **kwargs?

If it turns out that there's a dict implementation that's faster by not
preserving order, collections.UnorderedDict could be added.
There could also be specialized implementations that pre-size the dict (cf:
C++ unordered_map::reserve), etc., etc.
But these are all future things, which might not be necessary.

On 5 November 2017 at 12:44, Sven R. Kunze  wrote:

> +1 from me too.
>
> On 04.11.2017 21:55, Jim Baker wrote:
>
> +1, as Guido correctly recalls, this language guarantee will work well
> with Jython when we get to the point of implementing 3.7+.
>
> On Sat, Nov 4, 2017 at 12:35 PM, Guido van Rossum 
> wrote:
>
>> This sounds reasonable -- I think when we introduced this in 3.6 we were
>> worried that other implementations (e.g. Jython) would have a problem with
>> this, but AFAIK they've reported back that they can do this just fine. So
>> let's just document this as a language guarantee.
>>
>> On Sat, Nov 4, 2017 at 10:30 AM, Stefan Krah  wrote:
>>
>>>
>>> Hello,
>>>
>>> would it be possible to guarantee that dict literals are ordered in v3.7?
>>>
>>>
>>> The issue is well-known and the workarounds are tedious, example:
>>>
>>>https://mail.python.org/pipermail/python-ideas/2015-Decembe
>>> r/037423.html
>>>
>>>
>>> If the feature is guaranteed now, people can rely on it around v3.9.
>>>
>>>
>>>
>>> Stefan Krah
>>>
>>>
>>>
>>> ___
>>> Python-Dev mailing list
>>> Python-Dev@python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe: https://mail.python.org/mailma
>>> n/options/python-dev/guido%40python.org
>>>
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido )
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/jbaker%
>> 40zyasoft.com
>>
>>
>
>
> ___
> Python-Dev mailing 
> listPython-Dev@python.orghttps://mail.python.org/mailman/listinfo/python-dev
>
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/srkunze%40mail.de
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> pludemann%40google.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

[Peter Ludemann via Python-Dev]

If type annotations are treated like implicit lambdas, then that's a first
step to something similar to Lisp's "special forms". A full generalization
of that would allow, for example, logging.debug to not evaluate its args
unless debugging is turned on (I use a logging.debug wrapper that allows
lambdas as args, and evaluates them if debugging is turned on).

Maybe a better question is whether we want "special forms" in Python. It
complicates some things but simplifies others. But things that satisfy Lisp
programmers might not make Python programmers happy. ;)


On 4 November 2017 at 09:42, Guido van Rossum  wrote:

> I'm very worried about trying to come up with a robust implementation of
> this in under 12 weeks. By contrast, the stringification that Łukasz is
> proposing feels eminently doable.
>
> On Sat, Nov 4, 2017 at 6:51 AM, Nick Coghlan  wrote:
>
>> On 4 November 2017 at 00:40, Guido van Rossum  wrote:
>> > IMO the inability of referencing class-level definitions from
>> annotations on
>> > methods pretty much kills this idea.
>>
>> If we decided we wanted to make it work, I think the key runtime
>> building block we would need is a new kind of cell reference: an
>> IndirectAttributeCell.
>>
>> Those would present the same interface as a regular nonlocal cell (so
>> it could be stored in __closure__ just as regular cells are, and
>> accessed the same way when the function body is executed), but
>> internally it would hold two references:
>>
>> - one to another cell object (__class__ for this use case)
>> - an attribute name on the target object that get/set/del operations
>> on the indirect cell's value should affect
>>
>> As Python code:
>>
>> class IndirectAttributeCell:
>> def __new__(cls, cell, attr):
>> self._cell = cell
>> self._attr = attr
>>
>> @property
>> def cell_contents(self):
>> return getattr(self._cell.cell_contents, self._attr)
>>
>> @cell_contents.setter
>> def cell_contents(self, value):
>> setattr(self._cell.cell_contents, self._attr, value)
>>
>> @cell_contents.deleter
>> def cell_contents(self):
>> delattr(self._cell.cell_contents, self._attr)
>>
>> The class body wouldn't be able to evaluate the thunks (since
>> `__class__` wouldn't be set yet), but `__init_subclass__`
>> implementations could, as could class decorators.
>>
>> It would require some adjustment in the compiler as well (in order to
>> pass the class level attribute definitions down to these implicitly
>> defined scopes as a new kind of accessible external namespace during
>> the symbol analysis pass, as well as to register the use of
>> "__class__" if one of the affected names was referenced), but I think
>> it would work at least at a technical level (by contrast, every other
>> idea I came up with back when I was working on the list comprehension
>> change was sufficiently flawed that it fell apart within a few hours
>> of starting to tinker with the idea).
>>
>> As an added bonus, we could potentially also extend the same
>> permissive name resolution semantics to the implicit scopes used in
>> comprehensions, such that it was only the explicitly defined scopes
>> (i.e. lambda expressions, function definitions, and nested classes)
>> that lost implicit access to the class level variables.
>>
>> Cheers,
>> Nick.
>>
>> P.S. If we subsequently decided to elevate expression thunks to a
>> first class language primitive, they shouldn't need any further
>> semantic enhancements beyond that one, since the existing scoping
>> rules already give the desired behaviour at module and function scope.
>>
>> --
>> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> pludemann%40google.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] \G (match last position) regex operator non-existant in python?

[Peter Ludemann via Python-Dev]

On 28 October 2017 at 16:48, Steven D'Aprano  wrote:

> On Sun, Oct 29, 2017 at 12:31:01AM +0100, MRAB wrote:
>
> > Not that I'm planning on making any further additions, just bug fixes
> > and updates to follow the Unicode updates. I think I've crammed enough
> > into it already. There's only so much you can do with the regex syntax
> > with its handful of metacharacters and possible escape sequences...
>
> What do you think of the Perl 6 regex syntax?
>
> https://en.wikipedia.org/wiki/Perl_6_rules#Changes_from_Perl_5


​If you're going to change the notation, why not use notations similar to
what linguists use for FSTs? These allow building FSTs (with operations
such as adding/subtracting/composing/projecting FSTs) with millions of
states — and there are some impressive optimisers for them also, so that
encoding a dictionary with inflections is both more compact and faster than
a hash of just the words without inflections. Some of this work is open
source, but I haven't kept up with it.

If you're interested, you can start here:
http://web.stanford.edu/~laurik/​
http://web.stanford.edu/~laurik/publications/TR-2010-01.pdf
http://web.stanford.edu/group/cslipublications/cslipublications/site/1575864347.shtml
etc.

;)




>
>
>
>
> --
> Steve
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> pludemann%40google.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TextIO seek and tell cookies

[Peter Ludemann via Python-Dev]

On 25 September 2016 at 21:18, Guido van Rossum  wrote:

> Be careful though, comparing these to plain integers should probably
> be allowed,


​There's a good reason why it's "opaque" ... why would you want to make it
less opaque?

And I'm curious why Python didn't adopt the fgetpos/fsetpos style that
makes the data structure completely opaque (fpos_t). IIRC, this was added
to C when the ANSI standard was first written, to allow cross-platform
compatibility in cases where ftell/fseek was difficult (or impossible) to
fully implement. Maybe those reasons don't matter any more (e.g., dealing
with record-oriented or keyed file systems) ...



> and we also should make sure that things like
> serialization via JSON or storing in an SQL database don't break. I
> personally think it's one of those "learn not to touch the stove"
> cases and there's limited value in making this API idiot proof.
>
> On Sun, Sep 25, 2016 at 9:05 PM, Nick Coghlan  wrote:
> > On 26 September 2016 at 10:21, MRAB  wrote:
> >> On 2016-09-26 00:21, Ben Leslie wrote:
> >>> Are there any downsides to this? I've made some progress developing a
> >>> patch to change this functionality. Is it worth polishing and
> >>> submitting?
> >>>
> >> An alternative might be a subclass of int.
> >
> > It could make sense to use a subclass of int that emitted deprecation
> > warnings for integer arithmetic, and then eventually disallowed it
> > entirely.
> >
> > Cheers,
> > Nick.
> >
> > --
> > Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> pludemann%40google.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

[Peter Ludemann via Python-Dev]

I would take the opposite approach from Greg Ewing, namely that the
annotation is not a permission of values but a starting point for the type
inferencer; and the type checker/inferencer can complain if there's an
inconsistency (for some definition of "inconsistency", which is not defined
in the PEP). In most cases, this distinction doesn't matter, but it does
affect what kinds of errors or warnings are generated.

But ... perhaps people are overthinking these things? If we go back to the
example without variable annotation:

def bar()->Optional[int]: ...

def foo():
  x = bar()
  if x is None:
return -1
  return x

then a straightforward flow-tracing type inferencer can *infer* all the
annotations in foo:

def foo() -> int:  # *not* Optional[int] - see below
  x:Optional[int] = bar()  # derived from definition of bar
  if x is None:  # consistent with x:Optional[int]
return -1  # implies return type of foo
  return x  # implies return type of foo as Union[int, None] minus
None, that is: int

That is, the type annotations add no information in this example, but might
be useful to a human. Perhaps they wouldn't show in the source code at all,
but would instead be put into a database, for use by development tools -
for example, Kythe -flavored
tools, where the type data (and other usage information) are used for code
search, editing, refactoring, etc. (Or the type information could be kept
in a .pyi stub file, with an automated "merge" tool putting them into the
.py file as desired.)

On the other hand, a non-flow-tracing inferencer would derive 'def foo() ->
Optional[int]' ... it would be a *design choice* of the type
checker/inferencer as to whether that's an error, a warning, or silently
allowed ... I can see arguments for all of these choices.

In most cases, there's seldom any need for the programmer to add
annotations to local variables. Global variables and class/instance
attributes, however, can benefit from annotation.

(As to my credentials, which some people seem to crave: I worked on an
earlier version of Google's Python type inferencer (*pytype*) and I'm
currently working on *pykythe *(to be open-sourced), which takes the
function-level information and propagates it to the local variables, then
adds that information (together with call graph information) to a Kythe
database.)



On 5 September 2016 at 15:16, Greg Ewing 
wrote:

> Mark Shannon wrote:
>
> Unless of course, others may have a different idea of what the "type of a
>> variable" means.
>> To me, it means it means that for all assignments `var = expr`
>> the type of `expr` must be a subtype of the variable,
>> and for all uses of var, the type of the use is the same as the type of
>> the variable.
>>
>
> I think it means that, at any given point in time, the
> value of the variable is of the type of the variable or
> some subtype thereof. That interpretation leaves the
> type checker free to make more precise inferences if
> it can. For example, in...
>
> def foo()->int:
>> x:Optional[int] = bar()
>> if x is None:
>> return -1
>> return x
>>
>
> ...the type checker could notice that, on the branch
> containing 'return x', the value of x must be of type
> int, so the code is okay.
>
> --
> Greg
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/pludemann
> %40google.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NewType() to PEP 484

[Peter Ludemann via Python-Dev]

I'm surprised that nobody has suggested UniqueType. ;)


On 28 May 2016 at 10:17, Ivan Levkivskyi  wrote:

> My final vote goes to "distinct type alias".
> But how should we call the function? NewType? Or should we change it to
> DistinctAlias or something?
>
> --
> Ivan
> 28 Тра 2016 19:14 "Guido van Rossum"  пише:
>
>> Oh, another D-word! I really like distinct.
>>
>> On Sat, May 28, 2016 at 8:19 AM, Steve Dower 
>> wrote:
>> > Did anyone suggest "distinct type alias"?
>> >
>> > Regardless of what name, I'm fairly sure people will call it whatever
>> the
>> > function to create it is called. So if the function is
>> > typings.distinguish_type(...), then distinguished will stick.
>> >
>> > Top-posted from my Windows Phone
>> > 
>> > From: Guido van Rossum
>> > Sent: ‎5/‎28/‎2016 7:38
>> > To: Steven D'Aprano
>> > Cc: Python-Dev
>> > Subject: Re: [Python-Dev] Adding NewType() to PEP 484
>> >
>> > Just to add to the list of options, Twitter also came up with
>> >
>> > - invention
>> >
>> > - DomainType
>> >
>> > - TypedAlias
>> >
>> > But seriously I think we should just decide between Derived Type and
>> > Distinguished Type [Alias].
>> >
>> > The latter comes from the idea that when you write e.g.
>> >
>> > UserId = int
>> >
>> > then UserId is a type alias (that's existing PEP 484 terminology) and
>> > the type checker doesn't distinguish it from int -- you can use it in
>> > places where you logically expect a UserId but to the type checker
>> > those variables have the type int.
>> >
>> > There is even a neat potential "origin story" that would explain why
>> > we'd call it Distinguished Type Alias.
>> >
>> > The story is about gradually converting a large code base to being
>> > consistent: initially you make UserId a regular type alias and you
>> > start putting it in your code incrementally, making sure it has no
>> > mypy errors as you go (but this just treats it as an int). After days,
>> > when you think you are done, you change UserId to a distinguished type
>> > alias and then mypy will point out the places where you've missed
>> > something or you're doing something questionable with user IDs.
>> >
>> > And yes, in the wider context of subclassing, Derived Type is probably
>> > confusing because a subclass is also called a derived class.
>> >
>> >
>> > On Sat, May 28, 2016 at 5:24 AM, Steven D'Aprano 
>> > wrote:
>> >> On Fri, May 27, 2016 at 09:26:29PM -0700, Guido van Rossum wrote:
>> >>
>> >>> We discussed this over dinner at PyCon, some ideas we came up with:
>> >>>
>> >>> - Dependent types, harking back to a similar concept in Ada
>> >>> (
>> https://en.wikibooks.org/wiki/Ada_Programming/Type_System#Derived_types)
>> >>> which in that language is also spelled with "new".
>> >>
>> >> I started to explain this to my non-programmer wife, I got as far as
>> >> explaining types, and that we need a name for this thing, and she
>> >> stopped me and said
>> >>
>> >> "Please don't tell me this is leading to TypyMcTypeCheck."
>> >>
>> >> [...]
>> >>> - BoatyMcBoatType
>> >>
>> >>> The nice thing about "distinguished" is that it's a relatively rare
>> >>> word so it is easy to remember or look up.
>> >>
>> >> I would have thought that being rare, it would be *harder* to remember.
>> >>
>> >>
>> >>> Personally I'm still in favor of Derived type (but I'm more into
>> >>> ancient programming languages than most folks here). I could also live
>> >>> with Distinguished Type.
>> >>
>> >> I think Derived Type is the nicest of the options. It accurately
>> >> describes what it is: a type derived from another. And its shorter and
>> >> easy to both say and write than "Distinguished type" (which sounds like
>> >> "distinguished gentlemen" -- is it wearing a monocle and a top hat?).
>> >>
>> >> "Distinguished" is too vague for my tastes, it might as well be
>> >> "flibblegubble type". *All* types are distinguished, the type checker
>> >> has to distinguish int from float from list from str, so to call
>> >> NewType("userid", int) a "distinguished type" is only to call it a
>> type.
>> >>
>> >>
>> >>
>> >> --
>> >> Steve
>> >> ___
>> >> Python-Dev mailing list
>> >> Python-Dev@python.org
>> >> https://mail.python.org/mailman/listinfo/python-dev
>> >> Unsubscribe:
>> >> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>> >
>> >
>> >
>> > --
>> > --Guido van Rossum (python.org/~guido)
>> > ___
>> > Python-Dev mailing list
>> > Python-Dev@python.org
>> > https://mail.python.org/mailman/listinfo/python-dev
>> > Unsubscribe:
>> >
>> https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> 

Re: [Python-Dev] Why does PEP 7/8 explicitly suggest 2 spaces after a period?

[Peter Ludemann via Python-Dev]

I just tried a re-flow in emacs (M-q or fill-paragraph) and it didn't
change my single space to two (it also changed 3 spaces after a period to
2; and it preserved my hanging indents). I have no idea what vim does.
(OTOH, emacs annoyingly adds a blank line to my """ docstrings, which I
remove manually.)

I'm not going to stoke the fires of debate (especially as I've worked with
typographers over the years and know that the typographical sins of
programmers go far beyond the double-space-after-period), except to note
that if you read the thousands of words that have been written about
spacing after periods, they're usually talking about *proportional* fonts;
and we still tend to use monospaced fonts with programming tools.


On 21 May 2016 at 00:44, Stephen J. Turnbull  wrote:

> Bernardo Sulzbach writes:
>  > > On 05/20/2016 09:27 AM, Brett Cannon wrote:
>  > >
>  > > The period is a full-stop punctuation mark, but visually obscure [1].
>  >
>  > It is small. This does not make it hard to notice, however.
>
> That depends on fonts, and on the ability of the user to write
> correctly as well.  "Syntax should not look like grit on Tim's screen"
> applies to natural language as well.  I read a lot of English-as-a-
> second-language text, and it really does help to have the extra space,
> because the period often appears where English grammar suggests it
> doesn't belong.  The extra effort to use the second space helps to
> emphasize the author's intent, and even subjectively make the period
> "more visible".
>
> But I agree with Guido.  No Python contributors write poorly, so the
> real issues are consistency with past practice (a minor consideration
> in the case of comments) and tooling (since both Emacs and vim seem to
> come out of the box believing in this rule, I guess it's widespread
> enough to care).
>
> As for Brett's concern about whether this should be specified at this
> level, I think tooling again is an answer.  Emacs reflows whole
> paragraphs.  That means that text that is off-screen may be changed
> according to this rule, and that is an annoyance when you only notice
> it while preparing a patch for submission.  I think a detail of style
> that triggers unwanted (but plausible[1]) behavior in a widely-used
> tool is worth standardizing.  Sometimes, of course, you standardize
> *despite* the tool, but then at least the tool-users know that a
> decision has been taken to impose the burden on them, vs. imposing the
> burden on people who prefer the other style.
>
> Footnotes:
> [1]  If the behavior is implausible, fix the tool, of course!
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/pludemann%40google.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding Type[C] to PEP 484

[Peter Ludemann via Python-Dev]

On 14 May 2016 at 13:28, Guido van Rossum <gvanros...@gmail.com> wrote:

> On Sat, May 14, 2016 at 11:47 AM, Peter Ludemann <pludem...@google.com>
> wrote:
>
>> I think that Type[C,D] would mean Union[Type[C], Type[D]], but I'm not
>> sure ... I should probably talk to a typing expert about this.
>> (Sorry for thinking out loud; but if we decide that Type[C,D] doesn't
>> make sense, we need to prohibit it)
>>
>
> It sounds iffy enough to prohibit.
>
>
>> I suppose I'm asking: do we allow new_user(Type[BasicUser, ProUser])?
>>
>
> That looks like a call, but Type[] is something to use in the definition.
>
>
>> Here's a trivial example that off the top of my head makes sense:
>>
>> BasicOrProUser = TypeVar('BasicOrProUser', BasicUser, ProUser)
>> def new_user(name: str, user_factory: Type[BasicOrProuser]) ->
>> BasicOrProUser:
>> return user_factory(name)
>>
>
> That looks reasonable and only has one parameter to Type[].
>

So, should we allow this (by analogy to TypeVar allowing multiple types):

​  ​
def new_user(name: str, user_factory: Type[BasicUser, ProUser]) ->
Union[BasicUser, ProUser]:

​  ​
  return user_factory(name)

?
​... ​
​or should it be:

​
def new_user(name: str,
​  ​
user_factory: Type[
​
Union[
BasicUser, ProUser
​]​
]) -> Union[BasicUser, ProUser]:
  return user_factory(name)
​
?

Although both of these lose the information that the output type is related
to the input type; and hopefully the verbosity would encourage people to
use TypeVar.

(From these examples, my preference is for Type to be limited to a single
choice and anything more complicated should be done with TypeVar, Union,
etc.)



>
>
>> Or must the Type[...] item have been defined with a TypeVar(...,
>> bound=...), in which case multiple types aren't allowed with Type[...]?
>>
>
> You can use whatever you want. If you want to write Type[int] go right
> ahead. Even Type[Union[int, str]] should be allowed. There is *usually* a
> good reason to use a type variable though -- without one the return type
> would be the base class. (But then again maybe that could be what you want,
> or you might not even have a return type, e.g. when the thing just gets
> thrown into the database.)
>
> --Guido
>
>
>>
>>
>> On 14 May 2016 at 11:30, Guido van Rossum <gvanros...@gmail.com> wrote:
>>
>>> What would Type[C, D] mean?
>>>
>>> --Guido (mobile)
>>> On May 14, 2016 11:21 AM, "Peter Ludemann via Python-Dev" <
>>> python-dev@python.org> wrote:
>>>
>>>> Is Type[C,D] allowed? Or should multiple types be restricted to
>>>> TypeVar?
>>>>
>>>> ___
>>>> Python-Dev mailing list
>>>> Python-Dev@python.org
>>>> https://mail.python.org/mailman/listinfo/python-dev
>>>> Unsubscribe:
>>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>>>
>>>>
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding Type[C] to PEP 484

[Peter Ludemann via Python-Dev]

I think that Type[C,D] would mean Union[Type[C], Type[D]], but I'm not sure
... I should probably talk to a typing expert about this.
(Sorry for thinking out loud; but if we decide that Type[C,D] doesn't make
sense, we need to prohibit it)

I suppose I'm asking: do we allow new_user(Type[BasicUser, ProUser])?

Here's a trivial example that off the top of my head makes sense:

BasicOrProUser = TypeVar('BasicOrProUser', BasicUser, ProUser)
def new_user(name: str, user_factory: Type[BasicOrProuser]) ->
BasicOrProUser:
return user_factory(name)

Or must the Type[...] item have been defined with a TypeVar(...,
bound=...), in which case multiple types aren't allowed with Type[...]?


On 14 May 2016 at 11:30, Guido van Rossum <gvanros...@gmail.com> wrote:

> What would Type[C, D] mean?
>
> --Guido (mobile)
> On May 14, 2016 11:21 AM, "Peter Ludemann via Python-Dev" <
> python-dev@python.org> wrote:
>
>> Is Type[C,D] allowed? Or should multiple types be restricted to TypeVar?
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding Type[C] to PEP 484

[Peter Ludemann via Python-Dev]

Is Type[C,D] allowed? Or should multiple types be restricted to TypeVar?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 updated on whether to break before or after a binary update

[Peter Ludemann via Python-Dev]

If Python ever adopts the BCPL rule for implicit line continuation if the
last thing on a line is an operator (or if there's an open parentheses),
then the break-after-an-operator rule would be more persuasive.
;)

[IIRC, the BCPL rule was that there was an implicit continuation if the
grammar would not allow inserting a semicolon at the end of the line, which
covered both the open-parens and last-item-is-operator cases, and probably
a few others.] But I should shut up and leave shut discussions to
python-ideas.


On 15 April 2016 at 13:48, Ian Lee  wrote:

> Cross posting the comment I’d left on the issue [1].
>
> > My preference is to actually break that logic up and avoid the wrapping
> in the first place, as in [2]. Which in this particular class has the side
> benefit of that value being used again in the same function anyways.
>
> > I'm starting to realize that Brandon Rhodes really had a big impact on
> my ideas of styling as I've been learning Python these past few years, as
> this was another one style I'm stealing from that same talk [3].
>
> [1] http://bugs.python.org/msg263509
> [2]
> https://github.com/python/peps/commit/0c790e7b721bd13ad12ab9e6f6206836f398f9c4
>
> ~ Ian Lee | ianlee1...@gmail.com
>
> On Apr 15, 2016, at 10:49, MRAB  wrote:
>
> On 2016-04-15 18:03, Victor Stinner wrote:
> > Hum.
> >
> >  if (width == 0
> >  and height == 0
> >  and color == 'red'
> >  and emphasis == 'strong'
> >  or highlight > 100):
> >  raise ValueError("sorry, you lose")
> >
> > Please remove one space to vertically align "and" operators with the
> > opening parenthesis:
> >
> >  if (width == 0
> > and height == 0
> > and color == 'red'
> > and emphasis == 'strong'
> > or highlight > 100):
> >  raise ValueError("sorry, you lose")
> >
> > (I'm not sure that the difference is obvious in a mail client, you
> > need a fixed width font which is not the case in my Gmail editor.)
> >
> > It helps to visually see that the multiline test and the raise
> > instruction are in two different blocks.
> >
> > (Moreover, the pep8 checks of OpenStack simply reject such syntax, but
> > I cannot use this syntax anymore :-))
> >
> I always half-indent continuation lines:
>
>if (width == 0
>  and height == 0
>  and color == 'red'
>  and emphasis == 'strong'
>  or highlight > 100):
>raise ValueError("sorry, you lose")
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/ianlee1521%40gmail.com
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/pludemann%40google.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Speeding up CPython 5-10%

[Peter Ludemann via Python-Dev]

Also, modern compiler technology tends to use "infinite register" machines
for the intermediate representation, then uses register coloring to assign
the actual registers (and generate spill code if needed). I've seen work on
inter-function optimization for avoiding some register loads and stores
(combined with tail-call optimization, it can turn recursive calls into
loops in the register machine).



On 2 February 2016 at 09:16, Sven R. Kunze  wrote:

> On 02.02.2016 00:27, Greg Ewing wrote:
>
>> Sven R. Kunze wrote:
>>
>>> Are there some resources on why register machines are considered faster
>>> than stack machines?
>>>
>>
>> If a register VM is faster, it's probably because each register
>> instruction does the work of about 2-3 stack instructions,
>> meaning less trips around the eval loop, so less unpredictable
>> branches and less pipeline flushes.
>>
>
> That's was I found so far as well.
>
> This assumes that bytecode dispatching is a substantial fraction
>> of the time taken to execute each instruction. For something
>> like cpython, where the operations carried out by the bytecodes
>> involve a substantial amount of work, this may not be true.
>>
>
> Interesting point indeed. It makes sense that register machines only saves
> us the bytecode dispatching.
>
> How much that is compared to the work each instruction requires, I cannot
> say. Maybe, Yury has a better understanding here.
>
> It also assumes the VM is executing the bytecodes directly. If
>> there is a JIT involved, it all gets translated into something
>> else anyway, and then it's more a matter of whether you find
>> it easier to design the JIT to deal with stack or register code.
>>
>
> It seems like Yury thinks so. He didn't tell use so far.
>
>
> Best,
> Sven
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/pludemann%40google.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] FAT Python (lack of) performance

[Peter Ludemann via Python-Dev]

About benchmarks ... I've been there and it's not benchmarks that decide
whether something succeeds or fails.
(I found this old discussion
 which
mentions FIB (also TAK ,
which is rather more brutal)  ... do you recognize the language that got an
implementation that was competitive with C in performance, was vastly more
expressive, yet failed to catch on?)

OTOH, good performance is never a bad thing and sometimes is a necessity;
so I applau this work.


On 28 January 2016 at 01:39, Nick Coghlan  wrote:

> On 28 January 2016 at 18:30, INADA Naoki  wrote:
> > Please stop.
> >
> > I'm sorry about messing up this thread.
>
> Not your fault at all! This is just a particular bugbear of mine,
> since software architecture design (including appropriate programming
> language selection) is an even more poorly understood discipline than
> software development in general :)
>
> > I just wanted to represent why I'm very interested in Victor's efforts.
>
> And thanks for posting that, as it is indeed cool that the
> optimisation efforts currently being discussed may result in
> performance improvements on some of the simplified micro-benchmarks
> popular in programming language shootouts.
>
> There's no way you could have anticipated the subsequent tangential
> discussion on motives for contributing to open source projects, and
> the impact that has on what we can reasonably expect from fellow
> contributors.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/pludemann%40google.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Peter Ludemann via Python-Dev]

On 18 January 2016 at 23:25, Alexander Walters 
wrote:

>
>
> On 1/19/2016 02:21, Larry Hastings wrote:
>
>
> On 01/18/2016 08:40 PM, Alexander Walters wrote:
>
> I am not a core developer, but I just kind of feel its hypocritical to
> oppose always using brackets for the development of *python*
>
>
> CPython isn't written in Python, it's written in C.  So we use C idioms,
> which naturally are different from Python idioms.
>
>
> Yes, and always using brackets is an accepted C idiom (one of two, the
> other being only use brackets when you must).  Always using them is  more
> in line with the spirit of python.
>

​And in the spirit of safety, which I think is Brett's concern.
Yes, there are tools that could catch the Apple bug
, by catching
incorrect indentation. But if the rule is to *always* use braces, that just
feels safer. Even if it offends some people's ability to read everything at
one glance (my suggestion: use a smaller font or a larger screen; or
refactor the code so it isn't as big a chunk).

There's a fairly exhaustive list of styles here:
https://en.wikipedia.org/wiki/Indent_style
I'm sure that some of these have not been advocated in this thread.​



>
> */arry*
>
>
> ___
> Python-Dev mailing 
> listPython-Dev@python.orghttps://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/tritium-list%40sdamon.com
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/pludemann%40google.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] type(obj) vs. obj.__class__

[Peter Ludemann via Python-Dev]

I re-coded the "too clever by half" RingBuffer to use the same design but
with delegation ... and it ran 50% slower. (Code available on request)
Then I changed it to switch implementations of append() and get() when it
got full (the code is below) and it ran at essentially the same speed as
the original. So, there's no need to be so clever with __class__. Of
course, this trick of replacing a method is also "too clever by half"; but
an instance variable for "full" slows it down by 15%.

class RingBuffer(object):
def __init__(self, size_max):
self.max = size_max
self.data = []
self.cur = 0
def append(self, x):
self.data.append(x)
if len(self.data) == self.max:
self.append = self.append_full
def append_full(self, x):
self.data[self.cur] = x
self.cur = (self.cur + 1) % self.max
def get(self):
return self.data[self.cur:] + self.data[:self.cur]



On 18 October 2015 at 08:45, David Mertz  wrote:

> This recipe looks like a bad design to me to start with.  It's
> too-clever-by-half, IMO.
>
> If I were to implement RingBuffer, I wouldn't futz around with the
> __class__ attribute to change it into another thing when it was full.  A
> much more obvious API for users would be simply to implement a
> RingBuffer.isfull() method, perhaps supported by an underlying
> RingBuffer._full boolean attribute.  That's much friendlier than expecting
> people to introspect the type of the thing for a question that only
> occasionally matters; and when it does matter, the question is always
> conceived exactly as "Is it full?" not "What class is this currently?"
>
> So I think I'm still waiting for a compelling example where type(x) !=
> x.__class__ would be worthwhile (yes, of course it's *possible*)
>
> On Sat, Oct 17, 2015 at 10:55 PM, Steven D'Aprano 
> wrote:
>
>> On Sat, Oct 17, 2015 at 03:45:19PM -0600, Eric Snow wrote:
>> > In a recent tracker issue about OrderedDict [1] we've had some
>> > discussion about the use of type(od) as a replacement for
>> > od.__class__.
>> [...]
>> > The more general question of when we use type(obj) vs. obj.__class__
>> > applies to both the language and to all the stdlib as I expect
>> > consistency there would result in fewer surprises.  I realize that
>> > there are some places where using obj.__class__ makes more sense (e.g.
>> > for some proxy support).  There are other places where using type(obj)
>> > is the way to go (e.g. special method lookup).  However, the
>> > difference is muddled enough that usage is inconsistent in the stdlib.
>> > For example, C-implemented types use Py_TYPE() almost exclusively.
>> >
>> > So, would it make sense to establish some concrete guidelines about
>> > when to use type(obj) vs. obj.__class__?  If so, what would those be?
>> > It may also be helpful to enumerate use cases for "type(obj) is not
>> > obj.__class__".
>>
>> I for one would like to see a definitive explanation for when they are
>> different, and when you should use one or the other. The only
>> obvious example I've seen is the RingBuffer from the Python Cookbook:
>>
>> http://code.activestate.com/recipes/68429-ring-buffer/
>>
>>
>>
>> --
>> Steve
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>>
>
>
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/pludemann%40google.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] type(obj) vs. obj.__class__

[Peter Ludemann via Python-Dev]

On 18 October 2015 at 17:41, Chris Angelico  wrote:

> On Mon, Oct 19, 2015 at 11:35 AM, David Mertz  wrote:
> > That's interesting about the `self._full` variable slowing it down, I
> think
> > I'm not surprised (but obviously it depends on just how it's used).  But
> one
> > can also simply define RingBuffer.isfull() using
> `self.max==len(self.data)`
> > if you prefer that approach.  I doubt `myringbuffer.isfull()` is
> something
> > you need to call in an inner loop.
> >
> > That said, I think my implementation of RingBuffer would probably look
> more
> > like (completely untested):
> >
> > class RingBuffer(object):
> > def __init__(self, size_max):
> > self.data = [None] * size_max
> > self.size_max = size_max
> > self.used = 0
> > self.cur = 0
> > def append(self, val):
> > self.data[self.cur] = val
> > self.cur = (self.cur+1) % self.size_max
> > self.used = max(self.used, self.cur+1)
> > def isfull(self):
> > self.used == self.size_max
> >
> > Feel free to try this version against whatever benchmark you have in
> mind.
>
> What does this provide that collections.deque(maxlen=size_max)
> doesn't? I'm a little lost.
>

​I was merely re-implementing the "clever" code in a slightly less clever
way, for the same performance, to demonstrate that there's no need to
assign to __class__.

collections.deque is about 5x faster.
(My simple benchmark tests the cost of x.append(i))

- p​



>
> ChrisA
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/pludemann%40google.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498 PEP-501: Literal String Formatting/Interpolation

[Peter Ludemann via Python-Dev]

How is this proposal of di... more than a different spelling of lambda
i...? (I think it's a great idea — but am wondering if there are some
extra semantics that I missed)

I don't think there's any need to preserve the values of the {...} (or
${...}) constituents — the normal closure mechanism should do fine because
logging is more-or-less like this:
   if conditions for logging:
 if callable(msg):
   log_msg = msg(*args)
 else:
   log_msg = msg % args
and so there's no need to preserve the values at the moment the
interpolated string is created.

Perl allows arbitrary expressions inside interpolations, but that tends to
get messy and is self-limiting for complex expressions; however, it's handy
for things like:
   print(The {i+1}th item is strange: {x[i]})


On 16 August 2015 at 13:04, Gregory P. Smith g...@krypto.org wrote:



 On Sun, Aug 9, 2015 at 3:25 PM Brett Cannon br...@python.org wrote:


 On Sun, Aug 9, 2015, 13:51 Peter Ludemann via Python-Dev 
 python-dev@python.org wrote:

 Most of my outputs are log messages, so this proposal won't help me
 because (I presume) it does eager evaluation of the format string and the
 logging methods are designed to do lazy evaluation. Python doesn't have
 anything like Lisp's special forms, so there doesn't seem to be a way to
 implicitly put a lambda on the string to delay evaluation.

 It would be nice to be able to mark the formatting as lazy ... maybe
 another string prefix character to indicate that? (And would the 2nd
 expression in an assert statement be lazy or eager?)


 That would require a lazy string type which is beyond the scope of this
 PEP as proposed since it would require its own design choices, how much
 code would not like the different type, etc.

 -Brett


 Agreed that doesn't belong in PEP 498 or 501 itself... But it is a real
 need.

 We left logging behind when we added str.format() and adding yet another
 _third_ way to do string formatting without addressing the needs of
 deferred-formatting for things like logging is annoying.

 brainstorm: Imagine a deferred interpolation string with a d'' prefix..
  di'foo ${bar}' would be a new type with a __str__ method that also retains
 a runtime reference to the necessary values from the scope within which it
 was created that will be used for substitutions when iff/when it is
 __str__()ed.  I still wouldn't enjoy reminding people to use di''
 inlogging.info(di'thing happened: ${result}') all the time any more than
 I like reminding people to undo their use of % and just pass the values as
 additional args to the logging call... But I think people would find it
 friendlier and thus be more likely to get it right on their own.  logging's
 manually deferred % is an idiom i'd like to see wither away.

 There's also a performance aspect to any new formatter, % is oddly pretty
 fast, str.format isn't. So long as you can do stuff at compile time rather
 than runtime I think these PEPs could be even faster. Constant string
 pep-498 or pep-501 formatting could be broken down at compile time and
 composed into the optimal set of operations to build the resulting string /
 call the formatter.

 So far looking over both peps, I lean towards pep-501 rather than 498:

 I really prefer the ${} syntax.
 I don't like arbitrary logical expressions within strings.
 I dislike str only things without a similar concept for bytes.

 but neither quite suits me yet.

 501's __interpolate*__ builtins are good and bad at the same time.  doing
 this at the module level does seem right, i like the i18n use aspect of
 that, but you could also imagine these being methods so that subclasses
 could override the behavior on a per-type basis.  but that probably only
 makes sense if a deferred type is created due to when and how interpolates
 would be called.  also, adding builtins, even __ones__ annoys me for some
 reason I can't quite put my finger on.

 (jumping into the threads way late)
 -gps


 PS: As to Brett's comment about the history of string interpolation ...
 my recollection/understanding is that it started with Unix shells and the
 $variable notation, with the $variable being evaluated within ... and
 not within '...'. Perl, PHP, Make (and others) picked this up. There seems
 to be a trend to avoid the bare $variable form and instead use
 ${variable} everywhere, mainly because ${...} is sometimes required to
 avoid ambiguities (e.g. There were $NUMBER ${THING}s.)

 PPS: For anyone wishing to improve the existing format options, Common
 Lisp's FORMAT http://www.gigamonkeys.com/book/a-few-format-recipes.html
 and Prolog's format/2
 https://quintus.sics.se/isl/quintus/html/quintus/mpg-ref-format.html
 have some capabilities that I miss from time to time in Python.

 On 9 August 2015 at 11:22, Eric V. Smith e...@trueblade.com wrote:

 On 8/9/2015 1:38 PM, Brett Cannon wrote:
 
 
  On Sun, 9 Aug 2015 at 01:07 Stefan Behnel stefan...@behnel.de

  mailto:stefan...@behnel.de wrote:
 
  Eric V. Smith

Re: [Python-Dev] PEP-498: Literal String Formatting

[Peter Ludemann via Python-Dev]

Most of my outputs are log messages, so this proposal won't help me because
(I presume) it does eager evaluation of the format string and the logging
methods are designed to do lazy evaluation. Python doesn't have anything
like Lisp's special forms, so there doesn't seem to be a way to
implicitly put a lambda on the string to delay evaluation.

It would be nice to be able to mark the formatting as lazy ... maybe
another string prefix character to indicate that? (And would the 2nd
expression in an assert statement be lazy or eager?)

PS: As to Brett's comment about the history of string interpolation ... my
recollection/understanding is that it started with Unix shells and the
$variable notation, with the $variable being evaluated within ... and
not within '...'. Perl, PHP, Make (and others) picked this up. There seems
to be a trend to avoid the bare $variable form and instead use
${variable} everywhere, mainly because ${...} is sometimes required to
avoid ambiguities (e.g. There were $NUMBER ${THING}s.)

PPS: For anyone wishing to improve the existing format options, Common
Lisp's FORMAT http://www.gigamonkeys.com/book/a-few-format-recipes.html
and Prolog's format/2
https://quintus.sics.se/isl/quintus/html/quintus/mpg-ref-format.html have
some capabilities that I miss from time to time in Python.

On 9 August 2015 at 11:22, Eric V. Smith e...@trueblade.com wrote:

 On 8/9/2015 1:38 PM, Brett Cannon wrote:
 
 
  On Sun, 9 Aug 2015 at 01:07 Stefan Behnel stefan...@behnel.de
  mailto:stefan...@behnel.de wrote:
 
  Eric V. Smith schrieb am 08.08.2015 um 03:39:
   Following a long discussion on python-ideas, I've posted my draft
 of
   PEP-498. It describes the f-string approach that was the subject
 of
   the Briefer string format thread. I'm open to a better title than
   Literal String Formatting.
  
   I need to add some text to the discussion section, but I think
 it's in
   reasonable shape. I have a fully working implementation that I'll
 get
   around to posting somewhere this weekend.
  
def how_awesome(): return 'very'
   ...
f'f-strings are {how_awesome()} awesome!'
   'f-strings are very awesome!'
  
   I'm open to any suggestions to improve the PEP. Thanks for your
  feedback.
 
  [copying my comment from python-ideas here]
 
  How common is this use case, really? Almost all of the string
 formatting
  that I've used lately is either for logging (no help from this
 proposal
  here) or requires some kind of translation/i18n *before* the
 formatting,
  which is not helped by this proposal either. Meaning, in almost all
  cases,
  the formatting will use some more or less simple variant of this
  pattern:
 
  result = process(string with {a} and {b}).format(a=1, b=2)
 
  which commonly collapses into
 
  result = translate(string with {a} and {b}, a=1, b=2)
 
  by wrapping the concrete use cases in appropriate helper functions.
 
  I've seen Nick Coghlan's proposal for an implementation backed by a
  global
  function, which would at least catch some of these use cases. But it
  otherwise seems to me that this is a huge sledge hammer solution for
 a
  niche problem.
 
 
  So in my case the vast majority of calls to str.format could be replaced
  with an f-string. I would also like to believe that other languages that
  have adopted this approach to string interpolation did so with knowledge
  that it would be worth it (but then again I don't really know how other
  languages are developed so this might just be a hope that other
  languages fret as much as we do about stuff).

 I think it has to do with the nature of the programs that people write.
 I write software for internal use in a large company. In the last 13
 years there, I've written literally hundreds of individual programs,
 large and small. I just checked: literally 100% of my calls to
 %-formatting (older code) or str.format (in newer code) could be
 replaced with f-strings. And I think every such use would be an
 improvement.

 I firmly believe that the majority of software written in Python does
 not show up on PyPi, but is used internally in corporations. It's not
 internationalized or localized: it just exists to get a job done
 quickly. This is the code that would benefit from f-strings.

 This isn't to say that there's not plenty of code where f-strings would
 not help. But I think it's as big a mistake to generalize from my
 experience as it is from Stefan's.

 Eric.

 ___
 Python-Dev mailing list
 Python-Dev@python.org
 https://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
 https://mail.python.org/mailman/options/python-dev/pludemann%40google.com

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 

Re: [Python-Dev] PEP-498: Literal String Formatting

[Peter Ludemann via Python-Dev]

What if logging understood lambda? (By testing for types.FunctionType).
This is outside PEP 498, but there might be some recommendations on how
lazy evaluation should be done and understood by some functions.

e.g.:
log.info(lambda: f'{foo} just did a {bar} thing')

It's not pretty, but it's not too verbose. As far as I can tell, PEP 498
would work with this because it implicitly supports closures — that is,
it's defined as equivalent to
log.info(lambda: ''.join([foo.__format__(), ' just did a ',
bar.__format__(), ' thing']))


On 9 August 2015 at 15:25, Brett Cannon br...@python.org wrote:


 On Sun, Aug 9, 2015, 13:51 Peter Ludemann via Python-Dev 
 python-dev@python.org wrote:

 Most of my outputs are log messages, so this proposal won't help me
 because (I presume) it does eager evaluation of the format string and the
 logging methods are designed to do lazy evaluation. Python doesn't have
 anything like Lisp's special forms, so there doesn't seem to be a way to
 implicitly put a lambda on the string to delay evaluation.

 It would be nice to be able to mark the formatting as lazy ... maybe
 another string prefix character to indicate that? (And would the 2nd
 expression in an assert statement be lazy or eager?)


 That would require a lazy string type which is beyond the scope of this
 PEP as proposed since it would require its own design choices, how much
 code would not like the different type, etc.

 -Brett


 PS: As to Brett's comment about the history of string interpolation ... my
 recollection/understanding is that it started with Unix shells and the
 $variable notation, with the $variable being evaluated within ... and
 not within '...'. Perl, PHP, Make (and others) picked this up. There seems
 to be a trend to avoid the bare $variable form and instead use
 ${variable} everywhere, mainly because ${...} is sometimes required to
 avoid ambiguities (e.g. There were $NUMBER ${THING}s.)

 PPS: For anyone wishing to improve the existing format options, Common
 Lisp's FORMAT http://www.gigamonkeys.com/book/a-few-format-recipes.html
 and Prolog's format/2
 https://quintus.sics.se/isl/quintus/html/quintus/mpg-ref-format.html
 have some capabilities that I miss from time to time in Python.

 On 9 August 2015 at 11:22, Eric V. Smith e...@trueblade.com wrote:

 On 8/9/2015 1:38 PM, Brett Cannon wrote:
 
 
  On Sun, 9 Aug 2015 at 01:07 Stefan Behnel stefan...@behnel.de

  mailto:stefan...@behnel.de wrote:
 
  Eric V. Smith schrieb am 08.08.2015 um 03:39:
   Following a long discussion on python-ideas, I've posted my draft
 of
   PEP-498. It describes the f-string approach that was the subject
 of
   the Briefer string format thread. I'm open to a better title than
   Literal String Formatting.
  
   I need to add some text to the discussion section, but I think
 it's in
   reasonable shape. I have a fully working implementation that I'll
 get
   around to posting somewhere this weekend.
  
def how_awesome(): return 'very'
   ...
f'f-strings are {how_awesome()} awesome!'
   'f-strings are very awesome!'
  
   I'm open to any suggestions to improve the PEP. Thanks for your
  feedback.
 
  [copying my comment from python-ideas here]
 
  How common is this use case, really? Almost all of the string
 formatting
  that I've used lately is either for logging (no help from this
 proposal
  here) or requires some kind of translation/i18n *before* the
 formatting,
  which is not helped by this proposal either. Meaning, in almost all
  cases,
  the formatting will use some more or less simple variant of this
  pattern:
 
  result = process(string with {a} and {b}).format(a=1, b=2)
 
  which commonly collapses into
 
  result = translate(string with {a} and {b}, a=1, b=2)
 
  by wrapping the concrete use cases in appropriate helper functions.
 
  I've seen Nick Coghlan's proposal for an implementation backed by a
  global
  function, which would at least catch some of these use cases. But it
  otherwise seems to me that this is a huge sledge hammer solution for
 a
  niche problem.
 
 
  So in my case the vast majority of calls to str.format could be replaced
  with an f-string. I would also like to believe that other languages that
  have adopted this approach to string interpolation did so with knowledge
  that it would be worth it (but then again I don't really know how other
  languages are developed so this might just be a hope that other
  languages fret as much as we do about stuff).

 I think it has to do with the nature of the programs that people write.
 I write software for internal use in a large company. In the last 13
 years there, I've written literally hundreds of individual programs,
 large and small. I just checked: literally 100% of my calls to
 %-formatting (older code) or str.format (in newer code) could be
 replaced with f-strings. And I think

Re: [Python-Dev] Enable access to the AST for Python code

[Peter Ludemann via Python-Dev]

On 21 May 2015 at 17:12, Ethan Furman et...@stoneleaf.us wrote:

 On 05/21/2015 04:33 PM, Greg Ewing wrote:

 Steve Dower wrote:


 It's only a macro system when you generate code in unexpected/unobvious
 places with it. This is more like inspect.getsource(), but going straight
 to the AST.


 Is it really that much different? The end result is
 the same -- the user writes something that looks like
 a Python expression, but it gets evaluated using some
 other set of semantics that can be arbitrarily different
 from Python's.


 I think the key difference is that the AST is not going to be converted to
 run different Python code under Python, but under some other language --
 presumably to implement the semantics of the Python snippet.


As a simple example, a macro with access to the AST could decide to not
evaluate something, whereas normal Python rules would be to evaluate
(similar to wrapping with LISP QUOTE or LAMBDA). This would make PEP484
simpler (e.g., no need for special handling of forward references to
types).



 --
 ~Ethan~

 ___
 Python-Dev mailing list
 Python-Dev@python.org
 https://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
 https://mail.python.org/mailman/options/python-dev/pludemann%40google.com

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com