Re: Dependency injection: overriding defaults

[dieter]

Victor Porton  writes:

> I am writing a library, a command line utility which uses the library, and a 
> I am going to use dependency_injector package.
>
> Consider loggers:
>
> For the core library the logger should default to stderr.
>
> For the command line utility, we use the default logger of the library.
>
> For the server, the log should go to a file (not to stderr).
>
> Question: How to profoundly make my software to use the appropriate logger, 
> dependently on whether it is a command line utility or the daemon?

I would distinguish between the common library and distinct
applications (command line utility, daemon). The applications
configure the logging system (differently) while the library uses
uniform logging calls.

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

Re: Object-oriented gettext

[Victor Porton]

Victor Porton wrote:

> I want to write a multiuser application which uses multiple languages (one
> language for logging and a language per user).
> 
> https://docs.python.org/3/library/gettext.html describes a procedural
> gettext interface. The language needs to be switched before each gettext()
> call.
> 
> I want an object oriented interface like:
> 
> english.gettext("Word") == "Word"
> russian.gettext("Word") == "Слово"
> 
> That is, I do no want to write any language-switching code, but the
> language should depend on the object (like "english" and "russian" in the
> above example).
> 
> What is the best way to do this?
> 
> Should I write an object-oriented wrapper around gettext package?


Oh, I see that gettext.translation() seems to do the job.

-- 
Victor Porton - http://portonvictor.org
-- 
https://mail.python.org/mailman/listinfo/python-list

Advice on where to define dependency injection providers

[Victor Porton]

I define ExecutionContext in xmlboiler.core.execution_context module.

ExecutionContext is meant to contain a common "environment" suitable for 
different kinds of tasks.

Currently ExecutionContext contains a logger and a translator of messages:

class ExecutionContext(object):
def __init__(self, logger, translations):
"""
:param logger: logger
:param translations: usually should be gettext.GNUTranslations
"""
self.logger = logger
self.translations = translations

Now I want to define some "provides" using dependency_injector.providers 
module.

Where (in which module) should I define default factories for loggers, 
translations, and execution contexts? (Default logger should log to stderr, 
default translations should respect LANG environment variable.)

The only quite clear thing is that providers should be defined somewhere in 
xmlboiler.core.* namespace, because it is the namespace for the core library 
(to be used by several applications).

Should I define providers in xmlboiler.core.execution_context module or in 
something like xmlboiler.core.execution_context_build, or maybe in something 
like xmlboiler.core.providers.execution_context?

-- 
Victor Porton - http://portonvictor.org
-- 
https://mail.python.org/mailman/listinfo/python-list

Object-oriented gettext

[Victor Porton]

I want to write a multiuser application which uses multiple languages (one 
language for logging and a language per user).

https://docs.python.org/3/library/gettext.html describes a procedural 
gettext interface. The language needs to be switched before each gettext() 
call.

I want an object oriented interface like:

english.gettext("Word") == "Word"
russian.gettext("Word") == "Слово"

That is, I do no want to write any language-switching code, but the language 
should depend on the object (like "english" and "russian" in the above 
example).

What is the best way to do this?

Should I write an object-oriented wrapper around gettext package?

-- 
Victor Porton - http://portonvictor.org
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help to debug my free library

[Rustom Mody]

On Thursday, February 1, 2018 at 1:11:50 AM UTC+5:30, Victor Porton wrote:
> wxjmfauth wrote:
> 
> > Le mercredi 31 janvier 2018 20:13:06 UTC+1, Chris Angelico a écrit :
> >> On Thu, Feb 1, 2018 at 5:58 AM, Victor Porton  wrote:
> >> > LibComCom is a C library which passes a string as stdin of an OS
> >> > command and stores its stdout in another string.
> >> 
> >> Something like the built-in subprocess module does?
> >> 
> >> ChrisA
> > 
> > Do you mean the buggy subprocess module (coding of characters) ?
> > Yes, there is a working workaround : QtCore.QProcess().
> 
> Please elaborate: which bugs it has? in which versions?
> 

jmf is a pillar of the community who runs a campaign for equity and justice

In particular that a $ costs just 0x24  (6 significant bits)
whereas a € costs 0x20AC (14 bits) and (3 bytes in UTF-8 n0xE2 0x82 0xAC)
is highly unacceptable to him and he is taking it up with the UN.

We must heartily support him in this noble endeavour

[And when you get a chance to get your word in edgeways do ask him what this
has to do with python]


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

Dependency injection: overriding defaults

[Victor Porton]

I am writing a library, a command line utility which uses the library, and a 
daemon which uses the library.

I am going to use dependency_injector package.

Consider loggers:

For the core library the logger should default to stderr.

For the command line utility, we use the default logger of the library.

For the server, the log should go to a file (not to stderr).

Question: How to profoundly make my software to use the appropriate logger, 
dependently on whether it is a command line utility or the daemon?

-- 
Victor Porton - http://portonvictor.org
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Handle SIGINT in C and Python (Posting On Python-List Prohibited)

[eryk sun]

On Thu, Feb 1, 2018 at 4:57 AM, Victor Porton  wrote:
> Lawrence D’Oliveiro wrote:
>
>> On Thursday, February 1, 2018 at 8:10:24 AM UTC+13, Victor Porton wrote:
>>> Lawrence D’Oliveiro wrote:
>>>
 The usual behaviour for POSIX is that the call is aborted with EINTR
 after you get the signal.
>>>
>>> That poll() is interrupted does not imply that Python will run its
>>> pythonic signal handler at the point of interruption. That is a problem.
>>
>> * Python calls poll()
>> * poll() aborted with EINTR
>> * Python runs your signal handler
>>
>> Versus native C code:
>>
>> * your code calls poll()
>> * poll() aborted with EINTR
>> * your signal handler is run
>>
>> Where is there a fundamental difference?
>
> I meant to call poll() from C code, not Python code. In this case when
> poll() is aborted with EINTR, the pythonic signal handler does not run.

An extension module should call PyErr_CheckSignals [1] when
interrupted by EINTR. For example, here's the loop used to call poll()
in the standard-library select module:

async_err = 0;
do {
Py_BEGIN_ALLOW_THREADS
errno = 0;
poll_result = poll(self->ufds, self->ufd_len, (int)ms);
Py_END_ALLOW_THREADS

if (errno != EINTR)
break;

/* poll() was interrupted by a signal */
if (PyErr_CheckSignals()) {
async_err = 1;
break;
}

if (timeout >= 0) {
timeout = deadline - _PyTime_GetMonotonicClock();
if (timeout < 0) {
poll_result = 0;
break;
}
ms = _PyTime_AsMilliseconds(timeout, _PyTime_ROUND_CEILING);
/* retry poll() with the recomputed timeout */
}
} while (1);

self->poll_running = 0;

if (poll_result < 0) {
if (!async_err)
PyErr_SetFromErrno(PyExc_OSError);
return NULL;
}

[1]: https://docs.python.org/3/c-api/exceptions.html#c.PyErr_CheckSignals
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Handle SIGINT in C and Python (Posting On Python-List Prohibited)

[Victor Porton]

Lawrence D’Oliveiro wrote:

> On Thursday, February 1, 2018 at 5:57:58 PM UTC+13, Victor Porton wrote:
>> I meant to call poll() from C code, not Python code.
> 
> Do you need to use C code at all? Python is quite capable of handling this
> .

I already concluded that I can use Popen.communicate() instead of my 
library.

So the issue is closed.

-- 
Victor Porton - http://portonvictor.org
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Dutch Reach [was Re: Where has the practice of sending screen shots as source code come from?]

[Rustom Mody]

On Wednesday, January 31, 2018 at 11:17:45 PM UTC+5:30, Adriaan Renting wrote:
> I am Dutch and after googling the term, I can confirm that the "Dutch
> Reach" is taught in driving school here.
> I was taught this maneuvre when getting my licence 20 years ago.

 

> And in the Netherlands, we largely solve this problem by just having
> everyone on a bike. ;-)
> (We do ride cars as well)

Good to have an existence proof for civilization

Topic remains wildly OT until somebody adds one more piece to the jigsaw:
"…statistical evidence that the practice of 'dutch-reach' has significantly
reduced the instances of dooring…"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Handle SIGINT in C and Python (Posting On Python-List Prohibited)

[Victor Porton]

Lawrence D’Oliveiro wrote:

> On Thursday, February 1, 2018 at 8:10:24 AM UTC+13, Victor Porton wrote:
>> Lawrence D’Oliveiro wrote:
>> 
>>> The usual behaviour for POSIX is that the call is aborted with EINTR
>>> after you get the signal.
>> 
>> That poll() is interrupted does not imply that Python will run its
>> pythonic signal handler at the point of interruption. That is a problem.
> 
> * Python calls poll()
> * poll() aborted with EINTR
> * Python runs your signal handler
> 
> Versus native C code:
> 
> * your code calls poll()
> * poll() aborted with EINTR
> * your signal handler is run
> 
> Where is there a fundamental difference?

I meant to call poll() from C code, not Python code. In this case when 
poll() is aborted with EINTR, the pythonic signal handler does not run.

-- 
Victor Porton - http://portonvictor.org
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help to debug my free library

[Victor Porton]

Dennis Lee Bieber wrote:

> On Wed, 31 Jan 2018 20:58:56 +0200, Victor Porton 
> declaimed the following:
> 
>>LibComCom is a C library which passes a string as stdin of an OS command
>>and stores its stdout in another string.
>>
>>I wrote this library recently:
>>https://github.com/vporton/libcomcom
>>
>>Complete docs are available at
>>https://vporton.github.io/libcomcom-docs/
>>
>>Now I am trying to make Python bindings to the library:
>>https://github.com/vporton/libcomcom-python
>>
> 
> Debug -- no help, I'm not a fluent Linux programmer...
> 
> But based upon the description of this library, I would have to ask:
> 
> "What does this library provide that isn't already in the Python standard
> library?"
> 
> "Why would I want to use this library instead of, say
> subprocess.Popen().communicate()?" (or the older Popen* family)
> 
> {Though .communicate() is a one-shot call -- sends one packet to
> subprocess' stdin, reads to EOF, and waits for subprocess to terminate. If
> one needs interactive control, one needs explicit write/read calls,
> although those can deadlock if the caller and subprocess aren't written
> for such interaction}

If it "sends one packet", this would lead to a deadlock (even for "cat" 
command). Hopefully, you are wrong here.

I found that Popen.communicate() seems to solve my problem. (Previously I 
programmed in Java and found no native solution. For this reason I created 
my LibComCom.)

-- 
Victor Porton - http://portonvictor.org
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Dutch Reach [was Re: Where has the practice of sending screen shots as source code come from?]

[Steven D'Aprano]

On Wed, 31 Jan 2018 16:14:45 +0100, Adriaan Renting wrote:

> I am Dutch and after googling the term, I can confirm that the "Dutch
> Reach" is taught in driving school here. I was taught this maneuvre when
> getting my licence 20 years ago.

Thanks for the data point. Was it a requirement of the driving test?


> If it is actually used by a lot of people, I can't confirm. I use it
> most of the time, depending on what model car I'm driving. (wether the
> door handles are easy to reach/operate).
> 
> The way I was taught, you have to check your mirrors and then use it to
> force you to check your blind spot, 

But it doesn't force you to do anything - reaching over to the door 
handle with your opposite hand doesn't make you look over your shoulder.

And given that you are stopped, any vehicle travelling in your blind spot 
is going to only be there for a fraction of a second. If you are taking a 
genuine careful look for traffic, rather than a quick careless glance, 
you'll see any vehicle in your blind spot because it won't be in the 
blind spot for long.


> mostly to avoid cars hitting
> you/your door on the drivers side.

Yes, this is also a big problem. I used to work with somebody who came 
within a fraction of a centimetre of taking a woman's arm off when she 
suddenly opened the door to her car as he drove past in a narrow road. He 
took the door completely off.


-- 
Steve

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

[RELEASE] Python 3.7.0b1 is now available for testing

[Ned Deily]

On behalf of the Python development community and the Python 3.7 release
team, I'm happy to announce the availability of Python 3.7.0b1.  b1 is
the first of four planned beta releases of Python 3.7, the next major
release of Python, and marks the end of the feature development phase
for 3.7.  You can find Python 3.7.0b1 here:

https://www.python.org/downloads/release/python-370b1/

Among the new major new features in Python 3.7 are:

* PEP 538, Coercing the legacy C locale to a UTF-8 based locale
* PEP 539, A New C-API for Thread-Local Storage in CPython
* PEP 540, UTF-8 mode
* PEP 552, Deterministic pyc
* PEP 553, Built-in breakpoint()
* PEP 557, Data Classes
* PEP 560, Core support for typing module and generic types
* PEP 562, Module __getattr__ and __dir__
* PEP 563, Postponed Evaluation of Annotations
* PEP 564, Time functions with nanosecond resolution
* PEP 565, Show DeprecationWarning in __main__
* PEP 567, Context Variables

Please see "What’s New In Python 3.7" for more information.
Additional documentation for these features and for other changes
will be provided during the beta phase.

https://docs.python.org/3.7/whatsnew/3.7.html

Beta releases are intended to give you the opportunity to test new
features and bug fixes and to prepare their projects to support the
new feature release. We strongly encourage you to test your projects
with 3.7 during the beta phase and report issues found to
https://bugs.python.org as soon as possible.

While the release is feature complete entering the beta phase, it is
possible that features may be modified or, in rare cases, deleted up
until the start of the release candidate phase (2018-05-21). Our goal
is have no ABI changes after beta 3 and no code changes after rc1.
To achieve that, it will be extremely important to get as much exposure
for 3.7 as possible during the beta phase.

Attention macOS users: with 3.7.0b1, we are providing a choice of
two binary installers.  The new variant provides a 64-bit-only
version for macOS 10.9 and later systems; this variant also now
includes its own built-in version of Tcl/Tk 8.6.  We welcome your
feedback.

Please keep in mind that this is a preview release and its use is
not recommended for production environments.

The next planned release of Python 3.7 will be 3.7.0b2, currently
scheduled for 2018-02-26. More information about the release schedule
can be found here:

https://www.python.org/dev/peps/pep-0537/

--
  Ned Deily
  n...@python.org -- []

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

Re: Help to debug my free library

[Chris Angelico]

On Thu, Feb 1, 2018 at 9:31 AM, alister via Python-list
 wrote:
> On Thu, 01 Feb 2018 06:48:03 +1100, Chris Angelico wrote:
>
>> On Thu, Feb 1, 2018 at 6:41 AM, Victor Porton  wrote:
>>> wxjmfa...@gmail.com wrote:
>>>
 Le mercredi 31 janvier 2018 20:13:06 UTC+1, Chris Angelico a écrit :
> On Thu, Feb 1, 2018 at 5:58 AM, Victor Porton 
> wrote:
> > LibComCom is a C library which passes a string as stdin of an OS
> > command and stores its stdout in another string.
>
> Something like the built-in subprocess module does?
>
> ChrisA

 Do you mean the buggy subprocess module (coding of characters) ?
>>>
>>> Please elaborate: which bugs it has? in which versions?
>>>
 Yes, there is a working workaround : QtCore.QProcess().
>>
>> Ignore jmf, he wouldn't know a bug if he were eating it for dinner. His
>> posts are blocked on the mailing list, and you'd do well to just plonk
>> him in your newsreader.
>>
>> ChrisA
>
>
> I disagree jmf's posts are worth reading, if you find yourself agreeing
> with him you know you have got something wrong.
>

Heh. That would be useful if he ever actually posted anything other
than "Python is buggy". I'm pretty sure I've already read everything
he actually has to say.

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

Re: Help to debug my free library

[alister via Python-list]

On Thu, 01 Feb 2018 06:48:03 +1100, Chris Angelico wrote:

> On Thu, Feb 1, 2018 at 6:41 AM, Victor Porton  wrote:
>> wxjmfa...@gmail.com wrote:
>>
>>> Le mercredi 31 janvier 2018 20:13:06 UTC+1, Chris Angelico a écrit :
 On Thu, Feb 1, 2018 at 5:58 AM, Victor Porton 
 wrote:
 > LibComCom is a C library which passes a string as stdin of an OS
 > command and stores its stdout in another string.

 Something like the built-in subprocess module does?

 ChrisA
>>>
>>> Do you mean the buggy subprocess module (coding of characters) ?
>>
>> Please elaborate: which bugs it has? in which versions?
>>
>>> Yes, there is a working workaround : QtCore.QProcess().
> 
> Ignore jmf, he wouldn't know a bug if he were eating it for dinner. His
> posts are blocked on the mailing list, and you'd do well to just plonk
> him in your newsreader.
> 
> ChrisA


I disagree jmf's posts are worth reading, if you find yourself agreeing 
with him you know you have got something wrong.


-- 
Bernard Shaw is an excellent man; he has not an enemy in the world, and
none of his friends like him either.
-- Oscar Wilde
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help to debug my free library

[breamoreboy]

On Wednesday, January 31, 2018 at 7:41:50 PM UTC, Victor Porton wrote:
> wxjmfa...@gmail.com wrote:
> 
> > Le mercredi 31 janvier 2018 20:13:06 UTC+1, Chris Angelico a écrit :
> >> On Thu, Feb 1, 2018 at 5:58 AM, Victor Porton wrote:
> >> > LibComCom is a C library which passes a string as stdin of an OS
> >> > command and stores its stdout in another string.
> >> 
> >> Something like the built-in subprocess module does?
> >> 
> >> ChrisA
> > 
> > Do you mean the buggy subprocess module (coding of characters) ?
> 
> Please elaborate: which bugs it has? in which versions?
> 
> > Yes, there is a working workaround : QtCore.QProcess().
> -- 
> Victor Porton - http://portonvictor.org

You've now met the RUE, the Resident Unicode Expert.  For years he's been 
stating that the Python 3 Flexible String Representation is buggy, to the 
extent that Python 3.6.2 is unusable on Windows.  Strangely he cannot produce a 
shred of evidence to support his case so feel free to ignore him.

--
Kindest regards.

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

Re: Help to debug my free library

[Chris Angelico]

On Thu, Feb 1, 2018 at 6:41 AM, Victor Porton  wrote:
> wxjmfa...@gmail.com wrote:
>
>> Le mercredi 31 janvier 2018 20:13:06 UTC+1, Chris Angelico a écrit :
>>> On Thu, Feb 1, 2018 at 5:58 AM, Victor Porton  wrote:
>>> > LibComCom is a C library which passes a string as stdin of an OS
>>> > command and stores its stdout in another string.
>>>
>>> Something like the built-in subprocess module does?
>>>
>>> ChrisA
>>
>> Do you mean the buggy subprocess module (coding of characters) ?
>
> Please elaborate: which bugs it has? in which versions?
>
>> Yes, there is a working workaround : QtCore.QProcess().

Ignore jmf, he wouldn't know a bug if he were eating it for dinner.
His posts are blocked on the mailing list, and you'd do well to just
plonk him in your newsreader.

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

Re: Help to debug my free library

[Chris Angelico]

On Thu, Feb 1, 2018 at 6:26 AM, Victor Porton  wrote:
> Chris Angelico wrote:
>
>> On Thu, Feb 1, 2018 at 5:58 AM, Victor Porton  wrote:
>>> LibComCom is a C library which passes a string as stdin of an OS command
>>> and stores its stdout in another string.
>>
>> Something like the built-in subprocess module does?
>
> I was going to write: "It seems that subprocess module can cause deadlocks.
> For example, if it first writes a long string to "cat" command input (going
> to read cat's stdout later), then "cat" would block because its output is
> not read while writing input."
>
> But after reading the docs it seems that Popen.communicate() does the job.
>
> Well, I first wrote in Java. For Java there was no ready solution. Later I
> switched to Python and haven't checked the standard libraries.
>
> So, please help me to make sure if Popen.communicate() is a solution for my
> problem (namely that it does not deadlock, as in "cat" example above).
>
> I am interested in both Python 2.7 and 3.x.

I believe communicate() is indeed safe for this. It does retain all
data in memory, so with arbitrarily large output it may be better to
use a pipe and read from it progressively (similarly if the program's
going to run for a long time; communicate() will wait for the process
to terminate before giving you any output), but it won't just
deadlock.

Even if what you want can't be done with communicate(), I would
definitely recommend looking at the subprocess module. Worst case, you
do in Python what your C library is doing: create pipes to communicate
with the process. It's a lot easier in Python than in C, but the logic
would be similar.

Bonus: subprocess is available on all supported platforms (most
notably Windows and POSIX, which are drastically different; there are
a handful of Windows-only or Unix-only features, but the core is all
identical, despite the implementation differing), and you can still
support 2.7, although you have to forego the new and improved API in
Python 3.5+.

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

Re: Help to debug my free library

[Victor Porton]

wxjmfa...@gmail.com wrote:

> Le mercredi 31 janvier 2018 20:13:06 UTC+1, Chris Angelico a écrit :
>> On Thu, Feb 1, 2018 at 5:58 AM, Victor Porton  wrote:
>> > LibComCom is a C library which passes a string as stdin of an OS
>> > command and stores its stdout in another string.
>> 
>> Something like the built-in subprocess module does?
>> 
>> ChrisA
> 
> Do you mean the buggy subprocess module (coding of characters) ?

Please elaborate: which bugs it has? in which versions?

> Yes, there is a working workaround : QtCore.QProcess().
-- 
Victor Porton - http://portonvictor.org
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help to debug my free library

[Victor Porton]

Chris Angelico wrote:

> On Thu, Feb 1, 2018 at 5:58 AM, Victor Porton  wrote:
>> LibComCom is a C library which passes a string as stdin of an OS command
>> and stores its stdout in another string.
> 
> Something like the built-in subprocess module does?

I was going to write: "It seems that subprocess module can cause deadlocks. 
For example, if it first writes a long string to "cat" command input (going 
to read cat's stdout later), then "cat" would block because its output is 
not read while writing input."

But after reading the docs it seems that Popen.communicate() does the job.

Well, I first wrote in Java. For Java there was no ready solution. Later I 
switched to Python and haven't checked the standard libraries.

So, please help me to make sure if Popen.communicate() is a solution for my 
problem (namely that it does not deadlock, as in "cat" example above).

I am interested in both Python 2.7 and 3.x.

> ChrisA

-- 
Victor Porton - http://portonvictor.org
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Handle SIGINT in C and Python (Posting On Python-List Prohibited)

[Victor Porton]

Lawrence D’Oliveiro wrote:

> On Wednesday, January 31, 2018 at 9:55:45 PM UTC+13, Victor Porton wrote:
>> Lawrence D’Oliveiro wrote:
>> 
>>> On Wednesday, January 31, 2018 at 8:58:18 PM UTC+13, Victor Porton
>>> wrote:
 For this reason I
 cannot use Python signals because "A Python signal handler does not get
 executed inside the low-level (C) signal handler. Instead, the
 low-level signal handler sets a flag which tells the virtual machine to
 execute the corresponding Python signal handler at a later point(for
 example at the next bytecode instruction)."
>>> 
>>> Why is that a problem?
>> 
>> As I already said, I need to handle the signal (SIGCHLD) while poll()
>> waits for i/o.
> 
> The usual behaviour for POSIX is that the call is aborted with EINTR after
> you get the signal.

That poll() is interrupted does not imply that Python will run its pythonic 
signal handler at the point of interruption. That is a problem.

-- 
Victor Porton - http://portonvictor.org
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help to debug my free library

[Chris Angelico]

On Thu, Feb 1, 2018 at 5:58 AM, Victor Porton  wrote:
> LibComCom is a C library which passes a string as stdin of an OS command and
> stores its stdout in another string.

Something like the built-in subprocess module does?

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

Help to debug my free library

[Victor Porton]

LibComCom is a C library which passes a string as stdin of an OS command and 
stores its stdout in another string.

I wrote this library recently:
https://github.com/vporton/libcomcom

Complete docs are available at
https://vporton.github.io/libcomcom-docs/

Now I am trying to make Python bindings to the library:
https://github.com/vporton/libcomcom-python

I use CFFI (API level).

However testing my Python bindings segfaults in an unknown reason. Please 
help to debug the following:

$ LD_LIBRARY_PATH=.:/usr/local/lib:/usr/lib:/lib \
  PYTHONPATH=build/lib.linux-x86_64-2.7/ python test2.py 
Traceback (most recent call last):
Segmentation fault

(here libcomcom.so is installed in /usr/local/lib)

-- 
Victor Porton - http://portonvictor.org
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for info

[Joel Goldstick]

On Wed, Jan 31, 2018 at 10:55 AM,  wrote:

> from where we learn python for free of cost. i am begineer in python.plzz
> help me
> --
> https://mail.python.org/mailman/listinfo/python-list
>

Start with python.org tutorial pages

-- 
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays
-- 
https://mail.python.org/mailman/listinfo/python-list

for info

[harnali70]

from where we learn python for free of cost. i am begineer in python.plzz help 
me
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Dutch Reach [was Re: Where has the practice of sending screen shots as source code come from?]

[Adriaan Renting]

Adriaan Renting| Email: rent...@astron.nl
Software Engineer Radio Observatory
ASTRON | Phone: +31 521 595 100 (797 direct)
P.O. Box 2 | GSM:   +31 6 24 25 17 28
NL-7990 AA Dwingeloo   | FAX:   +31 521 595 101
The Netherlands| Web: http://www.astron.nl/~renting/



>>> On 30-1-2018 at 19:22, MRAB  wrote: 
> On 2018-01-30 15:39, Steven D'Aprano wrote:
>> On Tue, 30 Jan 2018 05:48:15 -0800, Rustom Mody wrote:
>> 
>> [...]
 Ah, yes, the Dutch Reach. That would be like the French Pox
(which
 isn't French), the Spanish Flu (that didn't start in Spain), the
 Jerusalem artichoke (which is neither an artichoke nor from
Jerusalem),
 and the turkey (the bird, which has nothing to do with Turkey,
the
 country).
 
 This technique is neither taught nor commonly used used by the
Dutch:
 apparently some Americans decided that because the Netherlands has
a
 lot of cyclists, they'll say its Dutch.
>>> 
>>> reference please
>> 
>> The onus should be on those who claim that the technique actually is
used
>> by the Dutch. Anecdotally, the Dutch people I've spoken to on the
>> Internet had no idea that this technique even existed.
>> 
> Do we know of anyone who's Dutch and frequents a Python newsgroup?
:-)
> 

I am Dutch and after googling the term, I can confirm that the "Dutch
Reach" is taught in driving school here.
I was taught this maneuvre when getting my licence 20 years ago.

If it is actually used by a lot of people, I can't confirm.
I use it most of the time, depending on what model car I'm driving.
(wether the door handles are easy to reach/operate).

The way I was taught, you have to check your mirrors and then use it to
force you to check your blind spot, mostly to avoid cars hitting
you/your door on the drivers side.
I don't remember any specific mention of bicycles or use by passengers
of this maneuvre.

I think in general cars are a much larger danger than bicycles:
- Faster: More likely have not been seen by you or not see you.
- More mass: Damage much bigger. (yes also depends on the square of the
velocity).
- Worse perception. A Bicyclist usually has unrestricted hearing and
vision around themselves, and is much more likely to have noticed the
person in the car.
- Bicyclists will understand they are vulnerable and be more careful.

Motorbikes and mopeds are the hardest for me, as they are more likely
to be missed due to their speed.

And in the Netherlands, we largely solve this problem by just having
everyone on a bike. ;-)
(We do ride cars as well)

If you want to know more about how the Dutch go about their cycling and
images of Dutch infrastructure, then I suggest the BicycleDutch Youtube
channel, for example this video:
https://www.youtube.com/watch?v=swqaAIkGtpA

The difference with a lot of other places, is that we use bicycles as a
means of transport, not as an excercise/sports device.
In general for distances < 15km (10 miles) and anything up to about the
size of a couch.

> [snip]

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

Re: Where has the practice of sending screen shots as source code come from?

[alister via Python-list]

On Tue, 30 Jan 2018 21:22:39 +0100, Jugurtha Hadjar wrote:

> On 01/29/2018 03:48 PM, alister via Python-list wrote:
>> On Mon, 29 Jan 2018 15:20:06 +0100, Jugurtha Hadjar wrote:
>>
>>> On 01/28/2018 04:43 PM, Skip Montanaro wrote:
 I've never been a Windows user, but at my current job, Windows is
 core to just about everything, so I am forced to use it for a lot of
 stuff (Outlook, SQL Server, Excel, etc).
>>> I was hired at a startup which made a good impression on me and I was
>>> eager to start working. I checked in for my first day, signed the
>>> paperwork, then the CTO showed me around and told me "Here's your
>>> laptop, you can install Windows and I'll check in with you later".
>>> Life started draining out of my body and my mind was racing in all
>>> directions before he even finished his sentence. I felt tricked: I was
>>> hired based on a test and the file I've received was a *.tar.gz* and
>>> it made me happy because I assumed they were a NIX shop..
>>>
>>> I was considering how I should go about quitting gracefully. I have
>>> stopped using Windows in 2008 for psychological reasons for it made me
>>> really anxious, irritable, angry, and tense to the point of abusing
>>> hardware with low kicks and punches which was not very healthy or
>>> sane. It was only when I switched OS that this behavior stopped. There
>>> was no way I would be going back to my bully.
>>>
>>> The CTO then said "Sorry.. I meant Ubuntu." and seeing my pale face,
>>> he said in a reassuring tone "Don't be afraid, there are no Windows
>>> machines here." which brought me back to life.
>>>
>>> I hope to be as brave as you some day.
>> Any Vacancies whatever they do I am sure I can learn :-)
>>
>>
>>
>>
> We're hiring all the good (technical and human side) people we can
> find/afford. It's a small startup that helps its clients improve
> business using machine learning. We're in Algiers, Algeria and Paris,
> France.

bit of a commute from Sevenage in UK



-- 
A pencil with no point needs no eraser.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Package containing C sources (Posting On Python-List Prohibited)

[Vincent Vande Vyvre]

Le 31/01/18 à 07:52, Victor Porton a écrit :

Lawrence D’Oliveiro wrote:


On Wednesday, January 31, 2018 at 6:13:00 PM UTC+13, Victor Porton wrote:

I am going to create a Python wrapper around a generally useful C
library. So the wrapper needs to contain some C code to glue them
together.

Not necessarily. It’s often possible to implement such a wrapper entirely
in Python, using ctypes .

But if I will find that I need C code, do I need to package it separately?

So I would get three packages: the C library, the C wrapper for Python, and
the Python code.

Can this be done with just two packages: the C library and C wrapper and
Python in one package?


Hi,

You can made an all-in-one package without problems.


Vincent

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

Install PyDev package or any other regular package during runtime in the python project

[user2301]

I am trying to dynamically install PyDev package at runtime. I have a PyDev 
project created in eclipse. I have a PyDev package on network location. Based 
on some configuration and input in my PyDev project, I want to install and load 
the PyDev package from network location. The classes contained in modules 
within this package will be used later. How can I install the regular(PyDev 
package) at runtime?. Is it possible to install the package at runtime? To 
which location I have to add this package ? project root directory or sys.path?

What I had done: I had created the PyDev package inside my project root 
directory. Then import the module in the package dynamically.

from pydoc import locate

#package already created/installed within the project root
def load(self):
  myclass = locate('package.module.classname') #importing module dynamically
  instance = myclass()

what I need to do:

from pydoc import locate

#package not yet installed within the project root
def load(self):
  # install the module first from given network path? how?
  myclass = locate('package.module.classname') #importing module 
 dynamically
  instance = myclass()
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyPy support breaking CPython compatibility?

[Ned Batchelder]

On 1/30/18 3:58 PM, Etienne Robillard wrote:

Hi Ned,


Le 2018-01-30 à 15:14, Ned Batchelder a écrit :
I'm curious what you had to change for PyPy? (Unless it's a Py2/Py3 
thing as Chris mentions.) 


Please take a look at the changesets:

https://bitbucket.org/tkadm30/libschevo/commits/745d1aeab5c6ee0d336790cf13d16f327e10c2f8 

https://bitbucket.org/tkadm30/libdurus/commits/875636e9b6caa840fd50ca87d69217d87fc06f43 



In short, it seems PyPy automagically adds a __weakref__ attribute to 
__slots__, causing the CPython interpreter to raise a TypeError...


PyPy and CPython are separate implementations, that never mix: you run 
your code in one, or in the other.  How can PyPy do something at runtime 
(add a __weakref__ attribute to __slots__) that can cause CPython to do 
something at runtime (raise a TypeError)?


A small demonstration case would be very helpful for figuring out what 
is going on.


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

Re: Import statements and multiprocessing

[Nicholas Cole]

On Tue, Jan 30, 2018 at 7:26 PM, Terry Reedy  wrote:
> On 1/30/2018 10:54 AM, Nicholas Cole wrote:
>
>> I have a strange problem on python 3.6.1
>
> [involving multiprocessing]

Interestingly it seems to have been a very subtle circular import
problem that was showing up only in multiprocessing, and which wasn't
raising an exception at the time of the import.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyPy support breaking CPython compatibility?

[Chris Angelico]

On Wed, Jan 31, 2018 at 8:15 PM, Etienne Robillard  wrote:
>
>
> Le 2018-01-30 à 16:38, Ned Batchelder a écrit :
>>>
>>> I'm confused by this:
>>>
>>> -if os.environ.get('SCHEVO_OPTIMIZE', '1') == '1':
>>> +if os.environ.get('SCHEVO_OPTIMIZE', '1') == True:
>>>
>> I was also curious about this: when does os.environ.get return anything
>> but a string?
>
>
> I was probably high when I coded this! ;)
>
> I think a better solution is to write :
>
> if os.environ.get('SCHEVO_OPTIMIZE', '0')  == '1':
>  ...
>
> Anyways, what do you think about the weakref case?
>

I think, without any real facts to justify it, that this sort of thing
is *probably* an unintended compatibility break. So if you can show a
minimal test-case that highlights the difference, you can probably
raise an issue against PyPy and maybe get it fixed.

But like I said, I don't have any facts to back that conjecture.

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

Re: PyPy support breaking CPython compatibility?

[Etienne Robillard]

Le 2018-01-30 à 16:38, Ned Batchelder a écrit :

I'm confused by this:

-if os.environ.get('SCHEVO_OPTIMIZE', '1') == '1':
+if os.environ.get('SCHEVO_OPTIMIZE', '1') == True:

I was also curious about this: when does os.environ.get return 
anything but a string? 


I was probably high when I coded this! ;)

I think a better solution is to write :

if os.environ.get('SCHEVO_OPTIMIZE', '0')  == '1':
 ...

Anyways, what do you think about the weakref case?

Etienne


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

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

Re: Handle SIGINT in C and Python (Posting On Python-List Prohibited)

[Victor Porton]

Lawrence D’Oliveiro wrote:

> On Wednesday, January 31, 2018 at 8:58:18 PM UTC+13, Victor Porton wrote:
>> For this reason I
>> cannot use Python signals because "A Python signal handler does not get
>> executed inside the low-level (C) signal handler. Instead, the low-level
>> signal handler sets a flag which tells the virtual machine to execute the
>> corresponding Python signal handler at a later point(for example at the
>> next bytecode instruction)."
> 
> Why is that a problem?

As I already said, I need to handle the signal (SIGCHLD) while poll() waits 
for i/o.

You can read the sources (and the file HACKING) of the C library which I am 
wrapping into Python here:

https://github.com/vporton/libcomcom

-- 
Victor Porton - http://portonvictor.org
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Handle SIGINT in C and Python

[Victor Porton]

Victor Porton wrote:
> I need to assign a real C signal handler to SIGINT.
> 
> This handler may be called during poll() waiting for data. For this reason
> I cannot use Python signals because "A Python signal handler does not get
> executed inside the low-level (C) signal handler. Instead, the low-level
> signal handler sets a flag which tells the virtual machine to execute the
> corresponding Python signal handler at a later point(for example at the
> next bytecode instruction)."
> 
> I want after my signal handler for SIGINT executed to raise
> KeyboardInterrupt (as if I didn't installed my own signal handler).
> 
> Is this possible? How?

I've found a solution: I can use PyOS_setsig() from Python implementation to 
get the old (Python default) OS-level signal handler, while I assign the new 
one.

-- 
Victor Porton - http://portonvictor.org
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Where has the practice of sending screen shots as source code come from?

[Abdur-Rahmaan Janhangeer]

it seems that at the end, invariably, the subject becomes well routed to
regions far away from codeland

Abdur-Rahmaan Janhangeer
https://abdurrahmaanjanhangeer.wordpress.com

On 28 Jan 2018 19:08, "Steven D'Aprano" <
steve+comp.lang.pyt...@pearwood.info> wrote:

> I'm seeing this annoying practice more and more often. Even for trivial
> pieces of text, a few lines, people post screenshots instead of copying
> the code.
>
> Where has this meme come from? It seems to be one which inconveniences
> *everyone* involved:
>
> - for the sender, instead of a simple copy and paste, they have to take a
> screen shot, possibly trim the image to remove any bits of the screen
> they don't want to show, attach it to their email or upload it to an
> image hosting site;
>
> - for the receiver, you are reliant on a forum which doesn't strip
> attachments, or displays externally hosted images; the visually impaired
> are excluded from using a screen reader; and nobody can copy or edit the
> given text.
>
> It is as if people are deliberately inconveniencing themselves in order
> to inconvenience the people they are asking to help them.
>
> With the exception of one *exceedingly* overrated advantage, namely the
> ability to annotate the image with coloured lines and circles and
> squiggles or other graphics (which most people don't bother to do), this
> seems to me to be 100% counter-productive for everyone involved. Why has
> it spread and why do people keep doing it?
>
> I don't want to be the old man yelling "Get Of My Lawn!" to the cool
> kids, but is this just another sign of the downward spiral of programming
> talent? Convince me that there is *some* justification for this practice.
> Even a tiny one.
>
> (The day a programmer posts a WAV file of themselves reading their code
> out aloud, is the day I turn my modem off and leave the internet forever.)
>
>
>
> --
> Steve
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Handle SIGINT in C and Python

[Victor Porton]

I need to assign a real C signal handler to SIGINT.

This handler may be called during poll() waiting for data. For this reason I 
cannot use Python signals because "A Python signal handler does not get 
executed inside the low-level (C) signal handler. Instead, the low-level 
signal handler sets a flag which tells the virtual machine to execute the 
corresponding Python signal handler at a later point(for example at the next 
bytecode instruction)."

I want after my signal handler for SIGINT executed to raise 
KeyboardInterrupt (as if I didn't installed my own signal handler).

Is this possible? How?

-- 
Victor Porton - http://portonvictor.org
-- 
https://mail.python.org/mailman/listinfo/python-list