Reference counting and the use of PYTHONDUMPREFS

[Anders Wegge Keller]

 During the final test of a bit of embedded python, I wanted to see if
I had any hanging references. To my suprise, I ended up with a rather
large amount, after running combinerefs.py. And even with the
simplest[1] possible use of embedding, I end up with 13475 still-living
references. 

 If this is the expected case, then what are the possible benefit from
running a process with the PYTHONDUMPREFS ebvironment variable set? My
code would have to be hemorrhaging in a severe way, to show up on this
background. Am I missing something here?

 The system in question is a Fedora 19 Linux, using the distribution's
Python3 debug rpm. I've seen similar results with Python 2.6, just at
a lesser scale.

1:
#include stdlib.h
#include Python.h

int main (int argc, char **argv) {

  Py_Initialize();
  Py_Finalize();

  return EXIT_SUCCESS;
}

Compiled with:

gcc pyleak.c -o pyleak `/usr/bin/python3.3dm-config --cflags`  \
  `/usr/bin/python3.3dm-config --ldflags` 


-- 
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Separate Address number and name

[Anders Wegge Keller]

Shane Konings shane.koni...@gmail.com writes:

 I have struggled with this for a while and know there must be a
 simple method to achieve this result.

 There are several. But without seeing the code you have already
written, it's har to help you improve it.

-- 
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Separate Address number and name

[Anders Wegge Keller]

Shane Konings shane.koni...@gmail.com writes:

...

 The following is a sample of the data. There are hundreds of lines
 that need to have an automated process of splitting the strings into
 headings to be imported into excel with theses headings

 ID  Address  StreetNum  StreetName  SufType  Dir   City  Province  PostalCode
 
 
 1 1067 Niagara Stone Rd, W, Niagara-On-The-Lake, ON L0S 1J0
 2 4260 Mountainview Rd, Lincoln, ON L0R 1B2
 3 25 Hunter Rd, Grimsby, E, ON L3M 4A3
 4 1091 Hutchinson Rd, Haldimand, ON N0A 1K0
 5 5172 Green Lane Rd, Lincoln, ON L0R 1B3
 6 500 Glenridge Ave, East, St. Catharines, ON L2S 3A1
 7 471 Foss Rd, Pelham, ON L0S 1C0
 8 758 Niagara Stone Rd, Niagara-On-The-Lake, ON L0S 1J0
 9 3836 Main St, North, Lincoln, ON L0R 1S0
 101025 York Rd, W, Niagara-On-The-Lake, ON L0S 1P0

 The input doesn't look consistent to me. Is Dir supposed to be an
optional value? If that is the only optional, it can be worked
around. But if the missing direction (I'm guessing) is due to
malformed input data, you have a hell of a job in front of you.

 What do you want to do with incomplete or malformed data? Try to
parse it as a best effort, or simply spew out an error message for
an operator to look at?

 In the latter case, I suggest a stepwise approach:

* Split input by ',' -res0

* Split the first result by ' ' - res

- Id = res[0]
- Address = res[1:]
- StreetNum = res[1]
- StreetName= res [2:]
- SufType = res[-1]

* Check if res0[1] looks like a cardinal direction
 If so Dir = res0[1]
 Otherwise, croak or use the default direction. Insert an element in
 the list, so the remainder is shifted to match the following steps.

- City = res0[2]

* Split res0[3] by ' ' - respp

respp[0] - Province
respp[1:] - Postcode


 And put in som basic sanitation of the resulting values, before
committing them as a parsed result. Provinces and post codes, should
be easy enough to validate against a fixed list. 

-- 
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[Anders Wegge Keller]

Kevin Walzer k...@codebykevin.com writes:

 I can only think of two widely used languages in the last decade where
 there was this type of major break in binary compatibility: Perl and
 Visual Basic.

 Lua 5.1, 5.2 and 5.3 are all incompatible to some extent. It's
debatable how widely used Lua is as a stand-alone language, but the
usage is pretty widespread; it's just mostly concealed inside another
application.

-- 
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*
-- 
https://mail.python.org/mailman/listinfo/python-list

Is there a tracker target for this mailing list?

[Anders Wegge Keller]

 My spam filter have an issue with the way mails are sent to this list. If a
mail sent to python-list is DKIM-signed, the DKIM-Signature header is kept
in the mail. Since the mangling happening during distribution to the list
changes one of the signed header fields, rather a lot of the mails to the
list ends up in Spam. 

 So where to report this issue?

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

Re: Is there a tracker target for this mailing list?

[Anders Wegge Keller]

On Thu, 31 Jul 2014 14:57:36 -0400
Terry Reedy tjre...@udel.edu wrote:

 On 7/31/2014 9:38 AM, Anders Wegge Keller wrote:
My spam filter have an issue with the way mails are sent to this list.
  If a mail sent to python-list is DKIM-signed, the DKIM-Signature header
  is kept in the mail. Since the mangling happening during distribution to
  the list changes one of the signed header fields, rather a lot of the
  mails to the list ends up in Spam.
 
So where to report this issue?
 
 All python.org list are run with 'mailman', www.list.org , which has 
 multiple lists about mailman.  I am assuming that the behavior you 
 describe is not specific to python-list.

 It is. The wikimedia/wikipedia/mediawiki lists I subscribe to, also use
Mailman. There are no problems with either wrong DKIM-signatures, nor wrong
spf checks.

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

Re: Global indent

[Anders Wegge Keller]

On Sun, 24 Aug 2014 00:56:11 +1000
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:

 Despite my comments, I don't actually have any objection to people who
 choose to use Emacs, or Vim, or edit their text files by poking the hard
 drive platter with a magnetised needle if they prefer :-) But I do think
 it's silly of them to claim that Emacs has no learning curve, or to fail to
 recognise how unfamiliar and different the UIs are compared to nearly
 everything else a computer user is likely to be familiar with in 2014.

 Really, they don't! At least not for the people, for whom they are
necessary tools. When I started in my present job, remote access was
a dial-up modem, that could do 2400 baud, if you were lucky[1]. With such a
shitty connection, a text-only editor is indisputably the right thing. 

 Curiously enough, even today the same lousy kind of connections prevail. We
still have a sizeable modem bank at my job. We still do our remote support
over a telnet/ssh session. And we still are unable to reliable get the 
connection speeds[2], that would make anything with a GUI remotely
pleasant. 

 So emacs and vim still have their niches. Those of us, who are old enough
to have started our first job in a glorified teletype, OR have to support
systems that are only reachable over RFC-1149 quality datalinks, belong
there. The rest of you would probably be better off with something nicer.

1. Meaning a real switched landline all the way from Denmark to Tokyo.
Ending up with two satellite up/down-links was a killer.

2. We have an installation in the Philippines, where we ended up installing a
   satellite uplink. It feels like we have doubled the connectivity of the
   entire Manilla area by doing so. And it's still painfully slow.

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

Parsing and displaying C structs in a semi-intelligent way.

[Anders Wegge Keller]

 In my day job, we have a large code base of mostly identical projects, each
with their own customizations. The customizations can be a real pain
sometimes. Especially when debugging binary data. The interesting part of
the binary dumps are most often the stuff that are tweaked from project to
project. The prime suspect is a structure like this:

typedef struct
{
bytenext ;  /* Index to next wedge  */
byteflags ; /* ricd-control flags   */
wordalt [MAX_alt] ; /* Alternative wedges   */
...
} ConvResult ;

typedef struct
{
bytestate ; /* UCART_ (see cart.h)  */
wordheadcart ;  /* Cart number for header cart  */
ConvResult  conv ;
...
} cartUTable_t ;

 The actual structure with substructures are much larger. This structure
contains all the information used when sorting stuff[1]. For historical
reasons, the data is dumped to a binary file at the end of the items
life-cycle. We do have a debugging tool, that reads an in-house file format
specifying the members of the structure, and how to display them. However,
updating this description is error-prone, and just about as funny as waiting
for the Norwegian Blue to fly out over the fiords. So most often it's either
not done, or is unusable. 

 To clean up this mess, I've devised a cunning plan, involving a C-parser,
that can write a structure definition as XML. Reading this is simple enough,
and going from that to a format string for struct.unpack() is mostly
trivial. Except for the arrays of some C-type, that happens to be something
else than an array of char. Due to the normal use case[2] of dumping this
binary data, I need to get the parsed data munged into a form, that can be
put into a namedtuple as single member, even when I have an array of
(typical) six conv.alt values. I'm getting stuck with the limitations of
struct and namedtuple. While inheriting either of them to get the job done,
seem to be feasible, I still feel that I somehow should be able to do
something list comprehension-ish, to avoid going there. I just can't see
the light.

(Thank you for reading all the way to here!)


1. Luggage, parcels, shop replenishments ... In short: mostly rectangular
   things that has a barcode attached.

2. Random ordering, not displaying all members, and only a part of the
   arrays.

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

Re: [Off-topic] Requests author discusses MentalHealthError exception

[Anders Wegge Keller]

On Mon, 29 Feb 2016 23:29:43 +
Mark Lawrence  wrote:

> On 29/02/2016 22:40, Larry Martell wrote:

>> I think for the most part, the mental health industry is most
>> interested in pushing drugs and forcing people into some status quo.

> I am disgusted by your comments.  I'll keep my original reply in reserve.

 Actually, if you view it by raw numbers, where depression makes up the bulk
of the total number of mental problems, Larry's statement is true.

 Studies not performed by the industry shows that an un-medicated depression
ends on average half a day later than one that's treated with some sort
of SSRI. 

Disclaimer: I'm depressed myself, and I've taken an interest into the hows
and whys of SSRI medications.

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

Re: Grapheme clusters, a.k.a.real characters

[Anders Wegge Keller]

På Tue, 18 Jul 2017 23:59:33 +1000
Chris Angelico  skrev:
> On Tue, Jul 18, 2017 at 11:11 PM, Steve D'Aprano


>> (I don't think any native English words use a double-V or double-U, but
>> the possibility exists.)  
 
> vacuum.

 That's latin. 

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

Re: Grapheme clusters, a.k.a.real characters

[Anders Wegge Keller]

På Tue, 18 Jul 2017 11:27:03 -0400
Dennis Lee Bieber  skrev:

>   Probably would have to go to words predating the Roman occupation
> (which probably means a dialect closer to Welsh or other Gaelic).
> Everything later is an import (anglo-saxon being germanic tribes invading
> south, Vikings in the central area, as I recall southern Irish displacing
> Picts in Scotland, and then the Norman French (themselves starting from
> Vikings ["nor(se)man"]).

 English is known to be lurking in back alleys, waiting for unsuspecting
 languages, that can be beat up for loose vocabulary. So defining anything
 "pure" about it, is going to be practically impossible.

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

SIGSEGV and SIGILL inside PyCFunction_Call

[Anders Wegge Keller]

 I have an ongoing issue with my usenet setup. I'm that one dude who don't
want to learn perl. That means that I have to build inn from source, so I
can enable the python interpreter. That's not so bad, and the errors that
show up have been something that I have been able to figure out by myself.
At least up until now. I have an almost 100% repeatable crash, when nnrpd
performs the user authentication step. Backtracing the core dum gives this:

#0  0x564a864e2d63 in ?? ()
#1  0x7f9609567091 in call_function (oparg=, 
pp_stack=0x7ffda2d801b0) at ../Python/ceval.c:4352

Note:   Line 4352 C_TRACE(x, PyCFunction_Call(func,callargs,NULL));

#2  PyEval_EvalFrameEx (
f=Frame 0x7f9604758050, for file /etc/news/filter/nnrpd_auth.py, 
line 67, in __init__ (self=

Re: SIGSEGV and SIGILL inside PyCFunction_Call

[Anders Wegge Keller]

På Thu, 20 Jul 2017 07:44:26 +0200
dieter <die...@handshake.de> skrev:
> Anders Wegge Keller <we...@wegge.dk> writes:

...

>>  Weird observation #1: Sometimes the reason is SIGSEGV, sometimes it's
>> SIGILL.   
 
> Python tends to be sensitive to the stack size. In previous times,
> there have often be problems because the stack size for threads
> has not been large enough. Not sure, whether "nnrpd" is multi threaded
> and provides a sufficiently large stack for its threads.

 Luckily, the "threading model" of nnrpd is fork().

> A "SIGILL" often occurs because a function call has destroyed part
> of the stack content and the return is erroneous (returning in the midst
> of an instruction).

 I think you're right. That also explains why gdb have trouble with the last
stack frame. 


>>  I'm not ready to give up yet, but I need some help proceeding from here.
>> What do the C_TRACE really do,  
 
> The casing (all upper case letters) indicates a C preprocessor macro.
> Search the "*.h" files for its definition.

 I know where it is. I just don't feel like deciphering a 60 lines
monstrosity before at least asking if someone has a intimate enough
relationship with it, to give a TL;DR.

> I suppose that with a normal Python build (no debug build), the
> macro will just call "PyCFunction_Call".
> Alternatively, it might provide support for debugging, tracing
> (activated by e.g. "pdb.set_trace()").

 Probably. I can see I have to dig into it.

>> and is there some way of getting a level
>> deeper, to see what cause the SEGV. Also, how can the C code end up with
>> an illegal instruction_  

...

> Unfortunately, stack corruption is a non local problem (the point
> where the problem is caused is usually far away from the point
> where it is observed).
> 
> If the problem is not "too small stack size", you might need
> a tool to analyse memory overrides.

 The trouble with that is that nnrpd is a system daemon, and as such is a
bit difficult to trace in place. That's why I am asking for help
reasoning the cause, before I have to resort to running a debugger as a
privileged user.


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

Re: object types, mutable or not?

[Anders Wegge Keller]

På Wed, 16 May 2018 14:48:27 +0100
Paul Moore  skrev:

> C++ called that an "rvalue". And then went on to define things that
> could go on the left hand side of an assignment as "lvalues". And now
> we have two confusing concepts to explain - see what happens when you
> let a standards committee define your language? :-)

 I'm not sure the C++ committee has to bear the responsibility for those
terms. They are pretty well defined in the C world, so I think you need to
point the finger of accusation at either Brian or Dennis. 

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

Re: Are the critiques in "All the things I hate about Python" valid?

[Anders Wegge Keller]

På Mon, 19 Feb 2018 08:47:14 +1100
Tim Delaney <timothy.c.dela...@gmail.com> skrev:
> On 18 February 2018 at 22:55, Anders Wegge Keller <we...@wegge.dk> wrote:


> >  That list is not only weakly typed, but rather untyped. There are no
> > safeguards in the language, that enforce that all elements in a list or
> > other container are in fact of the same type. Before type annotations and
> > mypy, I could not enforce that other than at runtime.

> You couldn't have got the above much more wrong.
 
> As others have said, typing is about how the underlying memory is treated.

 And that is exactly my point. Python does not have a typed list. It have a
list that takes whatever is thrown into it.

 I'll skip the rest, as you totally missed the point.
-- 
//Wegge
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Anders Wegge Keller]

På Tue, 20 Feb 2018 12:28:25 + (UTC)
Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> skrev:
> On Mon, 19 Feb 2018 16:34:29 +0100, Anders Wegge Keller wrote:
> 
> > På Mon, 19 Feb 2018 15:15:19 + (UTC) Steven D'Aprano
> > <steve+comp.lang.pyt...@pearwood.info> skrev:  
> >> On Mon, 19 Feb 2018 14:06:36 +0100, Anders Wegge Keller wrote:
> >>   
>  [...]  
> >> 
> >> That's a mighty powerful claim that goes against the documentation for
> >> the array module. Can you back your claims up?
> >> 
> >> Here's an array and a list:  
> > 
> >  Make me an array of tuples with two integers and a string, and we can
> >  talk.  
> 
> The array module's failure to support the specific type you want has no 
> bearing on whether or not Python is statically typed.

 You claimed Array could do what I requested, i.e. container type that
guaranteed only one type inside. Furthermore, you are misrepresenting C with
malice. 

 I don't care why you feel that a simple observation is a personal attack,
but I see you behave as a spoiled kid. I haven\t got the time for it, sop go
and pout in your corner. 

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

Re: Are the critiques in "All the things I hate about Python" valid?

[Anders Wegge Keller]

På Mon, 19 Feb 2018 04:39:31 + (UTC)
Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> skrev:
> On Mon, 19 Feb 2018 04:26:32 +0100, Anders Wegge Keller wrote:
> 
> > På Mon, 19 Feb 2018 08:47:14 +1100
> > Tim Delaney <timothy.c.dela...@gmail.com> skrev:  
> >> On 18 February 2018 at 22:55, Anders Wegge Keller <we...@wegge.dk>
> >> wrote:  
> > 
> >   
>  [...]  
> >   
> >> You couldn't have got the above much more wrong.  
> >
> >> As others have said, typing is about how the underlying memory is
> >> treated.  
> > 
> >  And that is exactly my point. Python does not have a typed list. It
> >  have a list that takes whatever is thrown into it.
> > 
> >  I'll skip the rest, as you totally missed the point.  
> 
> I think its actually you have totally missed the point. What you want is 
> a homogeneous list, a list which only accepts items of the same type. The 
> built-in list is not that data structure, but Python already has 
> something similar: see the array module.

 Given that I'm the one making a point about the unwarranted smugness, I
know that I'm not missing anything. Array is not even close to providing a
strongly typed container. For all of the yakking about other languages
weak, blah, BCPL, blah, I still wonder where that need to feel superior to
anything else comes from.  

 Python isn't particular strong typed. In fact, apart from asking an object
what type it is, types are not that important. It's the interface that
matters. I wonder why this is a sore point for Python developers?


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

Re: Are the critiques in "All the things I hate about Python" valid?

[Anders Wegge Keller]

På Mon, 19 Feb 2018 15:15:19 + (UTC)
Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> skrev:
> On Mon, 19 Feb 2018 14:06:36 +0100, Anders Wegge Keller wrote:
> 
> > Array is not even close to providing a strongly typed container.  
> 
> That's a mighty powerful claim that goes against the documentation for 
> the array module. Can you back your claims up?
> 
> Here's an array and a list:

 Make me an array of tuples with two integers and a string, and we can talk.

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

Re: Are the critiques in "All the things I hate about Python" valid?

[Anders Wegge Keller]

På Sun, 18 Feb 2018 07:34:03 -0500
Richard Damon  skrev:

> Python is much stronger typed than PHP, because in PHP you can do things 
> like 1 + '2' and get 3, as string values will naturally convert 
> themselves to numbers, Python won't do this. Yes Python will freely 
> convert between numeric types, but I wouldn't say that Python claims to 
> be a language that focuses on numerics.

 Type coercion is not the same as weak typing. Let me stress that the
difference between languages having 1 + 1.23 as a valid construct and
languages having 1 + '1.23' as a valid construct, is merely a design
descision. PHP is fully aware that a string and an integer have different
types, and makes a implicit cast, rather than throw an error. 

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

Re: Are the critiques in "All the things I hate about Python" valid?

[Anders Wegge Keller]

På Sat, 17 Feb 2018 15:05:34 +1100
Ben Finney  skrev:
> boB Stepp  writes:


> He blithely conflates “weakly typed” (Python objects are not weakly, but
> very strongly typed) 

 Python is more strongly typed than PHP, but that doesn't really say much.
However, compared to a language like C, there are big holes in the type
safety.

>>> alist = [1, 'two', ('three', four), 5*'#']

 That list is not only weakly typed, but rather untyped. There are no
safeguards in the language, that enforce that all elements in a list or
other container are in fact of the same type. Before type annotations and
mypy, I could not enforce that other than at runtime. 

 So claiming Python to have very strongly typed objects is a bit of a
strecth. PHP that many of us like to be smug about is equally strongly
typed. It just comes with a metric ton of inane type coersions that have
gone too far. However, we are happy to add an integer to a float without
having to make an explicit conversion every time, so ... Thread carefull and
all that.

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

Re: Unicode [was Re: Cult-like behaviour]

[Anders Wegge Keller]

På Mon, 16 Jul 2018 11:33:46 -0700
Jim Lee  skrev:

> Go right ahead.  I find it surprising that Stephen isn't banned, 
> considering the fact that he ridicules anyone he doesn't agree with.  
> But I guess he's one of the 'good 'ol boys', and so exempt from the code 
> of conduct.

Well said!

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

Re: Unicode [was Re: Cult-like behaviour]

[Anders Wegge Keller]

> The buzzing noise you just heard was the joke whizzing past your head 
> *wink*

 I have twins aged four. They also like to yell "I cheated!", whenever they
are called out.

 In general, you need to get rid of tat teenage brat persona you practice.
The "ranting rick" charade was especially toe-curling.

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

Re: Non-GUI, single processort inter process massaging - how?

[Anders Wegge Keller]

På Sat, 21 Jul 2018 09:07:23 +0100
Chris Green  skrev:

> So - what's the best approach to this?  I've done some searching and
> most/many of the solutions seem rather heavyweight for my needs. Am I
> overlooking something obvious or should I try rethinking the original
> requirement and look for another approach?

 What do you consider heavyweight? Number of dependencies, memory footprint,
amount of code or a fourth thing? Also, which platform will the code
eventually run on?

 If your update frequency is low enough that it wont kill the filesystem and
the amount of data is reasonably small, atomic writes to a file is easy to
work with:

  def atomic_write(filename, data):
handle, name = tempfile.mkstemp()
os.write(handle, data)
os.fsync(handle)
os.close(handle)
os.replace(tmpname, filename)

 The imports are trivial to deduce, so I removed the clutter. If you have
multiple filesystems, you may have to read into the details of calling
mkstemp.


 If you have an update frequency that will kill the filesystem (for instance
a RPi on a SD card), or have a larger data set where you only want to do
partial updates, the mmap module could be an option. It require some more
boilerplate. You will probably also have to consider a semaphore to
guarantee that the clients read a consistent result set.

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

Re: want to export some of the packets from a big pacp file to another file.

[Anders Wegge Keller]

På Thu, 5 Apr 2018 08:06:10 -0700 (PDT)
supsw...@gmail.com skrev:
> Hi,
> 
> I am using dpkt python package to parse .pcap file and I am able to do
> successfully.
> 
> My requirement is to filter some of the traffic from the big .pcap file
> and to export the result to another file.
> 
> I don't know how to do this.

 What kind of filtering do you need? In many cases it would be faster and
more convenient to use wireshark or other similar tools as a pass-through
filter, rather than rolling your own. 

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

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Anders Wegge Keller]

På Sat, 31 Mar 2018 11:58:39 -0400
Etienne Robillard  skrev:

> Are you trolling? Do you understand that a modern mobile device 
> typically require a Internet subscription and an additional subscription 
> for the smart phone?

 I think the question is why you equate python3 with the need for internet
connected tablets. That's quite the non sequitur. 

Consider this my +1 the the request of you to clarify what you mean.

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

PEP 394

[Anders Wegge Keller]

Short and simple: Do you expect PEP 394 to change status or
recommendation when official support for Python2 ends in 13½ months time, or
at least some time thereafter? 

For those that don't have the habit of memorizing PEPs, 394 is the one
stating 

* python2 will refer to some version of Python 2.x.
* python3 will refer to some version of Python 3.x.
* for the time being, all distributions should ensure that python, if
installed, refers to the same target as python2, unless the user
deliberately overrides this or a virtual environment is active.

-- 

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

Re: logging output

[Anders Wegge Keller]

På Fri, 19 Oct 2018 08:05:28 -0700 (PDT)
Sharan Basappa  skrev:

...

> delimiter=r'\s"') #data_df = pd.read_csv("BGL_MERGED.log")
> logger.debug("data frame %s \n", data_df)

 Do this help?
 


-- 

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

Re: PEP 394

[Anders Wegge Keller]

På Sat, 20 Oct 2018 12:57:45 +1100
Ben Finney  skrev:
> Anders Wegge Keller  writes:
> 
> > Short and simple: Do you expect PEP 394 to change status  
> 
> The status of PEP 394 today is “Active”. What change of status would you
> expect in this Informational PEP?

 One possible change would be that it would become archived, ceased to be,
bereft of life, resting in peace or maybe even retired. 

 I don't have any particular status change I want to see; I merely ask
what other experienced python developers expect to happen.

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