Creation of a metaclass for dataclass.

[Kirill Balunov]

I'm studying the meta-programming topic in Python, and as an exercise I'm
trying to make a somewhat simplified version of dataclass. My goal in this
exercise is to make the difference between annotated variables and usual
ones to be as much transparent as possible. So I come with this code to
obtain initial fields. It does not catch corner cases and as much as
possible undressed to be short. So my question is there any visible
pitfalls or am I doing something wrong from the early beginning?

Two helpful functions not to clutter `__annotations__`:

from typing import Any
AnyType = Any

def _is_not_dunder(name):
return not ((len(name) > 4) and (name[:2] == name[-2:] == '__'))

def _is_not_descriptor(obj):
return not (hasattr(obj, '__get__') or
hasattr(obj, '__set__') or
hasattr(obj, '__delete__'))

The special dict (class namespace) to inject usual variables in `
__annotations__` with default typehint - `AnyType`, and also keep their
ordered appearance in the class body.

class SpecialDict(dict):
def __init__(self):
super().__init__()
super().__setitem__('__annotations__', {})

def __setitem__(self, key, value):
if not (key in self) and _is_not_dunder(key) and
_is_not_descriptor(value):
self['__annotations__'][key] = AnyType
super().__setitem__(key, value)

Data meta-class which defines `__fields` from `__annotations__`:

class DataMeta(type):
@classmethod
def __prepare__(metacls, cls, bases, **kwargs):
_dict = SpecialDict()
return _dict

def __init__(cls, *args , **kwargs):
super().__init__(*args)

def __new__(metacls, cls, bases, clsdict):
clsdict['__fields'] = tuple(clsdict['__annotations__'].items())
_cls = type.__new__(metacls, cls, bases, clsdict)
return _cls

And test class:

class MyClass(metaclass=DataMeta):
a: float
barattr: int = 2
jik = 12
bzik: int =14

def foo(self, param):
pass

data = MyClass()

a.__fields   # (('a', float), ('barattr', int), ('jik', typing.Any),
('bzik', int))


Thank you!

With kind regards, -gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[mm0fmf]

On 28/12/2017 22:38, Tim Chase wrote:

On 2017-12-29 08:42, Ben Finney wrote:

Duram  writes:


How to use goto in python?


Step 0: what is goto in Python?

Step 1: that's not something that exists in Python. So why are you
asking how to use something that doesn't exist?


so quick to shoot down a poor soul.

http://entrian.com/goto/

Gives you both GOTO and COMEFROM ;-)

-tkc




This! An awful lot of my early C++, C# and Python programs resembled 
FORTRAN66, it took effort to learn the Zen of each language. Now I can 
continue to write FORTRAN66 style programs in Python and unlearn all the 
good stuff.


Thank you. And remember, a good programmer can write FORTRAN66 programs 
in any language!

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[alister via Python-list]

On Thu, 28 Dec 2017 18:54:31 -0800, breamoreboy wrote:

> On Thursday, December 28, 2017 at 7:40:14 PM UTC, alister wrote:
>> On Thu, 28 Dec 2017 00:58:48 -0200, Duram wrote:
>> 
>> > How to use goto in python?
>> > 
>> > ---
>> > This email has been checked for viruses by AVG.
>> > http://www.avg.com
>> 
>> Dont!
>> actually you cant - there isn't one*
>> 
>> *at least not in the core language no doubt some sick person will have
>> manager to hack together some sort of dodgy code to simulate it if you
>> look hard enough)
>> 
>> 
> This http://entrian.com/goto/ has been around for almost 14 years.

ok ill admit i didn't look at all (because goto is a silly idea & 
unnecessary)



-- 
The sunlights differ, but there is only one darkness.
-- Ursula K. LeGuin, "The Dispossessed"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: GUI user input to function

[Nico Vogeli]

Am Donnerstag, 28. Dezember 2017 14:00:14 UTC+1 schrieb Chris Angelico:
> On Thu, Dec 28, 2017 at 11:06 PM, Nico Vogeli  wrote:
> > Am Donnerstag, 28. Dezember 2017 12:59:24 UTC+1 schrieb Chris Angelico:
> >> On Thu, Dec 28, 2017 at 8:38 PM, Nico Vogeli  wrote:
> >> > Withs test, this return a correct value for the two x functions:
> >> >
> >> > from sympy import symbols
> >> >
> >> > x = symbols('x')
> >> > f1 = eval(input('function 1 '))
> >> > f2 = eval(input('function 2 '))
> >> >
> >>
> >> What are you typing as input? It's hard to grok your code without knowing 
> >> that.
> >>
> >> ChrisA
> >
> > I'm sorry! User input would look like this for example: x**2 + 3*x or x**3
> >
> 
> Cool. That's an expression, but it isn't a function. To make that into
> a function, you need to prefix it with the lambda keyword.
> 
> So you should be able to construct functions like this:
> 
> f1 = eval("lambda x: " + input("function 1: "))
> 
> Then, when you type "x**3", Python evaluates "lambda x: x**3", which
> is a function.
> 
> ChrisA

Thank you very much! It now works perfectly fine now!!

Thank you!

Nicco
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyWin32 installer question

[Skip Montanaro]

> That's not an architecture-independent file. The Wheel spec gives all
> the details, but "cp27" (as opposed to "py27") means it's CPython only
> (which usually means it's got a C extension) and "win32" is 32-bit
> only ("win_amd64" is the tag for 64-bit Windows). So the problem is
> that the py2exe_py2 maintainer doesn't supply a 64-bit build.

Thanks. I'll shoot Thomas Heller an email...

S
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyWin32 installer question

[Skip Montanaro]

> Thanks. I'll shoot Thomas Heller an email...


Actually, make that Christopher Toth. Seems he's the current maintainer.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyWin32 installer question

[Paul Moore]

On 29 December 2017 at 16:04, Skip Montanaro  wrote:
>> Thanks. I'll shoot Thomas Heller an email...
>
>
> Actually, make that Christopher Toth. Seems he's the current maintainer.

If you get no joy there, then in a week or two, when I next get access
to a system with a Python 2.x build environment on it, I can see if I
can do a 64-bit build for you. Ping me if that would be a help.

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[bartc]

On 29/12/2017 09:52, alister wrote:

On Thu, 28 Dec 2017 18:54:31 -0800, breamoreboy wrote:


On Thursday, December 28, 2017 at 7:40:14 PM UTC, alister wrote:

On Thu, 28 Dec 2017 00:58:48 -0200, Duram wrote:


How to use goto in python?

---
This email has been checked for viruses by AVG.
http://www.avg.com


Dont!
actually you cant - there isn't one*

*at least not in the core language no doubt some sick person will have
manager to hack together some sort of dodgy code to simulate it if you
look hard enough)



This http://entrian.com/goto/ has been around for almost 14 years.


ok ill admit i didn't look at all (because goto is a silly idea &
unnecessary)


If you want to translate code from one language to another, and the 
source language uses gotos, or uses control structures not available in 
the target language, then gotos would be very useful in the latter.


(gotos are frowned upon because they make program flow harder to see 
within a normal structured program. However examples of 'advanced' 
Python I've seen are such that I would rather contend with a few gotos.)


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python goto

[Grant Edwards]

On 2017-12-28, Skip Montanaro  wrote:

> Though it appears some wag has used function decorators to implement
> goto statements:
>
> https://pypi.python.org/pypi/goto-statement/1.1
>
> Rather clever, it seems.

That's brilliant!

Not that I'd look kindly on anybody who used it on project I ended up
working on...

-- 
Grant Edwards   grant.b.edwardsYow! My Aunt MAUREEN was a
  at   military advisor to IKE &
  gmail.comTINA TURNER!!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[Chris Angelico]

On Sat, Dec 30, 2017 at 4:13 AM, bartc  wrote:
> If you want to translate code from one language to another, and the source
> language uses gotos, or uses control structures not available in the target
> language, then gotos would be very useful in the latter.
>

As has already been said in this thread, a competent FORTRAN
programmer can write FORTRAN code in any language. But if you want to
actually write Python code, instead of writing FORTRAN code that gets
run through a Python interpreter, you have to grok the Python way of
doing things. You can't do that by mechanically transforming source
code into the syntax of a different language.

People who try to tell you that all programming languages are
identical, just with different syntax, are doing you a disservice.
Lisp is not Python is not REXX is not C is not DeScribe Macro
Language. (Especially the latter. Do NOT try to write C code in DML.
It'll look ugly. Trust me.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[MarkA]

On Thu, 28 Dec 2017 00:58:48 -0200, Duram wrote:

> How to use goto in python?
> 
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com

Rather than ask how to use an unavailable statement (GOTO), why not 
investigate why no modern languages use it?

-- 
MarkA

You can safely assume that you have created God in your own image when it 
turns out that God hates all the same people you do.  -- Anne Lamott
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyWin32 installer question

[Terry Reedy]

On 12/29/2017 11:38 AM, Paul Moore wrote:

On 29 December 2017 at 16:04, Skip Montanaro  wrote:

Thanks. I'll shoot Thomas Heller an email...



Actually, make that Christopher Toth. Seems he's the current maintainer.


If you get no joy there, then in a week or two, when I next get access
to a system with a Python 2.x build environment on it, I can see if I
can do a 64-bit build for you. Ping me if that would be a help.


I have not followed this thread, but there may be no need to.
https://www.lfd.uci.edu/~gohlke/pythonlibs/
Christopher Gohlke, at UC Irvine, provides Windows cpxx wheels for about 
300 packages, for 2.7, 3.4, 3.5, 3.6, 3.7, in win32 and win_amd64 
versions (as applicable).   PyWin32-221 is included, with all combinations.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[bartc]

On 29/12/2017 18:55, MarkA wrote:

On Thu, 28 Dec 2017 00:58:48 -0200, Duram wrote:


How to use goto in python?

---
This email has been checked for viruses by AVG.
http://www.avg.com


Rather than ask how to use an unavailable statement (GOTO), why not
investigate why no modern languages use it?


Golang uses goto.

Lua didn't have goto but then added it.

PHP also added goto to a later version.

That's the extent of my one minutes' research; I guess a few other 
newish languages might use it (plus any I create myself, and pile of 
older languages).


Why most newer, higher level languages don't, I don't know. Perhaps 
because the people who design them want to make programming harder? Or 
they are adept at doing without it, and expect everyone else to be 
equally so?


Nothing wrong with goto when you have a throwaway program to finish and 
an approaching deadline.


Overuse of goto in real applications would be a problem, but that's the 
same with any feature. In Python, you can define F as function, but then 
reassign any other arbitrary value to F, at any point in a program, at 
any time, and as many times as you like. That makes goto seem almost 
benign! (Except that Python would probably let you assign to labels...)


--
bartc

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[Chris Angelico]

On Sat, Dec 30, 2017 at 7:03 AM, bartc  wrote:
> On 29/12/2017 18:55, MarkA wrote:
>>
>> On Thu, 28 Dec 2017 00:58:48 -0200, Duram wrote:
>>
>>> How to use goto in python?
>>>
>>> ---
>>> This email has been checked for viruses by AVG.
>>> http://www.avg.com
>>
>>
>> Rather than ask how to use an unavailable statement (GOTO), why not
>> investigate why no modern languages use it?
>
>
> Golang uses goto.
>
> Lua didn't have goto but then added it.
>
> PHP also added goto to a later version.

Ahh, great choice of example. "It's okay - PHP does it."

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[bartc]

On 29/12/2017 20:25, Chris Angelico wrote:

On Sat, Dec 30, 2017 at 7:03 AM, bartc  wrote:

On 29/12/2017 18:55, MarkA wrote:


On Thu, 28 Dec 2017 00:58:48 -0200, Duram wrote:


How to use goto in python?

---
This email has been checked for viruses by AVG.
http://www.avg.com



Rather than ask how to use an unavailable statement (GOTO), why not
investigate why no modern languages use it?



Golang uses goto.

Lua didn't have goto but then added it.

PHP also added goto to a later version.


Ahh, great choice of example. "It's okay - PHP does it."


I don't know PHP, but I guess it has all the usual features that people 
can use to eliminate goto (ie. the ability to add extra, more convoluted 
code).


So presumably adding it had a net benefit.

Notice I said Lua and Golang also have it.

Adding it to a language doesn't mean people are obliged to use it.

--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[D'Arcy Cain]

On 12/29/2017 02:25 PM, Chris Angelico wrote:
>> PHP also added goto to a later version.
> 
> Ahh, great choice of example. "It's okay - PHP does it."

I thought that that was a reason to not do it.

-- 
D'Arcy J.M. Cain
Vybe Networks Inc.
http://www.VybeNetworks.com/
IM:da...@vex.net VoIP: sip:da...@vybenetworks.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[Chris Angelico]

On Sat, Dec 30, 2017 at 8:03 AM, D'Arcy Cain  wrote:
> On 12/29/2017 02:25 PM, Chris Angelico wrote:
>>> PHP also added goto to a later version.
>>
>> Ahh, great choice of example. "It's okay - PHP does it."
>
> I thought that that was a reason to not do it.

Often, yeah. Hence my comment that "hey, PHP has goto" is an excellent
choice of example.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[bartc]

On 29/12/2017 21:56, Stefan Ram wrote:

Chris Angelico  writes:

On Sat, Dec 30, 2017 at 8:03 AM, D'Arcy Cain  wrote:

On 12/29/2017 02:25 PM, Chris Angelico wrote:

PHP also added goto to a later version.

Ahh, great choice of example. "It's okay - PHP does it."

I thought that that was a reason to not do it.

Often, yeah. Hence my comment that "hey, PHP has goto" is an excellent
choice of example.


   I already wrote this before, recently, in some newsgroup (here?):

   Knuth's algorithm's often use "goto"'s. When translating them into
   another language, it is helpful to be able to translate them as
   direct as possible. Having to change the algorithm in one's head
   to avoid "goto" while converting it to Python seems to be a
   source of errors.

   When a language has a "goto", one can then translate Knuth's
   algorithms more literally. One then can add tests. And /then/
   one can refactor step-by-step to an algorithm without "goto".




That sort of argument will never wash here:

"/I/ can write code without ever using 'goto'. So nobody else should 
ever need to use it either".


Forget about automatic code translators, automatic parser generators, 
automatic state machine translators, plus a host of other uses which 
goto could simplify.


--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 29/12/2017 21:55, Lawrence D’Oliveiro wrote:

On Saturday, December 30, 2017 at 9:03:50 AM UTC+13, bartc wrote:

Why most newer, higher level languages don't, I don't know. Perhaps
because the people who design them want to make programming harder?


I don’t use gotos in C code. Why should it be “harder” in a higher-level 
language?



Good for you.

Looking at 14 million lines of Linux kernel sources, which are in C, 
over 100,000 of them use 'goto'. About one every 120 lines.


My own low level sources use about one goto every 400 lines. It's hardly 
a lot. If one is used, it's because it was handy to use it, until such 
time as it can be replaced with proper logic. But such logic will 
usually be more convoluted.


BTW, looking at 220,000 lines of CPython sources, in C (an old 
distribution I had to hand), there are 2600 gotos, about one every 85 
lines. And those are the ones are directly visible as gotos, and not 
hidden behind macros.


I understand that on Linux, the CPython dispatcher makes use of label 
pointers, using 'goto *opcode_targets[*next_instr++]' to do a faster 
byte-code dispatch than using switch.


You I guess would have written it without that, and we'd all have to 
suffer 10% slower speed (or whatever) for your principles. That's 
assuming you could have got rid of the other 2600 gotos as well.


--
bartc

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Skip Montanaro]

Looking at 14 million lines of Linux kernel sources, which are in C, over
100,000 of them use 'goto'. About one every 120 lines.


Isn't C's goto statement restricted to the current function? I imagine
setjmp and longjmp calls might be more insidious.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[MRAB]

On 2017-12-29 23:12, bartc wrote:

On 29/12/2017 21:55, Lawrence D’Oliveiro wrote:

On Saturday, December 30, 2017 at 9:03:50 AM UTC+13, bartc wrote:

Why most newer, higher level languages don't, I don't know. Perhaps
because the people who design them want to make programming harder?


I don’t use gotos in C code. Why should it be “harder” in a higher-level 
language?



Good for you.

Looking at 14 million lines of Linux kernel sources, which are in C,
over 100,000 of them use 'goto'. About one every 120 lines.

My own low level sources use about one goto every 400 lines. It's hardly
a lot. If one is used, it's because it was handy to use it, until such
time as it can be replaced with proper logic. But such logic will
usually be more convoluted.

BTW, looking at 220,000 lines of CPython sources, in C (an old
distribution I had to hand), there are 2600 gotos, about one every 85
lines. And those are the ones are directly visible as gotos, and not
hidden behind macros.

I understand that on Linux, the CPython dispatcher makes use of label
pointers, using 'goto *opcode_targets[*next_instr++]' to do a faster
byte-code dispatch than using switch.

You I guess would have written it without that, and we'd all have to
suffer 10% slower speed (or whatever) for your principles. That's
assuming you could have got rid of the other 2600 gotos as well.

I too use goto in C code, principally to go to clean-up code after 
checking the result of a call.


In Python, on the other hand, I have automatic garbage collection, 
exceptions, etc.


It's OK for code that's close to the metal, but in high-level code? No.

Python has managed for >25 years without it, and I've yet to see a 
convincing use-case.

--
https://mail.python.org/mailman/listinfo/python-list

How to create a python extension module from a shared library?

[Etienne Robillard]

Hi all,

I would like to extend uWSGI by creating a CPython extension module for 
the libuwsgi.so shared library included in the distribution.


My goal is to use this automatically generated CPython module for 
extending uWSGI.


I have summarized my current approach here:

https://mail.python.org/pipermail/tutor/2017-December/112475.html

So far, I have tried to use CFFI and pycparser to generate the Python 
bindings, however CFFI and pycparser doesn't handle C directives like 
#include and #define.


I also attempted using clang to preprocess the "uwsgi.h" header found in 
the uWSGI distro with pycparser.parse_file() to generate a AST, however 
the generated AST object seems incorrect.


Is there any way to reflect a shared library into a CPython module?

I know that using "nm -D libuwsgi.so" I can get a list of available 
functions for this module. However, I have very little experience with 
ctypes and CFFI.


Do I need to modify CFFI to allow it to parse a C header with libclang?

I'm guessing CFFI/clang or ctypes should allow me to reflect the shared 
library, but I'm not sure about which method is the most appropriate.



What do you think?

Sincerely,

Etienne

--
Etienne Robillard
tkad...@yandex.com
https://www.isotopesoftware.ca/

--
https://mail.python.org/mailman/listinfo/python-list

Goto

[Mikhail V]

MRAB wrote:


> It's OK for code that's close to the metal, but in high-level code? No.
> Python has managed for >25 years without it, and I've yet to see a
> convincing use-case.

"convincing" is a broad term I think, especially for syntax proposals ;)

I think often one wish to use it just to avoid "if" blocks in
obvious situations - no need to setup flags and  indent/unindent code blocks.

Apart from that, I personally would prefer it in such typical code:

if a :
a()
goto "end"
if b :
b()
goto "end"
if c :
c()
goto "end"
"end"

I know I can do it with "elif", but "elif" is just not my cup of tea.
For this case goto provides symmetrical and explicit look, which I value a lot.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Rustom Mody]

On Saturday, December 30, 2017 at 8:35:27 AM UTC+5:30, Lawrence D’Oliveiro 
wrote:
> On Saturday, December 30, 2017 at 12:12:23 PM UTC+13, bartc wrote:
> > Looking at 14 million lines of Linux kernel sources, which are in C, 
> > over 100,000 of them use 'goto'. About one every 120 lines.
> 
> That kind of thing leads to spaghetti code.
> 
> Here  is an example I like to bring 
> up: writing a Python extension module in C. As you know, this requires a lot 
> of careful memory management to cope with errors and avoid either memory 
> leaks or double-frees. The coding convention I came up with looks like this:
> 
> ... initialize pointers to allocated storage to NULL ...
> do /*once*/
>   {
> ... processing ...
> allocate some storage;
> if (error)
> break;
> ... more processing ...
> allocate more storage;
> if (error)
> break;
> ... even more processing ...
>   }
> while (false);
> ... free allocated storage ...
> 
> Basically, it becomes possible to satisfy yourself, by inspection, that every 
> possible control path through the above code will pass once, and only once, 
> through the storage deallocation.
> 
> Things get slightly more complicated where allocation has to happen in a 
> loop. Actually, that’s where the interesting cases happen. My technique can 
> be adapted to cope elegantly with this, too--see the code.

Bizarre how religions proliferate…
I wonder how many people who quote Dijkstra have read "goto statement considered
harmful". 
And that short letter was negative, aka "Don’t use goto!”

The more positive answer to the question: “Ok so then how to program?”
was "Structured Programming"
I am ready to bet that an even tinier percentage has ever seen that tome

And if one really got the gist of structuredness:
mapping an automaton with
state = label
transition = goto
is really the most clean structured mapping

One can do almost as well with a switch and (case) labels

You can make a virtue of the fact that python has neither
I call it blind religious genuflecting

BTW there can be quite good reasons for not putting¹ goto into a language
especially interpreted ones is that gotos tend to make semantics non 
compositional:

ie Say S₁ S₂ are two statements in the source language composed together into
a larger source statement S₁ □ S₂ which translates into T₁ ▽ T₂
Egs of S₁ □ S₂ could be ifthenelse sequencing etc
T₁ ▽ T₂ could be assembly code for S₁ followed by code for S₂ (for a compiler)
Or action of S₁ followed by action of S₂ (for interpreter)

Now if S₁ , S₂ has gotos jumping into each other this 
"homomorphic tree transforming model" becomes messed up

However in the face of exceptions² that are quite close to gotos I dont
think this logic would apply

Finally I would like to quote my teacher of programming who made a statement
that altered my next 30 years of programming life:

“What the goto does to control structure, the assignment does to data structure”

¹ The most important decisions for a language designer are what to leave out —
Nicklaus Wirth

² The original objectives of the language (Ada) included reliability,
readability of programs, formality of language definition, and even
simplicity. Gradually these objectives have been sacrificed in favor
of power, supposedly achieved by a plethora of features and notational
conventions, many of them unnecessary and some of them, like exception
handling, even dangerous
C.A.R. Hoare Turing lecture: 
https://amturing.acm.org/award_winners/hoare_4622167.cfm
-- 
https://mail.python.org/mailman/listinfo/python-list