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

[Steve Dower]

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.

Cheers,
Steve

Top-posted from my Windows Phone

From: Greg Ewing
Sent: ‎5/‎20/‎2015 22:33
To: Python-Dev
Subject: Re: [Python-Dev] Enable access to the AST for Python code

Guido van Rossum wrote:
> Hey Ben, this is probably a better topic for python-ideas. I'll warn you
> that a hurdle for ideas like this is that ideally you don't want to
> support this just for CPython. It's definitely cool though!

This would effectively be a macro system. I thought
your position on macros was that they're uncool?

If you've changed your mind about this, that's cool
too -- just checking.

--
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/steve.dower%40microsoft.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] Enable access to the AST for Python code

[Ben Hoyt]

Thanks. Good point about python-ideas -- I was thinking that after I sent
it too. I'll repost there soon.

Out of interest, what specifically were you referring to as "definitely
cool" here: LINQ-style generator expressions that build SQL ala PonyORM, or
the more general feature of enabling AST access?

-Ben

On Wed, May 20, 2015 at 10:31 PM, Guido van Rossum  wrote:

> Hey Ben, this is probably a better topic for python-ideas. I'll warn you
> that a hurdle for ideas like this is that ideally you don't want to support
> this just for CPython. It's definitely cool though! (Using movie poster
> style quotes you can turn this into a ringing endorsement: "definitely
> cool" -- The BDFL. :-)
>
> On Wed, May 20, 2015 at 7:26 PM, Ben Hoyt  wrote:
>
>> Hi Python devs,
>>
>> Enabling access to the AST for compiled code would make some cool
>> things possible (C# LINQ-style ORMs, for example), and not knowing too
>> much about this part of Python internals, I'm wondering how possible
>> and practical this would be.
>>
>> Context: PonyORM (http://ponyorm.com/) allows you to write regular
>> Python generator expressions like this:
>>
>> select(c for c in Customer if sum(c.orders.price) > 1000)
>>
>> which compile into and run SQL like this:
>>
>> SELECT "c"."id"
>> FROM "Customer" "c"
>> LEFT JOIN "Order" "order-1" ON "c"."id" = "order-1"."customer"
>> GROUP BY "c"."id"
>> HAVING coalesce(SUM("order-1"."total_price"), 0) > 1000
>>
>> I think the Pythonic syntax here is beautiful. But the tricks PonyORM
>> has to go to get it are ... not quite so beautiful. Because the AST is
>> not available, PonyORM decompiles Python bytecode into an AST first,
>> and then converts that to SQL. (More details on all that from author's
>> EuroPython talk at http://pyvideo.org/video/2968)
>>
>> I believe PonyORM needs the AST just for generator expressions and
>> lambda functions, but obviously if this kind of AST access feature
>> were in Python it'd probably be more general.
>>
>> I believe C#'s LINQ provides something similar, where if you're
>> developing a LINQ converter library (say LINQ to SQL), you essentially
>> get the AST of the code ("expression tree") and the library can do
>> what it wants with that.
>>
>> What would it take to enable this kind of AST access in Python? Is it
>> possible? Is it a good idea?
>>
>> -Ben
>> ___
>> 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

[Python-Dev] segfaults due to hash randomization in C OrderedDict

[Eric Snow]

(see http://bugs.python.org/issue16991)

I an working on resolving an intermittent segfault that my C
OrderedDict patch introduces.  The failure happens in
test_configparser (RawConfigParser uses OrderedDict internally), but
only sporadically.  However, Ned pointed out to me that it appears to
be related to hash randomization, which I have verified.  I'm looking
into it.

In the meantime, here's a specific question.  What would lead to the
pattern of failures I'm seeing?  I've verified that the segfault
happens consistently for certain hash randomization seeds and never
for the rest.  I don't immediately recognize the pattern but expect
that it would shed some light on where the problem lies.  I ran the
following command with the OrderedDict patch applied:

  for i in `seq 1 100`; do echo $i; PYTHONHASHSEED=$i ./python -m
test.regrtest -m test_basic test_configparser ; done

Through 100 I get segfaults with seeds of 7, 15, 35, 37, 39, 40, 42,
47, 50, 66, 67, 85, 87, 88, and 92.  I expect the distribution across
all seeds is uniform, but I haven't verified that.

Thoughts?

-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/archive%40mail-archive.com

Re: [Python-Dev] Status of PEP 484 and the typing module

[Guido van Rossum]

Hi Mark,

We're down to the last few items here. I'm CC'ing python-dev so folks can
see how close we are. I'll answer point by point.

On Thu, May 21, 2015 at 6:24 AM, Mark Shannon  wrote:

> Hi,
>
> The PEP itself is looking fairly good.
>

I hope you'll accept it at least provisionally so we can iterate over the
finer points while a prototype of typing.py in in beta 1.


> However, I don't think that typing.py is ready yet, for a number of
> reasons:
>
> 1.
> As I've said before, there needs to be a distinction between classes and
> types.
> They is no need for Any, Generic, Generic's subtypes, or Union to subclass
> builtins.type.
>

I strongly disagree. They can appear in many positions where real classes
are acceptable, in particular annotations can have classes (e.g. int) or
types (e.g. Union[int, str]).


> Playing around with typing.py, it has also become clear to me that it
> is also important to distinguish type constructors from types.
>
> What do I mean by a type constructor?
> A type constructor makes types.
> "List" is an example of a type constructor. It constructs types such as
> List[T] and List[int].
> Saying that something is a List (as opposed to a list) should be rejected.
>

The PEP actually says that plain List (etc.) is equivalent to List[Any].
(Well, at least that's the intention; it's implied by the section about the
equivalence between Node() and Node[Any]().


> 2.
> Usability of typing as it stands:
>
> Let's try to make a class that implements a mutable mapping.
>
> >>> import typing as tp
> #Make some variables.
> >>> T = tp.TypeVar('T')
> >>> K = tp.TypeVar('K')
> >>> V = tp.TypeVar('V')
>
> #Then make our class:
>
> >>> class MM(tp.MutableMapping): pass
> ...
> #Oh that worked, but it shouldn't. MutableMapping is a type constructor.
>

It means MutableMapping[Any].


> #Let's make one
> >>> MM()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/home/mark/repositories/typehinting/prototyping/typing.py", line
> 1095, in __new__
> if _gorg(c) is Generic:
>   File "/home/mark/repositories/typehinting/prototyping/typing.py", line
> 887, in _gorg
> while a.__origin__ is not None:
> AttributeError: type object 'Sized' has no attribute '__origin__'
>
> # ???
>

Sorry, that's a bug I introduced in literally the last change to typing.py.
I will fix it. The expected behavior is

TypeError: Can't instantiate abstract class MM with abstract methods __len__



> #Well let's try using type variables.
> class MM2(tp.MutableMapping[K, V]): pass
> ...
> >>> MM2()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/home/mark/repositories/typehinting/prototyping/typing.py", line
> 1095, in __new__
> if _gorg(c) is Generic:
>   File "/home/mark/repositories/typehinting/prototyping/typing.py", line
> 887, in _gorg
> while a.__origin__ is not None:
> AttributeError: type object 'Sized' has no attribute '__origin__'
>

Ditto, and sorry.

>
> At this point, we have to resort to using 'Dict', which forces us to
> subclass 'dict' which may not be what we want as it may cause metaclass
> conflicts.
>
> 3.
> Memory consumption is also a worry. There is no caching, which means every
> time I use "List[int]" as an annotation, a new class object is created.
> Each class may only be a few KB, but collectively this could easily add up
> to several MBs.
> This should be easy to fix.
>

I can work on this after the beta-1 release. Until then, type aliases can
be used to avoid redundant type creation (and often they are clearer anyway
:-).


> 4.
> PY2, etc. really need to go.
> Assuming that this code type checks OK:
>
>  if typing.PY2:
>  type_safe_under_py2_only()
>  else:
>  type_safe_under_py3_only()
>
> Is the checker supposed to pass this:
>
>  if sys.hexversion < 0x0300:
>  type_safe_under_py2_only()
>  else:
>  type_safe_under_py3_only()
>
> If it should pass, then why have PY2, etc. at all.
> If it should fail, well that is just stupid and annoying.
>
> Pylint already understands version checks, as does our (Semmle's) checker.
> I suspect most IDEs do as well.
>

I have to negotiate this with Jukka but I think he'll agree.


> 5.
> Removing isinstance() support:
>
> As I said before, this is the job of a checker not typing.py.
>
> It also introduces some strange situations:
> D = tp.Dict[str,int]
> d = {}
> assert isinstance(d, D)
> d["x"] = None
> assert isinstance(d, D)
>
> In the above case the first check passes, and the second fails.
> But d is either of type D or it isn't. It can't be both, as types
> are static properties of programs, unlike classes.
>

Well, isinstance() is a dynamic function. The type checker has no authority
over its behavior beyond its signature.


> And it's broken anyway:
> >>> D = tp.Dict[str,'D']
> >>> d = {"x": {}}
> >>> isinstance(d, D)
> False
>

That's because _ForwardRef doesn't implement __instancheck__ or
__subclasscheck__. It's easily fixed.

>
> Realistically, I don't see typing.py

Re: [Python-Dev] Status of PEP 484 and the typing module

[Mark Shannon]

On 21/05/15 16:01, Guido van Rossum wrote:

Hi Mark,

We're down to the last few items here. I'm CC'ing python-dev so folks
can see how close we are. I'll answer point by point.

On Thu, May 21, 2015 at 6:24 AM, Mark Shannon mailto:m...@hotpy.org>> wrote:

Hi,

The PEP itself is looking fairly good.


I hope you'll accept it at least provisionally so we can iterate over
the finer points while a prototype of typing.py in in beta 1.

However, I don't think that typing.py is ready yet, for a number of
reasons:

1.
As I've said before, there needs to be a distinction between classes
and types.
They is no need for Any, Generic, Generic's subtypes, or Union to
subclass builtins.type.


I strongly disagree. They can appear in many positions where real
classes are acceptable, in particular annotations can have classes (e.g.
int) or types (e.g. Union[int, str]).


Why does this mean that they have to be classes? Annotations can be any 
object.


It might to help to think, not in terms of types being classes, but 
classes being shorthand for the nominal type for that class (from the 
point of view of the checker and type geeks)

So when the checker sees 'int' it treats it as Type(int).

Subtyping is distinct from subclassing;
Type(int) <: Union[Type(int), Type(str)]
has no parallel in subclassing.
There is no class that corresponds to a Union, Any or a Generic.

In order to support the
class C(ParameterType[T]): pass
syntax, parametric types do indeed need to be classes, but Python has 
multiple inheritance, so thats not a problem:

class ParameterType(type, Type): ...
Otherwise typing.Types shouldn't be builtin.types and vice versa.

I think a lot of this issues on the tracker would not have been issues 
had the distinction been more clearly enforced.




Playing around with typing.py, it has also become clear to me that it
is also important to distinguish type constructors from types.

What do I mean by a type constructor?
A type constructor makes types.
"List" is an example of a type constructor. It constructs types such
as List[T] and List[int].
Saying that something is a List (as opposed to a list) should be
rejected.


The PEP actually says that plain List (etc.) is equivalent to List[Any].
(Well, at least that's the intention; it's implied by the section about
the equivalence between Node() and Node[Any]().


Perhaps we should change that. Using 'List', rather than 'list' or 
'List[Any]' suggests an error, or misunderstanding, to me.


Is there a use case where 'List' is needed, and 'list' will not suffice?
I'm assuming that the type checker knows that 'list' is a MutableSequence.



2.
Usability of typing as it stands:

Let's try to make a class that implements a mutable mapping.

 >>> import typing as tp
#Make some variables.
 >>> T = tp.TypeVar('T')
 >>> K = tp.TypeVar('K')
 >>> V = tp.TypeVar('V')

#Then make our class:

 >>> class MM(tp.MutableMapping): pass
...
#Oh that worked, but it shouldn't. MutableMapping is a type constructor.


It means MutableMapping[Any].

#Let's make one
 >>> MM()
Traceback (most recent call last):
   File "", line 1, in 
   File "/home/mark/repositories/typehinting/prototyping/typing.py",
line 1095, in __new__
 if _gorg(c) is Generic:
   File "/home/mark/repositories/typehinting/prototyping/typing.py",
line 887, in _gorg
 while a.__origin__ is not None:
AttributeError: type object 'Sized' has no attribute '__origin__'

# ???


Sorry, that's a bug I introduced in literally the last change to
typing.py. I will fix it. The expected behavior is

TypeError: Can't instantiate abstract class MM with abstract methods __len__

#Well let's try using type variables.
class MM2(tp.MutableMapping[K, V]): pass
...
 >>> MM2()
Traceback (most recent call last):
   File "", line 1, in 
   File "/home/mark/repositories/typehinting/prototyping/typing.py",
line 1095, in __new__
 if _gorg(c) is Generic:
   File "/home/mark/repositories/typehinting/prototyping/typing.py",
line 887, in _gorg
 while a.__origin__ is not None:
AttributeError: type object 'Sized' has no attribute '__origin__'


Ditto, and sorry.
No need to apologise, I'm just a bit worried about how easy it was for 
me to expose this sort of bug.





At this point, we have to resort to using 'Dict', which forces us to
subclass 'dict' which may not be what we want as it may cause
metaclass conflicts.

3.
Memory consumption is also a worry. There is no caching, which means
every time I use "List[int]" as an annotation, a new class object is
created. Each class may only be a few KB, but collectively this
could easily add up to several MBs.
This should be easy to fix.


I can work on this after the beta-1 release. Until then, type aliases
can be used to avoid redundant type

Re: [Python-Dev] segfaults due to hash randomization in C OrderedDict

[MRAB]

On 2015-05-21 15:55, Eric Snow wrote:

(see http://bugs.python.org/issue16991)

I an working on resolving an intermittent segfault that my C
OrderedDict patch introduces.  The failure happens in
test_configparser (RawConfigParser uses OrderedDict internally), but
only sporadically.  However, Ned pointed out to me that it appears to
be related to hash randomization, which I have verified.  I'm looking
into it.

In the meantime, here's a specific question.  What would lead to the
pattern of failures I'm seeing?  I've verified that the segfault
happens consistently for certain hash randomization seeds and never
for the rest.  I don't immediately recognize the pattern but expect
that it would shed some light on where the problem lies.  I ran the
following command with the OrderedDict patch applied:

   for i in `seq 1 100`; do echo $i; PYTHONHASHSEED=$i ./python -m
test.regrtest -m test_basic test_configparser ; done

Through 100 I get segfaults with seeds of 7, 15, 35, 37, 39, 40, 42,
47, 50, 66, 67, 85, 87, 88, and 92.  I expect the distribution across
all seeds is uniform, but I haven't verified that.

Thoughts?


In "_odict_get_index", for example (there are others), you're caching
"ma_keys":

PyDictKeysObject *keys = ((PyDictObject *)od)->ma_keys;

If it resizes, you go back to the label "start", which is after that
line, but could "ma_keys" change when it's resized?

___
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] Enable access to the AST for Python code

[Guido van Rossum]

Dang it. :-) I just want to encourage you to continue pursuing this idea,
one way or another.

On Thu, May 21, 2015 at 7:01 AM, Ben Hoyt  wrote:

> Thanks. Good point about python-ideas -- I was thinking that after I sent
> it too. I'll repost there soon.
>
> Out of interest, what specifically were you referring to as "definitely
> cool" here: LINQ-style generator expressions that build SQL ala PonyORM, or
> the more general feature of enabling AST access?
>
> -Ben
>
> On Wed, May 20, 2015 at 10:31 PM, Guido van Rossum 
> wrote:
>
>> Hey Ben, this is probably a better topic for python-ideas. I'll warn you
>> that a hurdle for ideas like this is that ideally you don't want to support
>> this just for CPython. It's definitely cool though! (Using movie poster
>> style quotes you can turn this into a ringing endorsement: "definitely
>> cool" -- The BDFL. :-)
>>
>> On Wed, May 20, 2015 at 7:26 PM, Ben Hoyt  wrote:
>>
>>> Hi Python devs,
>>>
>>> Enabling access to the AST for compiled code would make some cool
>>> things possible (C# LINQ-style ORMs, for example), and not knowing too
>>> much about this part of Python internals, I'm wondering how possible
>>> and practical this would be.
>>>
>>> Context: PonyORM (http://ponyorm.com/) allows you to write regular
>>> Python generator expressions like this:
>>>
>>> select(c for c in Customer if sum(c.orders.price) > 1000)
>>>
>>> which compile into and run SQL like this:
>>>
>>> SELECT "c"."id"
>>> FROM "Customer" "c"
>>> LEFT JOIN "Order" "order-1" ON "c"."id" = "order-1"."customer"
>>> GROUP BY "c"."id"
>>> HAVING coalesce(SUM("order-1"."total_price"), 0) > 1000
>>>
>>> I think the Pythonic syntax here is beautiful. But the tricks PonyORM
>>> has to go to get it are ... not quite so beautiful. Because the AST is
>>> not available, PonyORM decompiles Python bytecode into an AST first,
>>> and then converts that to SQL. (More details on all that from author's
>>> EuroPython talk at http://pyvideo.org/video/2968)
>>>
>>> I believe PonyORM needs the AST just for generator expressions and
>>> lambda functions, but obviously if this kind of AST access feature
>>> were in Python it'd probably be more general.
>>>
>>> I believe C#'s LINQ provides something similar, where if you're
>>> developing a LINQ converter library (say LINQ to SQL), you essentially
>>> get the AST of the code ("expression tree") and the library can do
>>> what it wants with that.
>>>
>>> What would it take to enable this kind of AST access in Python? Is it
>>> possible? Is it a good idea?
>>>
>>> -Ben
>>> ___
>>> 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)
>>
>
>


-- 
--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] Enable access to the AST for Python code

[Ben Hoyt]

Heh, thanks. :-)

On Thu, May 21, 2015 at 2:17 PM, Guido van Rossum  wrote:

> Dang it. :-) I just want to encourage you to continue pursuing this idea,
> one way or another.
>
> On Thu, May 21, 2015 at 7:01 AM, Ben Hoyt  wrote:
>
>> Thanks. Good point about python-ideas -- I was thinking that after I sent
>> it too. I'll repost there soon.
>>
>> Out of interest, what specifically were you referring to as "definitely
>> cool" here: LINQ-style generator expressions that build SQL ala PonyORM, or
>> the more general feature of enabling AST access?
>>
>> -Ben
>>
>> On Wed, May 20, 2015 at 10:31 PM, Guido van Rossum 
>> wrote:
>>
>>> Hey Ben, this is probably a better topic for python-ideas. I'll warn you
>>> that a hurdle for ideas like this is that ideally you don't want to support
>>> this just for CPython. It's definitely cool though! (Using movie poster
>>> style quotes you can turn this into a ringing endorsement: "definitely
>>> cool" -- The BDFL. :-)
>>>
>>> On Wed, May 20, 2015 at 7:26 PM, Ben Hoyt  wrote:
>>>
 Hi Python devs,

 Enabling access to the AST for compiled code would make some cool
 things possible (C# LINQ-style ORMs, for example), and not knowing too
 much about this part of Python internals, I'm wondering how possible
 and practical this would be.

 Context: PonyORM (http://ponyorm.com/) allows you to write regular
 Python generator expressions like this:

 select(c for c in Customer if sum(c.orders.price) > 1000)

 which compile into and run SQL like this:

 SELECT "c"."id"
 FROM "Customer" "c"
 LEFT JOIN "Order" "order-1" ON "c"."id" = "order-1"."customer"
 GROUP BY "c"."id"
 HAVING coalesce(SUM("order-1"."total_price"), 0) > 1000

 I think the Pythonic syntax here is beautiful. But the tricks PonyORM
 has to go to get it are ... not quite so beautiful. Because the AST is
 not available, PonyORM decompiles Python bytecode into an AST first,
 and then converts that to SQL. (More details on all that from author's
 EuroPython talk at http://pyvideo.org/video/2968)

 I believe PonyORM needs the AST just for generator expressions and
 lambda functions, but obviously if this kind of AST access feature
 were in Python it'd probably be more general.

 I believe C#'s LINQ provides something similar, where if you're
 developing a LINQ converter library (say LINQ to SQL), you essentially
 get the AST of the code ("expression tree") and the library can do
 what it wants with that.

 What would it take to enable this kind of AST access in Python? Is it
 possible? Is it a good idea?

 -Ben
 ___
 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)
>>>
>>
>>
>
>
> --
> --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] Status of PEP 484 and the typing module

[Guido van Rossum]

Things are looking up. I think we're down to a very small number of issues
where we still disagree -- hopefully you'll allow me some leeway. :-)

On Thu, May 21, 2015 at 8:45 AM, Mark Shannon  wrote:

>
>
> On 21/05/15 16:01, Guido van Rossum wrote:
>
>> Hi Mark,
>>
>> We're down to the last few items here. I'm CC'ing python-dev so folks
>> can see how close we are. I'll answer point by point.
>>
>> On Thu, May 21, 2015 at 6:24 AM, Mark Shannon > > wrote:
>>
>> Hi,
>>
>> The PEP itself is looking fairly good.
>>
>>
>> I hope you'll accept it at least provisionally so we can iterate over
>> the finer points while a prototype of typing.py in in beta 1.
>>
>> However, I don't think that typing.py is ready yet, for a number of
>> reasons:
>>
>> 1.
>> As I've said before, there needs to be a distinction between classes
>> and types.
>> They is no need for Any, Generic, Generic's subtypes, or Union to
>> subclass builtins.type.
>>
>>
>> I strongly disagree. They can appear in many positions where real
>> classes are acceptable, in particular annotations can have classes (e.g.
>> int) or types (e.g. Union[int, str]).
>>
>
> Why does this mean that they have to be classes? Annotations can be any
> object.
>

I want to encourage users to think about annotations as types, and for most
users the distinction between type and class is too subtle, so a simpler
rule is to say they are classes. This works out nicely when the annotations
are simple types such as 'int' or 'str' or user-defined classes (e.g.
'Employee').


> It might to help to think, not in terms of types being classes, but
> classes being shorthand for the nominal type for that class (from the point
> of view of the checker and type geeks)
> So when the checker sees 'int' it treats it as Type(int).
>

I'm fine with that being the formal interpretation (except that I don't
want to introduce a function named Type()). But it's too subtle for most
users.


> Subtyping is distinct from subclassing;
> Type(int) <: Union[Type(int), Type(str)]
> has no parallel in subclassing.
> There is no class that corresponds to a Union, Any or a Generic.
>

Again, for most people te distinction is too subtle. People expect to be
able to play around with things interactively. I think it will be helpful
if they can experiment with the objects exported by typing too:
experimenting with things like isinstance(42, Union[int, str]) or
issubclass(Any, Employee) and issubclass(Employee, Any) is a useful thing
to explore how these things work (always with the caveat that when Any is
involved, issubclass is not transitive). Of course it won't work when they
advance to type variables -- at that point you just *have* to understand
the theory and switch from using the interactive interpreter to writing
small test programs and seeing how mypy (or some other checker) responds to
them.


> In order to support the
> class C(ParameterType[T]): pass
>

I presume you mean class C(Generic[T])?


> syntax, parametric types do indeed need to be classes, but Python has
> multiple inheritance, so thats not a problem:
> class ParameterType(type, Type): ...
> Otherwise typing.Types shouldn't be builtin.types and vice versa.
>

There's one thing here that Jukka has convinced me of. While I really want
Union[...] to act like a class (though not subclassable!), plain Union
(without the [...]) needn't. The same is true for Callable and Tuple
without [...]. I've filed https://github.com/ambv/typehinting/issues/133
for this. I'm not sure how much work it will be to fix this but I don't
think it absolutely needs to be done in beta 1 -- there's not much you can
do with them anyway.


> I think a lot of this issues on the tracker would not have been issues had
> the distinction been more clearly enforced.
>
>
>> Playing around with typing.py, it has also become clear to me that it
>> is also important to distinguish type constructors from types.
>>
>> What do I mean by a type constructor?
>> A type constructor makes types.
>> "List" is an example of a type constructor. It constructs types such
>> as List[T] and List[int].
>> Saying that something is a List (as opposed to a list) should be
>> rejected.
>>
>>
>> The PEP actually says that plain List (etc.) is equivalent to List[Any].
>> (Well, at least that's the intention; it's implied by the section about
>> the equivalence between Node() and Node[Any]().
>>
>
> Perhaps we should change that. Using 'List', rather than 'list' or
> 'List[Any]' suggests an error, or misunderstanding, to me.
>
> Is there a use case where 'List' is needed, and 'list' will not suffice?
> I'm assuming that the type checker knows that 'list' is a MutableSequence.
>

I think it's easier if we ask people to always write 'List' rather than
'list' when they are talking about types, and 'List[Any]' will probably be
a popular type (lots of people don't want to think about exactly what the
item type is,

Re: [Python-Dev] segfaults due to hash randomization in C OrderedDict

[Eric Snow]

Good catch.  Unfortunately, sticking "keys = ((PyDictObject
*)od)->ma_keys;" right after "hash = ..." did not make a difference.
I still get the same segfault.

-eric

On Thu, May 21, 2015 at 11:17 AM, MRAB  wrote:
> On 2015-05-21 15:55, Eric Snow wrote:
>>
>> (see http://bugs.python.org/issue16991)
>>
>> I an working on resolving an intermittent segfault that my C
>> OrderedDict patch introduces.  The failure happens in
>> test_configparser (RawConfigParser uses OrderedDict internally), but
>> only sporadically.  However, Ned pointed out to me that it appears to
>> be related to hash randomization, which I have verified.  I'm looking
>> into it.
>>
>> In the meantime, here's a specific question.  What would lead to the
>> pattern of failures I'm seeing?  I've verified that the segfault
>> happens consistently for certain hash randomization seeds and never
>> for the rest.  I don't immediately recognize the pattern but expect
>> that it would shed some light on where the problem lies.  I ran the
>> following command with the OrderedDict patch applied:
>>
>>for i in `seq 1 100`; do echo $i; PYTHONHASHSEED=$i ./python -m
>> test.regrtest -m test_basic test_configparser ; done
>>
>> Through 100 I get segfaults with seeds of 7, 15, 35, 37, 39, 40, 42,
>> 47, 50, 66, 67, 85, 87, 88, and 92.  I expect the distribution across
>> all seeds is uniform, but I haven't verified that.
>>
>> Thoughts?
>>
> In "_odict_get_index", for example (there are others), you're caching
> "ma_keys":
>
> PyDictKeysObject *keys = ((PyDictObject *)od)->ma_keys;
>
> If it resizes, you go back to the label "start", which is after that
> line, but could "ma_keys" change when it's resized?
>
> ___
> 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/ericsnowcurrently%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/archive%40mail-archive.com

Re: [Python-Dev] segfaults due to hash randomization in C OrderedDict

[MRAB]

On 2015-05-21 22:52, Eric Snow wrote:
> Good catch.  Unfortunately, sticking "keys = ((PyDictObject
> *)od)->ma_keys;" right after "hash = ..." did not make a difference.
> I still get the same segfault.

So, does it change sometimes?

>
> On Thu, May 21, 2015 at 11:17 AM, MRAB  
wrote:

> > On 2015-05-21 15:55, Eric Snow wrote:
> >>
> >> (see http://bugs.python.org/issue16991)
> >>
> >> I an working on resolving an intermittent segfault that my C
> >> OrderedDict patch introduces.  The failure happens in
> >> test_configparser (RawConfigParser uses OrderedDict internally), but
> >> only sporadically.  However, Ned pointed out to me that it appears to
> >> be related to hash randomization, which I have verified.  I'm looking
> >> into it.
> >>
> >> In the meantime, here's a specific question.  What would lead to the
> >> pattern of failures I'm seeing?  I've verified that the segfault
> >> happens consistently for certain hash randomization seeds and never
> >> for the rest.  I don't immediately recognize the pattern but expect
> >> that it would shed some light on where the problem lies.  I ran the
> >> following command with the OrderedDict patch applied:
> >>
> >>for i in `seq 1 100`; do echo $i; PYTHONHASHSEED=$i ./python -m
> >> test.regrtest -m test_basic test_configparser ; done
> >>
> >> Through 100 I get segfaults with seeds of 7, 15, 35, 37, 39, 40, 42,
> >> 47, 50, 66, 67, 85, 87, 88, and 92.  I expect the distribution across
> >> all seeds is uniform, but I haven't verified that.
> >>
> >> Thoughts?
> >>
> > In "_odict_get_index", for example (there are others), you're caching
> > "ma_keys":
> >
> > PyDictKeysObject *keys = ((PyDictObject *)od)->ma_keys;
> >
> > If it resizes, you go back to the label "start", which is after that
> > line, but could "ma_keys" change when it's resized?
> >

___
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] segfaults due to hash randomization in C OrderedDict

[Eric Snow]

On Thu, May 21, 2015 at 4:06 PM, MRAB  wrote:
> On 2015-05-21 22:52, Eric Snow wrote:
>> Good catch.  Unfortunately, sticking "keys = ((PyDictObject
>> *)od)->ma_keys;" right after "hash = ..." did not make a difference.
>> I still get the same segfault.
>
> So, does it change sometimes?

The segfault is consistent if I use the same seed (e.g. 7):

  PYTHONHASHSEED=7 ./python -m test.regrtest -m test_basic test_configparser

Some seeds always segfault and some seeds never segfault.

-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/archive%40mail-archive.com

Re: [Python-Dev] segfaults due to hash randomization in C OrderedDict

[MRAB]

On 2015-05-21 23:17, Eric Snow wrote:
> On Thu, May 21, 2015 at 4:06 PM, MRAB  wrote:
> > On 2015-05-21 22:52, Eric Snow wrote:
> >> Good catch.  Unfortunately, sticking "keys = ((PyDictObject
> >> *)od)->ma_keys;" right after "hash = ..." did not make a difference.
> >> I still get the same segfault.
> >
> > So, does it change sometimes?
>
> The segfault is consistent if I use the same seed (e.g. 7):
>
>   PYTHONHASHSEED=7 ./python -m test.regrtest -m test_basic 
test_configparser

>
> Some seeds always segfault and some seeds never segfault.
>
OK, another thought.

In "_odict_get_index" again, you say that if the hash has changed, the 
dict might've

been resized, but could the dict be resized _without_ the hash changing?

Could the value of "keys" still become invalid even if the hash is the same?

___
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] segfaults due to hash randomization in C OrderedDict

[Eric Snow]

On Thu, May 21, 2015 at 4:41 PM, MRAB  wrote:
> On 2015-05-21 23:17, Eric Snow wrote:
>> The segfault is consistent if I use the same seed (e.g. 7):
>>
>>   PYTHONHASHSEED=7 ./python -m test.regrtest -m test_basic
>> test_configparser
>>
>> Some seeds always segfault and some seeds never segfault.
>>
> OK, another thought.
>
> In "_odict_get_index" again, you say that if the hash has changed, the dict
> might've
> been resized, but could the dict be resized _without_ the hash changing?
>
> Could the value of "keys" still become invalid even if the hash is the same?

Good question.  The only way I can see here that the dict would resize
is during re-entrance to the interpreter eval loop via Python code
potentially triggered through the PyObject_Hash call.

Also, there's no check for a changed hash.  The code compares the size
of ma_keys (effectively the dict keys hash table) against the size of
of the odict "fast nodes" table.

-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/archive%40mail-archive.com

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

[Greg Ewing]

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.

--
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/archive%40mail-archive.com

Re: [Python-Dev] segfaults due to hash randomization in C OrderedDict

[MRAB]

On 2015-05-22 00:22, Eric Snow wrote:

On Thu, May 21, 2015 at 4:41 PM, MRAB  wrote:
> On 2015-05-21 23:17, Eric Snow wrote:
>> The segfault is consistent if I use the same seed (e.g. 7):
>>
>>   PYTHONHASHSEED=7 ./python -m test.regrtest -m test_basic
>> test_configparser
>>
>> Some seeds always segfault and some seeds never segfault.
>>
> OK, another thought.
>
> In "_odict_get_index" again, you say that if the hash has changed, the dict
> might've
> been resized, but could the dict be resized _without_ the hash changing?
>
> Could the value of "keys" still become invalid even if the hash is the same?

Good question.  The only way I can see here that the dict would resize
is during re-entrance to the interpreter eval loop via Python code
potentially triggered through the PyObject_Hash call.

Also, there's no check for a changed hash.  The code compares the size
of ma_keys (effectively the dict keys hash table) against the size of
of the odict "fast nodes" table.

Ah, OK.

I'm not looking at the use of "PyTuple_Pack". As I understand it, 
"PyTuple_Pack" borrows the
references of the objects passed, and when the tuple itself is DECREFed, 
those objects will be

DECREFed

"odict_reduce" calls "PyTuple_Pack", passing 1 or 2 references to 
Py_None which aren't INCREFed
first, so could there be a bug there? (There might be similar issues in 
other functions.)

___
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] segfaults due to hash randomization in C OrderedDict

[Eric Snow]

On Thu, May 21, 2015 at 5:55 PM, MRAB  wrote:
> I'm not looking at the use of "PyTuple_Pack". As I understand it,
> "PyTuple_Pack" borrows the
> references of the objects passed, and when the tuple itself is DECREFed,
> those objects will be
> DECREFed

>From the docs [1] it seems that PyTuple_Pack does not steal any
references and it returns a new reference.  Perhaps you were thinking
of PyTuple_SetItem (and PyTuple_SET_ITEM)?

[1] https://docs.python.org/3.5//c-api/tuple.html

>
> "odict_reduce" calls "PyTuple_Pack", passing 1 or 2 references to Py_None
> which aren't INCREFed
> first, so could there be a bug there? (There might be similar issues in
> other functions.)

Alas, I don't think it is. :(

I'll point out that the configparser test in question does a lot of
resizes.  It may be that the problem only surfaces after many resizes
and apparently only for certain hash randomization seeds.  At the
moment I'm looking at how hash randomization impacts resizing.  I'm
certainly seeing that the resizes happen at different item counts
depending on the seed.

-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/archive%40mail-archive.com

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

[Ethan Furman]

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.


--
~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/archive%40mail-archive.com

Re: [Python-Dev] segfaults due to hash randomization in C OrderedDict

[MRAB]

On 2015-05-22 01:12, Eric Snow wrote:

On Thu, May 21, 2015 at 5:55 PM, MRAB  wrote:
> I'm not looking at the use of "PyTuple_Pack". As I understand it,
> "PyTuple_Pack" borrows the
> references of the objects passed, and when the tuple itself is DECREFed,
> those objects will be
> DECREFed

>From the docs [1] it seems that PyTuple_Pack does not steal any
references and it returns a new reference.  Perhaps you were thinking
of PyTuple_SetItem (and PyTuple_SET_ITEM)?

[1] https://docs.python.org/3.5//c-api/tuple.html

>
> "odict_reduce" calls "PyTuple_Pack", passing 1 or 2 references to Py_None
> which aren't INCREFed
> first, so could there be a bug there? (There might be similar issues in
> other functions.)

Alas, I don't think it is. :(

I'd come to the same conclusion.

Oh, well, I'll keep looking...

I'll point out that the configparser test in question does a lot of
resizes.  It may be that the problem only surfaces after many resizes
and apparently only for certain hash randomization seeds.  At the
moment I'm looking at how hash randomization impacts resizing.  I'm
certainly seeing that the resizes happen at different item counts
depending on the seed.


___
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] Enable access to the AST for Python code

[Greg Ewing]

Ethan Furman wrote:
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.


If the semantics were exactly the same as the Python
snippet, there would be no need to convert it to another
language -- you might as well just run the Python
code as-is.

The whole point of this kind of facility is to express
things that you *can't* express the way you would like
using standard Python semantics.

From the user's point of view, it doesn't matter whether
the implementation works by generating Python code, or
generating some other language, or processing the AST
directly. The effect is to assign non-Python semantics
to Python syntax.

(At least is *is* still Python syntax -- I can understand
Guido being wary of letting people redefine the syntax
as well.)

--
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/archive%40mail-archive.com

Re: [Python-Dev] segfaults due to hash randomization in C OrderedDict

[Eric Snow]

On Thu, May 21, 2015 at 6:22 PM, MRAB  wrote:
> Oh, well, I'll keep looking...

Thanks!

-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/archive%40mail-archive.com

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  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

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

[Steve Dower]

The semantics could be the same while the execution plan is different, just 
like numba compiled code runs with the same semantics as the original.

A better way of getting the AST than decompiling byte code is all that's being 
asked for. Maybe not easy to do in the general case, but certainly not an 
unreasonable request.

Cheers,
Steve

Top-posted from my Windows Phone

From: Greg Ewing
Sent: ‎5/‎21/‎2015 17:29
To: python-dev@python.org
Subject: Re: [Python-Dev] Enable access to the AST for Python code

Ethan Furman wrote:
> 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.

If the semantics were exactly the same as the Python
snippet, there would be no need to convert it to another
language -- you might as well just run the Python
code as-is.

The whole point of this kind of facility is to express
things that you *can't* express the way you would like
using standard Python semantics.

 From the user's point of view, it doesn't matter whether
the implementation works by generating Python code, or
generating some other language, or processing the AST
directly. The effect is to assign non-Python semantics
to Python syntax.

(At least is *is* still Python syntax -- I can understand
Guido being wary of letting people redefine the syntax
as well.)

--
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/steve.dower%40microsoft.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] Enable access to the AST for Python code

[Ben Hoyt]

FYI, I've re-posted this on python-ideas now:
https://mail.python.org/pipermail/python-ideas/2015-May/033621.html

-Ben

On Wed, May 20, 2015 at 10:31 PM, Guido van Rossum  wrote:
> Hey Ben, this is probably a better topic for python-ideas. I'll warn you
> that a hurdle for ideas like this is that ideally you don't want to support
> this just for CPython. It's definitely cool though! (Using movie poster
> style quotes you can turn this into a ringing endorsement: "definitely cool"
> -- The BDFL. :-)
>
> On Wed, May 20, 2015 at 7:26 PM, Ben Hoyt  wrote:
>>
>> Hi Python devs,
>>
>> Enabling access to the AST for compiled code would make some cool
>> things possible (C# LINQ-style ORMs, for example), and not knowing too
>> much about this part of Python internals, I'm wondering how possible
>> and practical this would be.
>>
>> Context: PonyORM (http://ponyorm.com/) allows you to write regular
>> Python generator expressions like this:
>>
>> select(c for c in Customer if sum(c.orders.price) > 1000)
>>
>> which compile into and run SQL like this:
>>
>> SELECT "c"."id"
>> FROM "Customer" "c"
>> LEFT JOIN "Order" "order-1" ON "c"."id" = "order-1"."customer"
>> GROUP BY "c"."id"
>> HAVING coalesce(SUM("order-1"."total_price"), 0) > 1000
>>
>> I think the Pythonic syntax here is beautiful. But the tricks PonyORM
>> has to go to get it are ... not quite so beautiful. Because the AST is
>> not available, PonyORM decompiles Python bytecode into an AST first,
>> and then converts that to SQL. (More details on all that from author's
>> EuroPython talk at http://pyvideo.org/video/2968)
>>
>> I believe PonyORM needs the AST just for generator expressions and
>> lambda functions, but obviously if this kind of AST access feature
>> were in Python it'd probably be more general.
>>
>> I believe C#'s LINQ provides something similar, where if you're
>> developing a LINQ converter library (say LINQ to SQL), you essentially
>> get the AST of the code ("expression tree") and the library can do
>> what it wants with that.
>>
>> What would it take to enable this kind of AST access in Python? Is it
>> possible? Is it a good idea?
>>
>> -Ben
>> ___
>> 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] Enable access to the AST for Python code

[Ethan Furman]

On 05/21/2015 05:28 PM, Greg Ewing wrote:

Ethan Furman wrote:


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.


If the semantics were exactly the same as the Python
snippet, there would be no need to convert it to another
language -- you might as well just run the Python
code as-is.


Going back to the OP:


Context: PonyORM (http://ponyorm.com/) allows you to write regular
Python generator expressions like this:

select(c for c in Customer if sum(c.orders.price) > 1000)

which compile into and run SQL like this:

SELECT "c"."id"
FROM "Customer" "c"
LEFT JOIN "Order" "order-1" ON "c"."id" = "order-1"."customer"
GROUP BY "c"."id"
HAVING coalesce(SUM("order-1"."total_price"), 0) > 1000


That last code is /not/ Python.  ;)

--
~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/archive%40mail-archive.com

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

[Greg]

On 22/05/2015 1:33 p.m., Ethan Furman wrote:

Going back to the OP:


select(c for c in Customer if sum(c.orders.price) > 1000)

which compile into and run SQL like this:

SELECT "c"."id"
FROM "Customer" "c"
LEFT JOIN "Order" "order-1" ON "c"."id" = "order-1"."customer"
GROUP BY "c"."id"
HAVING coalesce(SUM("order-1"."total_price"), 0) > 1000


That last code is /not/ Python.  ;)


More importantly, it's not Python *semantics*. You can't view
it as simply a translation of the Python expression into a
different language.

I still think this is really a macro facility by a different
name. I'm not saying that's a bad thing, just pointing it out.

The main difference is that a macro would (or at least could)
be expanded at compile time, whereas this would require
processing the AST each time it's used.

--
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/archive%40mail-archive.com

Re: [Python-Dev] segfaults due to hash randomization in C OrderedDict

[Eric Snow]

On Thu, May 21, 2015 at 6:22 PM, MRAB  wrote:
> Oh, well, I'll keep looking...

I've posted some data to http://bugs.python.org/issue16991 that I hope
will shed some light on the issue.  We can continue the conversation
there.

-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/archive%40mail-archive.com