Re: Instagram: 40% Py3 to 99% Py3 in 10 months (Posting On Python-List Prohibited)

2017-06-19 Thread Steven D'Aprano
On Mon, 19 Jun 2017 21:45:09 -0700, Paul Rubin wrote:

> Lawrence D’Oliveiro  writes:
>> Is Python 2 the Windows XP of the programming world?
> 
> That's a good way to put it.  It's nice to hear about Instagram but so
> far I don't personally know anyone who uses Python 3.


Funny about that, I don't personally know anyone who uses Java or C++.

You should check out Reddit's /r/python, it has a reputation for being 
(unreasonably, obnoxiously) pro-Python 3 even when people have a good 
reason for sticking with Python 1.

I mean 2.



> Meanwhile there's still lots of new Py2 projects being started.


Unless that project is extremely small, or a throw-away ("we need it for 
three months, then it's obsolete"[1]), I consider starting new projects 
in Python 2 to be borderline professional misconduct, unless there's a 
genuinely good reason.

(Which might include "the customer insists", or "yeah, I know it sucks, 
but politics".)

In less than three years time, 2.7 will no longer be receiving support or 
bug fixes from the Python core devs. There will still be paid support 
from third parties available for a few years after that, but this is 
starting to limit your options.

(E.g. are you willing to tell your clients to move their servers to RHEL 
so they can pay for Red Hat support for Python 2.7?)

At this point, any Python developer who isn't recommending Python 3 as 
the default choice is doing their clients a professional disservice, in 
my opinion.

It's still okay to use 2.7 if you have a good reason, or a bad reason for 
that matter, hell if you want to use 1.5 go right ahead, it's free 
software. But 2.7 should not be any professional Python developer's 
default recommendation any longer.


https://pythonclock.org/




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


Re: Progress on the Gilectomy

2017-06-19 Thread Paul Rubin
Cem Karan  writes:
> Can you give examples of how it's not reliable?

Basically there's a chance of it leaking memory by mistaking a data word
for a pointer.  This is unlikely to happen by accident and usually
inconsequential if it does happen, but maybe there could be malicious
data that makes it happen

Also, it's a non-compacting gc that has to touch all the garbage as it
sweeps, not a reliability issue per se, but not great for performance
especially in large, long-running systems.

It's brilliant though.  It's one of those things that seemingly can't
possibly work, but it turns out to be quite effective.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Progress on the Gilectomy

2017-06-19 Thread Paul Rubin
Chris Angelico  writes:
> Or let's look at it a different way. Instead of using a PyObject* in C
> code, you could write C++ code that uses a trivial wrapper class that
> holds the pointer, increments its refcount on construction, and
> decrements that refcount on destruction.

That's the C++ STL shared_ptr template.  Unfortunately it has the same
problem as Python refcounts, i.e. it has to use locks to maintain thread
safety, which slows it down significantly.

The simplest way to start experimenting with GC in Python might be to
redefine the refcount macros to do nothing, connect the allocator to the
Boehm GC, and stop all the threads when GC time comes.  I don't know if
Guile has threads at all, but I know it uses the Boehm GC and it's quite
effective.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Instagram: 40% Py3 to 99% Py3 in 10 months (Posting On Python-List Prohibited)

2017-06-19 Thread Paul Rubin
Lawrence D’Oliveiro  writes:
> Is Python 2 the Windows XP of the programming world?

That's a good way to put it.  It's nice to hear about Instagram but so
far I don't personally know anyone who uses Python 3.  Meanwhile there's
still lots of new Py2 projects being started.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Progress on the Gilectomy

2017-06-19 Thread Chris Angelico
On Tue, Jun 20, 2017 at 1:52 PM, Rustom Mody  wrote:
> Saw this this morning
> https://medium.com/@alexdixon/functional-programming-in-javascript-is-an-antipattern-58526819f21e
>
> May seem irrelevant to this, but if JS, FP is replaced by Python, GC it 
> becomes
> more on topical

https://rhettinger.wordpress.com/2011/05/26/super-considered-super/

If super() is replaced with GC, it also becomes on-topic.

I'm sure all this has some deep existential meaning about how easily
blog posts can be transplanted into utterly unrelated conversations,
but at the moment, it eludes me.

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


Re: Progress on the Gilectomy

2017-06-19 Thread Rustom Mody
On Tuesday, June 20, 2017 at 5:53:00 AM UTC+5:30, Cem Karan wrote:
> On Jun 19, 2017, at 6:19 PM, Gregory Ewing wrote:
> 
> > Ethan Furman wrote:
> >> Let me ask a different question:  How much effort is required at the C 
> >> level when using tracing garbage collection?
> > 
> > That depends on the details of the GC implementation, but often
> > you end up swapping one form of boilerplate (maintaining ref
> > counts) for another (such as making sure the GC system knows
> > about all the temporary references you're using).
> > 
> > Some, such as the Bohm collector, try to figure it all out
> > automagically, but they rely on non-portable tricks and aren't
> > totally reliable.
> 
> Can you give examples of how it's not reliable?  I'm currently using it in 
> one of my projects, so if it has problems, I need to know about them.

Saw this this morning
https://medium.com/@alexdixon/functional-programming-in-javascript-is-an-antipattern-58526819f21e

May seem irrelevant to this, but if JS, FP is replaced by Python, GC it becomes
more on topical
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Progress on the Gilectomy

2017-06-19 Thread Cem Karan

On Jun 19, 2017, at 6:19 PM, Gregory Ewing  wrote:

> Ethan Furman wrote:
>> Let me ask a different question:  How much effort is required at the C level 
>> when using tracing garbage collection?
> 
> That depends on the details of the GC implementation, but often
> you end up swapping one form of boilerplate (maintaining ref
> counts) for another (such as making sure the GC system knows
> about all the temporary references you're using).
> 
> Some, such as the Bohm collector, try to figure it all out
> automagically, but they rely on non-portable tricks and aren't
> totally reliable.

Can you give examples of how it's not reliable?  I'm currently using it in one 
of my projects, so if it has problems, I need to know about them.

On the main topic: I think that a good tracing garbage collector would probably 
be a good idea.  I've been having a real headache binding python to my C 
library via ctypes, and a large part of that problem is that I've got two 
different garbage collectors (python and bdwgc).  I think I've got it worked 
out at this point, but it would have been convenient to get memory allocated 
from python's garbage collected heap on the C-side.  Lot fewer headaches.

Thanks,
Cem Karan
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Progress on the Gilectomy

2017-06-19 Thread Gregory Ewing

Ethan Furman wrote:
Let me ask a different question:  How much effort is required at the C 
level when using tracing garbage collection?


That depends on the details of the GC implementation, but often
you end up swapping one form of boilerplate (maintaining ref
counts) for another (such as making sure the GC system knows
about all the temporary references you're using).

Some, such as the Bohm collector, try to figure it all out
automagically, but they rely on non-portable tricks and aren't
totally reliable.

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


Re: Progress on the Gilectomy

2017-06-19 Thread Chris Angelico
On Tue, Jun 20, 2017 at 1:44 AM, Skip Montanaro
 wrote:
> On Mon, Jun 19, 2017 at 10:20 AM, Ethan Furman  wrote:
>
>> Programming at the C level is not working in Python, and many Python
>> niceties simply don't exist there.
>
>
> True, but a lot of functionality available to Python programmers exists at
> the extension module level, whether delivered as part of the core
> distribution or from third-party sources. (The core CPython test suite
> spends a fair amount of effort on leak detection, one side effect of
> incorrect reference counting.) While programming in Python you don't need
> to worry about reference counting errors, when they slip through from the C
> level, they affect you.

High level languages mean that you don't have to write C code. Does
the presence of core code and/or extension modules written in C mean
that Python isn't a high level language? No. And nor does that code
mean Python isn't garbage-collected. Everything has to have an
implementation somewhere.

Or let's look at it a different way. Instead of using a PyObject* in C
code, you could write C++ code that uses a trivial wrapper class that
holds the pointer, increments its refcount on construction, and
decrements that refcount on destruction. That way, you can simply
declare these PyObjectWrappers and let them expire. Does that mean
that suddenly the refcounting isn't your responsibility, ergo it's now
a garbage collector? Because the transformation is trivially easy.

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


PyCon.DE 2017 - Call for Proposals

2017-06-19 Thread Mike Müller
Call for Proposals
--

The Call for Proposals for the PyCon.DE 2017 is open until July 30, 2017.
Please submit your proposals here:

https://www.papercall.io/pyconde2017

We’re looking for proposals on every aspect of Python: programming from novice
to advanced levels, applications and frameworks, or how you have been involved
in introducing Python into your organization. PyCon.DE is a community
conference and we are eager to hear about your experience.

The conference will be held in English language only.

The conferences addresses:

* Data Scientists
* Software Developers
* System Administrators
* Academic Scientists
* Technology Enthusiasts

We are looking for:

* 30 minute presentations (incl. optional 5 minute Q&A)
* 45 minute presentations (incl. optional 5 minute Q&A)

PyData @ PyConDE 2017

There will be a PyData track at this year’s conference. Please submit your
papers for the PyData track through the PyConDE form.

About PyCon.DE 2017
---

The next PyCon.DE will be held from 25-27th October 2017 at the ZKM - Center
for Art and Media in Karlsruhe, Germany [1]. The conference is the sixth in
this series, gathering Python professionals and enthusiasts. The conference
language will English, attracting Pythonistas from all over Europe and the
world. Volunteers organize and provide talks, tutorials, as well as discussions
in an open-source fashion.

This Karlsruhe conference has a special focus on data science. Therefore, a
PyData conference is held  as part of PyCon.DE. PyData [2] is an
internationally renowned conference series, which is dedicated to data science,
machine learning, and AI.

The ZKM - Center for Art and the Media  is a unique cultural institution, as it
is a place that extends the original tasks of the museum. It is a home of all
media and genres, a house of both the traditional arts like painting,
photography, and sculpture as well as the time-based arts such as film, video,
media art, music, dance, theater, and performance.

Conference registration is open. Don't miss this event!
More information available at: http://www.pycon.de

[1] http://zkm.de
[2] http://pydata.org

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


Project Structure

2017-06-19 Thread Rob Gaddi
I'm working on a project ( https://github.com/NJDFan/register-maps 
http://register-maps.readthedocs.io/en/latest/ ) and running into some 
issues with overall project structure and documentation.


The project is a code generator that reads in a set of proprietary 
format XML files and uses them to generate output in any number of 
languages (C, Python, VHDL) as well as HTML documentation.  Input is an 
entire directory, output is an entire directory.


  registermap ./data/src --format=html --output=../docs/html

One of the things I'd like to do is to write a boilerplate README.rst 
into the target directory.  I also have Sphinx documentation; I'd like 
to incorporate all those READMEs into the HTML docs.  I'd also like to 
have something like a


  registermap --format-help vhdl

Which displays the appropriate README, ideally neatly formatted for the 
terminal and running through a pager.  You know, civilized.


So, right now I have a project setup which is

./
  doc/
...
  registermaps/
__init__.py
...
resource/
  vhdl/
README.rst
...
  html/
README.rst
style.css
...
  README.rst
  setup.py
  ...

Output classes have a .outputname, which is both the command-line output 
name ('html') and the directory under resource that all the stuff is in.
I have a utility function in the module that allows those classes to 
register themselves against that name for the command-line tool.


Resources are accessed through pkg_resource.resource_string internal to 
the program, and the READMEs get pulled into the Sphinx docs by having a 
doc/source/outputs.rst full of include directives like


  .. include:: ../../registermaps/resource/html/README.rst

I still don't have any kind of standard way of pretty-printing and 
paging the reST to the terminal.  And, more the point, this all feels 
VERY tangled.  Like there's something that other people just know to do 
and I missed the memo.  Anyone have any ideas on a cleaner implementation?


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


Re: Progress on the Gilectomy

2017-06-19 Thread Ethan Furman

On 06/19/2017 08:44 AM, Skip Montanaro wrote:

On Mon, Jun 19, 2017 at 10:20 AM, Ethan Furman wrote:



Programming at the C level is not working in Python, and many Python niceties 
simply don't exist there.


True, but a lot of functionality available to Python programmers exists at the 
extension module level, whether delivered
as part of the core distribution or from third-party sources. (The core CPython 
test suite spends a fair amount of
effort on leak detection, one side effect of incorrect reference counting.) 
While programming in Python you don't need
to worry about reference counting errors, when they slip through from the C 
level, they affect you.


Let me ask a different question:  How much effort is required at the C level 
when using tracing garbage collection?

--
~Ethan~

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


Re: Progress on the Gilectomy

2017-06-19 Thread Skip Montanaro
On Mon, Jun 19, 2017 at 10:20 AM, Ethan Furman  wrote:

> Programming at the C level is not working in Python, and many Python
> niceties simply don't exist there.


True, but a lot of functionality available to Python programmers exists at
the extension module level, whether delivered as part of the core
distribution or from third-party sources. (The core CPython test suite
spends a fair amount of effort on leak detection, one side effect of
incorrect reference counting.) While programming in Python you don't need
to worry about reference counting errors, when they slip through from the C
level, they affect you.

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


Re: Progress on the Gilectomy

2017-06-19 Thread Ethan Furman

On 06/19/2017 08:06 AM, Skip Montanaro wrote:

On Mon, Jun 19, 2017 at 9:20 AM, Ethan Furman wrote:



Reference counting is a valid garbage collecting mechanism, therefore Python is 
also a GC language.


Garbage collection is usually thought of as a way to remove responsibility for 
tracking of live data from the user.
Reference counting doesn't do that.


Caveat:  I'm not a CS major.

Question: In the same way that Object Orientation is usually thought of as data 
hiding?

Comment:  Except in rare cases (e.g. messing with __del__), the Python user does not have to think about nor manage live 
data, so reference counting seems to meet that requirement.  Programming at the C level is not working in Python, and 
many Python niceties simply don't exist there.


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


Re: Progress on the Gilectomy

2017-06-19 Thread Skip Montanaro
On Mon, Jun 19, 2017 at 9:20 AM, Ethan Furman  wrote:

> Reference counting is a valid garbage collecting mechanism, therefore
> Python is also a GC language.


Garbage collection is usually thought of as a way to remove responsibility
for tracking of live data from the user. Reference counting doesn't do that.

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


Re: Progress on the Gilectomy

2017-06-19 Thread Rustom Mody
On Monday, June 19, 2017 at 7:40:49 PM UTC+5:30, Robin Becker wrote:
> On 19/06/2017 01:20, Paul Rubin wrote:
> ...
> > the existing C API quite seriously.  Reworking the C modules in the
> > stdlib would be a large but not impossible undertaking.  The many
> > external C modules out there would be more of an issue.
> > 
> I have always found the management of reference counts to be one of the 
> hardest 
> things about the C api.  I'm not sure exactly how C extensions would/should 
> interact with a GC python. There seem to be different approaches eg lua & go 
> are 
> both GC languages but seem different in how C/GC memory should interact.

Worth reading for chances python missed:

https://stackoverflow.com/questions/588958/what-are-the-drawbacks-of-stackless-python

To be fair also this:
https://stackoverflow.com/questions/377254/stackless-python-and-multicores
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Progress on the Gilectomy

2017-06-19 Thread Ethan Furman

On 06/19/2017 07:10 AM, Robin Becker wrote:


I have always found the management of reference counts to be one of the hardest 
things about the C api.  I'm not sure
exactly how C extensions would/should interact with a GC python. There seem to be 
different approaches eg lua & go are
both GC languages but seem different in how C/GC memory should interact.


The conversation would be easier if the proper terms were used.  Reference counting is a valid garbage collecting 
mechanism, therefore Python is also a GC language.


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


Re: Progress on the Gilectomy

2017-06-19 Thread Robin Becker

On 19/06/2017 01:20, Paul Rubin wrote:
...

the existing C API quite seriously.  Reworking the C modules in the
stdlib would be a large but not impossible undertaking.  The many
external C modules out there would be more of an issue.

I have always found the management of reference counts to be one of the hardest 
things about the C api.  I'm not sure exactly how C extensions would/should 
interact with a GC python. There seem to be different approaches eg lua & go are 
both GC languages but seem different in how C/GC memory should interact.

--
Robin Becker

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


Re: Error while connecting Teradata

2017-06-19 Thread mradul dhakad
Yes i did installed teradata odbc driver .

On Mon, Jun 19, 2017 at 9:20 AM, Dennis Lee Bieber 
wrote:

> On Sun, 18 Jun 2017 22:57:22 -0400, mradul dhakad
>  declaimed the following:
>
> >   File "C:\Python27\Lib\site-packages\teradata\tdodbc.py", line 391, in
> >   determineDriver
> >   "Available drivers: {}".format(dbType, ",".join(drivers)))
> >   InterfaceError: ('DRIVER_NOT_FOUND', "No driver found for 'Teradata'
> >
>
> 
>
> >Could anyone please let me know how to resolve this  Error.
> >
>
> Uhm... Did you install the Teradata ODBC driver?
>
> http://downloads.teradata.com/download/connectivity/odbc-driver/windows
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Reciprocal data structures

2017-06-19 Thread Christopher Reimer
> On Jun 18, 2017, at 11:02 PM, Chris Angelico  wrote:
> 
> On Mon, Jun 19, 2017 at 3:54 PM, Steven D'Aprano  wrote:
>>> With a list? No, I would say it's a bad idea.
>> 
>> 
>> Why a bad idea?
>> 
>> As opposed to "can't be done", or "too hard and slow".
> 
> Maintaining a record of list indices inside an object, with the
> specific proviso that:
> 
>> If the list is changed, the list updates the indices.
> 

A linked list with pointers to the next and previous items?

If this was a homework problem, a linked list is usually implemented in C. The 
list keyword in Python is not the same thing.

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


course

2017-06-19 Thread Val Krem via Python-list
Hi all,

Is there  on line course in Python? I am looking for a level between beginner 
and intermediate. I would appreciate if you could  suggest me?

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