Fwd: Re: Progress migrating cffi and pycparser to libclang

[Etienne Robillard]

Forwarding  this thread to the CFFI developers...

Re Paul: Thanks for your feedback.

My intended audience are developers who can use hg to fetch/build source 
code without pip.


Best regards,

Etienne


 Message transféré 
Sujet : Re: Progress migrating cffi and pycparser to libclang
Date :  Thu, 4 Jan 2018 21:25:27 +
De :Paul Moore 
Pour :  Etienne Robillard 
Copie à :   Python 



On 4 January 2018 at 21:02, Etienne Robillard  wrote:

As a fork/extension for cffi, I have no particular opinion (I'm
unlikely to ever use it). But the advantage of pycparser is that it's
cross-platform and pure Python, so I doubt this will be acceptable for
inclusion into CFFI itself.


CFFI/pycparser definitely need to be patched to support parsing standard C
directives like #define and #include in the ffi.cdef() function.

The easiest solution is to migrate the internal parsing code to libclang, a
state-of-the art C/C++ compiler based on LLVM.


I would strongly object to adding a dependency to cffi that couldn't
be automatically installed by pip as part of standard dependency
resolution (i.e., a PyPI hosted Python project with wheels available
for all common platforms - Linux, Mac OS and Windows). But ultimately
if you're proposing this as a change to cffi, you should be getting
the opinions of the cffi devs, not just asking on this list. (I notice
you have posted to the cffi mailing list, but haven't had any response
yet).

Paul

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

sendline buffer

[Iranna Mathapati]

Hi Team,

I have faced fallowing issue::

 dev.sendline("*show version*")  <<< its printing "show version output"
 dev.sendline("*show module*")   <<< its printing "shoe module output"

*Runing again*

 dev.sendline("show veriosn")   <<< its runing 2nd time again

 dev.before  *output is not consistence means some time it printing
"shoe version output" or some time its printing only "show module output"*

can you please let me know , how to resolve the issue.


Thanks,
Iranna M
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Linux/Windows GUI programming: GUI-fy a CLI using pyInstaller

[Kevin Walzer]

On 1/1/18 11:45 AM, X. wrote:

Ulli Horlacher:

I have to transfer a python 2.7 CLI programm into one with a (simple) GUI.
The program must run on Linux and Windows and must be compilable with
pyinstall, because I have to ship a standalone windows.exe
Any kind of installer is not acceptable.

Reading https://github.com/pyinstaller/pyinstaller/wiki/Supported-Packages
supported GUI packages are PyGTK, PyQt4, PyQt5, wxPython
I have tested tkinter by myself and it works, too.
I do not like GTK and Qt, because they are too complex.

I want to do VERY simple things and I prefer a simple GUI toolkit :-)



me too !



Try easygui:

https://pypi.python.org/pypi/easygui


--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
--
https://mail.python.org/mailman/listinfo/python-list

Re: Re: Progress migrating cffi and pycparser to libclang

[Armin Rigo]

Hi Etienne,

On 5 January 2018 at 10:15, Etienne Robillard  wrote:

> Forwarding  this thread to the CFFI developers...
>
If you're asking whether we could add libclang as a dependency to CFFI, the
answer is no, sorry.

I feel that I've already explained exactly this to you several times in
private e-mails, so I'm writing down this fact here on the public
python-cffi mailing list.  Please stop asking the same question.

For reference, here's my answer again.  CFFI is meant to be used in a
certain way.  I know from experience that a few people keep thinking about
it in a different way---sometimes for good reasons: it is tedious to wrap a
very large library even if it is easy to copy-paste-tweak individual
function definitions.  So to automate the process these people usually want
to parse real .h files, using libclang or better pycparser integration or
something else; and that's cool.  As I said there are already third-party
projects that try to do something similar.  Usually it is never completely
general, but more focused on a particular style of .h files coming from a
particular large project.  Maybe you'll run into similar issues and make
something that works in your case but not in others.  Or maybe you'll
manage to make it general enough.  In all cases this won't be included
inside CFFI, but could nevertheless be a successful separate project.
Please think about it as a project *above* CFFI, maybe something you'll
import and use inside a CFFI build script in order to provide content to
ffi.cdef().


A bientôt,

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

Re: has sourceforge exposed the dirty little secret ?

[Ian Kelly]

On Fri, Jan 5, 2018 at 9:27 AM, Kim of K.  wrote:
>
> "Background
>
> We feel that the world still produces way too much software that is
> frankly substandard. The reasons for this are pretty simple: software
> producers do not pay enough attention [...]"
>
>
> quote from http://texttest.sourceforge.net/index.php?page=about
>
>
> In other words: most sites like SF and github offer tons of crap.
> download and break is the overwhelming theme here.
>
> why is no one complaining ?

It is what it is. What would be the utility of complaining about it?
That's not going to fix anything.

And what does this have to do with Python?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: has sourceforge exposed the dirty little secret ?

[Larry Martell]

On Fri, Jan 5, 2018 at 11:27 AM, Kim of K.  wrote:
>
> "Background
>
> We feel that the world still produces way too much software that is
> frankly substandard. The reasons for this are pretty simple: software
> producers do not pay enough attention [...]"
>
>
> quote from http://texttest.sourceforge.net/index.php?page=about
>
>
> In other words: most sites like SF and github offer tons of crap.
> download and break is the overwhelming theme here.
>
> why is no one complaining ?

You want to complain? Look at these shoes. I've only had them three
weeks and the heels are worn right through.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: has sourceforge exposed the dirty little secret ?

[Grant Edwards]

On 2018-01-05, Kim of K.  wrote:

> In other words: most sites like SF and github offer tons of crap.
> download and break is the overwhelming theme here.
>
> why is no one complaining ?

Because complaining doesn't have any effect?  If you care, shut up and
fix something.

-- 
Grant Edwards   grant.b.edwardsYow! !  I'm in a very
  at   clever and adorable INSANE
  gmail.comASYLUM!!

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

Re: has sourceforge exposed the dirty little secret ?

[John Gordon]

In <15151695.348096.18338899180412170014@welt.netz> "Kim of K." 
 writes:


> In other words: most sites like SF and github offer tons of crap.
> download and break is the overwhelming theme here.

> why is no one complaining ?

90% of everything is crap.  Why should software be any different?

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

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

Re: has sourceforge exposed the dirty little secret ?

[John Gordon]

In <151517608506.368831.5093080329614058603@welt.netz> "Kim of K." 
 writes:

> print(emo('now you see emos'))
> OF COURSE THIS SHIT DOES NOT WORK.

What device did you run this on?  Your average terminal window isn't
going to support emojis...

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

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

Re: has sourceforge exposed the dirty little secret ?

[Chris Angelico]

On Sat, Jan 6, 2018 at 6:02 AM, John Gordon  wrote:
> In <151517608506.368831.5093080329614058603@welt.netz> "Kim of K." 
>  writes:
>
>> print(emo('now you see emos'))
>> OF COURSE THIS SHIT DOES NOT WORK.
>
> What device did you run this on?  Your average terminal window isn't
> going to support emojis...
>

I dunno about yours. Mine does. It's the default XFCE terminal on
Debian GNU/Linux. It doesn't respect the Unicode colour designations
(since it does colour in other ways and it would conflict), but AFAIK
it supports everything else.

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

Re: has sourceforge exposed the dirty little secret ?

[Igor Korot]

Hi,

On Fri, Jan 5, 2018 at 12:58 PM, John Gordon  wrote:
> In <15151695.348096.18338899180412170014@welt.netz> "Kim of K." 
>  writes:
>
>
>> In other words: most sites like SF and github offer tons of crap.
>> download and break is the overwhelming theme here.
>
>> why is no one complaining ?
>
> 90% of everything is crap.  Why should software be any different?

Moreover, most of the time life sucks.
Every morning you have to go to school/work instead of staying home
and enjoying the life.
And you are lucky if the school/work is in the same city where you family is...

Thank you.

>
> --
> John Gordon   A is for Amy, who fell down the stairs
> gor...@panix.com  B is for Basil, assaulted by bears
> -- Edward Gorey, "The Gashlycrumb Tinies"
>
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: has sourceforge exposed the dirty little secret ?

[Igor Korot]

Hi,

On Fri, Jan 5, 2018 at 2:11 PM, Kim of K.  wrote:
> Igor Korot wrote:
>
>> Hi,
>>
>> On Fri, Jan 5, 2018 at 12:58 PM, John Gordon  wrote:
>>> In <15151695.348096.18338899180412170014@welt.netz> "Kim of K." 
>>>  writes:
>>>
>>>
 In other words: most sites like SF and github offer tons of crap.
 download and break is the overwhelming theme here.
>>>
 why is no one complaining ?
>>>
>>> 90% of everything is crap.  Why should software be any different?
>>
>> Moreover, most of the time life sucks.
>> Every morning you have to go to school/work instead of staying home
>> and enjoying the life.
>> And you are lucky if the school/work is in the same city where you family 
>> is...
>>
>> Thank you.
>
>
> let me tell you...
>
> Once you're done with that school crap, you realize it was the pefect waste 
> of time.
>
> At work or in life you need less than 2% of that school crap they funnelled 
> into your head.

I seriously doubt you had the same opinion when you were 7 y.o.
I meant school as "junior/middle/high school/university/college"
school, because you still have to wake up early in the morning and go
to school.

So yes, life sucks most of the time anyway...

Thank you.

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

[OT] Re: has sourceforge exposed the dirty little secret ?

[Michael Torrie]

On 01/05/2018 10:56 AM, Kim of K. wrote:
> wow! 

Yup that's what I said when I read your ramblings.

> even you are defensive about publishing non-working garbage.

Absolutely. You have absolutely no right to make demands of any of the
folks who toss their half-baked personal projects up on sourceforge or
github. What makes you think you do?  This entitlement mentality is
probably the biggest threat to open source software.

Look I can publish non-working garbage if I want. Who are you to say
otherwise?

> btw., I'm trying to fix emojis for so one can use emoji in this group, using a
> python newsreader, of course.

Please, no!  We don't need emoji in this group. Fortunately the vast
majority of posters use plain text (as is the etiquette) and so we don't
have to worry about that kind of nonsense.

Anyway, it sounds like the software you are trying to get running is
defective. Better ask for a refund.

Anyway, time to plonk.

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

Re: is comp.lang.python still the pinnacle of the py community ?

[Ian Kelly]

On Fri, Jan 5, 2018 at 2:06 PM, Kim of K.  wrote:
>
> post frequency is down to a precarious level

It's true that compared to ten years ago, the quantity of posts here
has diminished by a significant fraction, maybe even by an order of
magnitude. This is still a great place for discussion however, as long
as that discussion is about Python.

If this post is (as it appears to be) just a backhanded way of
complaining that not many are responding to your excessive and
trollish posts, then try making higher-quality posts that are actually
on topic.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: is comp.lang.python still the pinnacle of the py community ?

[Gene Heskett]

On Friday 05 January 2018 16:06:34 Kim of K. wrote:

> post frequency is down to a precarious level

Thats because the huge majority of us who are here to learn a tidbit here 
and there, shove that stuff off to a spamassassin training directory, 
where its studied by sa-learn --spam for a second or two, and deleted 
the next day.
.
And your posts are about to be added to that.

Say something helpfull to the python knowledge base, or STFU, this is not 
intended to be your private podium to call the rest of the world 
un-enlightened or names.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Native object exposing buffer protocol

[Rob Gaddi]

I'd like to create a native Python object that exposes the buffer 
protocol.  Basically, something with a ._data member which is a 
bytearray that I can still readinto, make directly into a numpy array, etc.


I can do it by inheriting the entire thing from bytearray directly, but 
that gives me a whole lot of methods that are unsuitable for what I'm 
doing with it, which is reading the contents of a binary file, allowing 
them to be lightly malleable in memory, and then sending them on to a 
device.


Not the end of the world (the file's less than 2KB), but it seems like 
something that should be doable easily without having to throw around a 
lot of extraneous copies.


--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

Python Inheritance Terminology

[Irv Kalb]

I'm doing some writing for an upcoming course on OOP using Python.  

I have been doing OOP programming for many years in many different languages, 
and I want make sure that I'm using the appropriate terminology in Python.  I'd 
like to know if there are "official" or even standard terms that are used to 
describe a class that is inherited from, and the class that is doing the 
inheriting.  From my reading (especially the PSF docs.python.org 
), it looks like the terms would be "base class" and 
"subclass".

However, in books about Python and other languages, I have also seen the terms:

base class & derived class
parent class & child class
superclass & subclass

So, are base class & subclass the proper terms?

Thanks,

Irv




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

Re: Native object exposing buffer protocol

[breamoreboy]

On Saturday, January 6, 2018 at 12:02:18 AM UTC, Rob Gaddi wrote:
> I'd like to create a native Python object that exposes the buffer 
> protocol.  Basically, something with a ._data member which is a 
> bytearray that I can still readinto, make directly into a numpy array, etc.
> 
> I can do it by inheriting the entire thing from bytearray directly, but 
> that gives me a whole lot of methods that are unsuitable for what I'm 
> doing with it, which is reading the contents of a binary file, allowing 
> them to be lightly malleable in memory, and then sending them on to a 
> device.
> 
> Not the end of the world (the file's less than 2KB), but it seems like 
> something that should be doable easily without having to throw around a 
> lot of extraneous copies.
> 
> -- 
> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> Email address domain is currently out of order.  See above to fix.

Could you use memoryviews instead of making the copies?

--
Kindest regards.

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

Re: Native object exposing buffer protocol

[Ben Finney via Python-list]

Rob Gaddi  writes:

> I'd like to create a native Python object that exposes the buffer
> protocol.  Basically, something with a ._data member which is a
> bytearray that I can still readinto, make directly into a numpy array,
> etc.

The “etc.” seems pretty important, there. You want the behaviour of
‘bytearray’ without actually inheriting that behaviour from the
‘bytearray’ type.

So, it seems your options are:

* Enumerate all the things, specifically, that you do want your new type
  to do. Don't hide anything in “etc.”, so that you know exactly what
  behaviours need to be implemented. Implement all those behaviours,
  without benefit of inheriting from ‘bytearray’.

* Inherit from ‘bytearray’, but ameliorate the problems you want to
  avoid. This will require enumerating all those problems, so that you
  can know whether you have avoided them. Don't hide any of them in an
  “etc.”.

> Not the end of the world (the file's less than 2KB), but it seems like
> something that should be doable easily without having to throw around
> a lot of extraneous copies.

I look forward to your report from having tried it :-)

-- 
 \  “A lie can be told in a few words. Debunking that lie can take |
  `\   pages. That is why my book… is five hundred pages long.” —Chris |
_o__)Rodda, 2011-05-05 |
Ben Finney

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

Re: Python Inheritance Terminology

[Ben Finney]

Irv Kalb  writes:

> I'm doing some writing for an upcoming course on OOP using Python.  

Welcome, and congratulations for using Python in this work.

> I'd like to know if there are "official" or even standard terms that
> are used to describe a class that is inherited from, and the class
> that is doing the inheriting. From my reading (especially the PSF
> docs.python.org ), it looks like the terms
> would be "base class" and "subclass".

Standard (“official”) terms are most likely to be had from the language
reference http://docs.python.org/3/reference/>. I would recommend
the glossary http://docs.python.org/3/glossary.html>, but with the
caveat that many flaws have been found in recent years.

> However, in books about Python and other languages, I have also seen the 
> terms:
>
> base class & derived class
> parent class & child class
> superclass & subclass

The only term I take issue with there is “superclass”. In a
multiple-inheritance system, such as provided by Python, the superclass
is *not* necessarily the base class. See this article from 2011
https://rhettinger.wordpress.com/2011/05/26/super-considered-super/>.

> So, are base class & subclass the proper terms?

In my opinion you will be correct to use those terms. Which is not to
say that other terms aren't also good.

-- 
 \“The greatest tragedy in mankind's entire history may be the |
  `\   hijacking of morality by religion.” —Arthur C. Clarke, 1991 |
_o__)  |
Ben Finney

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

Re: has sourceforge exposed the dirty little secret ?

[Richard Damon]

On 1/5/18 3:11 PM, Kim of K. wrote:

let me tell you...

Once you're done with that school crap, you realize it was the pefect waste of 
time.

At work or in life you need less than 2% of that school crap they funnelled 
into your head.


My experience is that while I found little use for much of the 'facts' 
that I learned in school, there has been a lot of use for the basic 
methods that were learned while processing those facts in school.


--
Richard Damon

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