Re: multiprocessing module backport from 3 to 2.7 - spawn feature

[Andres Riancho]

On Wed, Jan 28, 2015 at 3:06 PM, Skip Montanaro
 wrote:
>
> On Wed, Jan 28, 2015 at 7:07 AM, Andres Riancho 
> wrote:
>>
>> The feature I'm specially interested in is the ability to spawn
>> processes [1] instead of forking, which is not present in the 2.7
>> version of the module.
>
>
> Can you explain what you see as the difference between "spawn" and "fork" in
> this context?

Well, fork is a system call [0] where a process creates a copy of
itself, usually using COW [1]. This copy receives a new process ID and
is slightly dependent on the parent: they share the same address
space.

Spawn, and I took that from the multiprocessing 3 documentation, will
create a new process without using fork(). This means that no memory
is shared between the MainProcess and the spawn'ed sub-process created
by multiprocessing.

My goal is to prevent dead-locks and other issues [2][3] which come
from forking a multithreaded program (situation I'm in right now).

[0] https://en.wikipedia.org/wiki/Fork_%28system_call%29
[1] https://en.wikipedia.org/wiki/Copy-on-write
[2] See "Note that safely forking a multithreaded process is
problematic." at
https://docs.python.org/3.4/library/multiprocessing.html#multiprocessing.set_start_method
[3] 
http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them

> Are you using Windows perhaps? I don't know anything obviously
> different between the two terms on Unix systems.

Nope, I'm on linux

> Skip
>



-- 
Andrés Riancho
Project Leader at w3af - http://w3af.org/
Web Application Attack and Audit Framework
Twitter: @w3af
GPG: 0x93C344F3
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: why zip64_limit defined as 1<<31 -1?

[jesse]

the official zip format spec states clearly that normal zip file should be
<= 4G size instead 2G.  I just can not believe Python has such an obvious
bug.

People suggested monkey patch the ZIP64_LIMIT value to pass 2G, I am not
sure what will be the ramifications.
On Jan 28, 2015 1:37 PM, "Chris Angelico"  wrote:

> On Thu, Jan 29, 2015 at 5:53 AM, jesse  wrote:
> > should not it be 1<<32 -1(4g)?
> >
> > normal zip archive format should be able to support 4g file.
> >
> > thanks
>
> 1<<31-1 is the limit for a signed 32-bit integer. You'd have to look
> into the details of the zip file format to see whether that's the
> official limit or not; it might simply be that some (un)archivers have
> problems with >2GB files, even if the official stance is that it's
> unsigned.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Mario Figueiredo]

In article , 
breamore...@yahoo.co.uk says...
> 
> C and C++ are weakly and statically typed languages.  Python is a 
> strongly and dynamically typed language.  Therefore anything following 
> based on the above paragraph alone is wrong.
> 

Indeed. I confused strongly/weakly with static. I feel a a bit 
embarrased by it. My apologies.

But no. Nothing that follows from that paragraph is wrong, just because 
of that mistake.

It still stands that list was artifically created to make it look like 
type annotations on top of executable code is a feature of nearly every 
language in the book. When it is not!

Most particularly when it comes to statically typed languages, wich 
Steven didn't feel guilty of including there.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: why zip64_limit defined as 1<<31 -1?

[Mark Lawrence]

On 29/01/2015 00:55, jesse wrote:

the official zip format spec states clearly that normal zip file should
be <= 4G size instead 2G.  I just can not believe Python has such an
obvious bug.

People suggested monkey patch the ZIP64_LIMIT value to pass 2G, I am not
sure what will be the ramifications.



There are numerous open issues on bugs.python.org regarding the zipfile 
and zipimport modules.  Perhaps you'd like to help fix a few of them?


As an aside please don't top post on this list, thanks.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Python is DOOMED! Again!

[Mario Figueiredo]

In article <54c980cd$0$12981$c3e8da3$54964...@news.astraweb.com>, 
steve+comp.lang.pyt...@pearwood.info says...
> 
> Ian, that's obvious. Just open your eyes:
> 
> Scala
> def addInt( a:Int, b:Int ) : Int
> 
> Python
> def addInt( a:int, b:int ) -> int:
> 
> 
> They're COMPLETELY different. In Scala they are *type declarations*, not
> annotations. We're talking about annotations, not declarations. They're as
> different as cheese and a very slightly different cheese. Do try to keep
> up.
> 
> *wink*

The sarcasm is unnecessary. They are different yes. Are you on purpose 
confusing the syntax of a feature with its meaning? Because while you 
have a very similar syntax between Julia, Scala and Python. Their 
meanings are very different.

I think it is obvious to anyone that if a feature like type annotations 
are meant to be EVALUATED AT RUNTIME (and I myself gave you another 
example of Julia), it makes every sense for that feature to be a part of 
the programming language syntax. I could never argue against Julia or 
Scala type annotations on that basis. The syntax is an integral part of 
the executable code.

But when a feature is not meant for runtime evaluation, why should it 
clutter your executable code? Make me understand your reasoning?

Your list of programming languages is just plain wrong. To my knowledge 
(there's a few languages there I don't know and never used), none of 
those languages implement anything like Python. Type annotations in 
python are entirely ignored by the interpreter except to make them 
available to external libraries. This is a feature that I have seen 
implemented in numerous languages as a part of doc-like comments. Never, 
ever, as a part ofthe language syntax.
-- 
https://mail.python.org/mailman/listinfo/python-list

ANN: Python Meeting Düsseldorf - New Videos online

[eGenix Team: M.-A. Lemburg]

[This announcement is in German since it targets a local user group
 meeting in Düsseldorf, Germany]



WAS IST DAS PYTHON MEETING DÜSSELDORF ?

Das Python Meeting Düsseldorf ist eine Veranstaltung, die alle drei
Monate in Düsseldorf stattfindet und sich an Python Begeisterte aus
der Region wendet:

 http://pyddf.de/

Bei jedem Treffen werden Vorträge gehalten und anschließend in
Diskussionen vertieft. Die Meetings dauern üblicherweise ca. 2 Stunden
und münden anschließend in eine Restaurant-Session.

Teilnehmer kommen aus ganz Nordrhein-Westfalen, hauptsächlich
allerdings aus der näheren Umgebung.

Diese Nachricht ist auch online verfügbar:
http://www.egenix.com/company/news/Python-Meeting-Duesseldorf-Videos



NEUE VIDEOS

Um die Vorträge auch für andere Python Enthusiasten zugänglich zu
machen, nehmen wir die Vorträge auf, produzieren daraus Videos und
laden diese auf unseren PyDDF YouTube Channel hoch:

https://youtube.com/pyddf/

In den letzten Tagen haben wir die Videos der letzten Treffen
aufgearbeitet. Insgesamt sind 34 neue Videos dazugekommen. Viel Spaß
damit:

Python Meeting Düsseldorf 2015-01-20

https://www.youtube.com/watch?v=z_o6L5RkaiU&list=PLu2a6axgqUTzh81DNhnV2rTL6oCaKlZQr

Python Meeting Düsseldorf 2014-09-30

https://www.youtube.com/watch?v=AHUKRoJwPCE&list=PLu2a6axgqUTylZtifjbOhvP0z1zIh7n_1

Python Meeting Düsseldorf Sprint 2014 (2014-09-27/28)

https://www.youtube.com/watch?v=y3BH9OBAn88&list=PLu2a6axgqUTwD7U3nFLhNiArHVLb17Y1Q

Python Meeting Düsseldorf 2014-07-02

https://www.youtube.com/watch?v=1uJgXl4p9_I&list=PLu2a6axgqUTyDzIjWvz3NYQsqj8jT-G4J

Python Meeting Düsseldorf 2014-04-29

https://www.youtube.com/watch?v=P3oD9EswbN8&list=PLu2a6axgqUTzRO1bUn62cUAwMkIxw8UrM

Python Meeting Düsseldorf 2014-01-21

https://www.youtube.com/watch?v=Sd_fw8Ae49M&list=PLu2a6axgqUTz3PZfZowvKsZT3rTY2x7WO

Python Meeting Düsseldorf 2013-11-19

https://www.youtube.com/watch?v=6pryEma7Ams&list=PLu2a6axgqUTyykq74j4ARFDfCMp7d3YsP


Die vollständige Liste aller mehr als 70 Python Meeting Videos ist
über unsere Video Liste verfügbar:

http://www.egenix.com/library/pyddf/videos.html



WEITERE INFORMATIONEN

Weitere Informationen und Termine rund um das Python Meeting
Düsseldorf stehen auf unserer Webseite:

http://pyddf.de/

Mit freundlichen Grüßen,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 29 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> mxODBC Plone/Zope Database Adapter ...   http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


: Try our mxODBC.Connect Python Database Interface for free ! ::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Mark Lawrence]

On 29/01/2015 08:23, Mario Figueiredo wrote:

In article ,
breamore...@yahoo.co.uk says...


C and C++ are weakly and statically typed languages.  Python is a
strongly and dynamically typed language.  Therefore anything following
based on the above paragraph alone is wrong.



Indeed. I confused strongly/weakly with static. I feel a a bit
embarrased by it. My apologies.


Accepted, from me anyhow. Please remember the only person who never 
makes a mistake never does anything :)




But no. Nothing that follows from that paragraph is wrong, just because
of that mistake.


I should have emphasied the word *alone*, sorry about that.



It still stands that list was artifically created to make it look like
type annotations on top of executable code is a feature of nearly every
language in the book. When it is not!

Most particularly when it comes to statically typed languages, wich
Steven didn't feel guilty of including there.



I don't know enough about most other languages to comment, I'll leave 
that to the various gurus.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: ANN: unpyc3 - a python bytecode decompiler for Python3

[Cem Karan]

On Jan 28, 2015, at 5:02 PM, Chris Angelico  wrote:

> On Thu, Jan 29, 2015 at 8:52 AM, Devin Jeanpierre
>  wrote:
>> Git doesn't help if you lose your files in between commits, or if you
>> lose the entire directory between pushes.
> 
> So you commit often and push immediately. Solved.
> 
> ChrisA

Just to expand on what Chris is saying, learn to use branches.  I use git flow 
([1][2]), but you don't need it, plain old branches are fine.  Then you can 
have a feature branch like 'Joes_current', or something similar which you and 
only you push/pull from.  Whenever you're done with it, you can merge the 
changes back into whatever you & your group see as the real branch.  That is 
the model I use at work, and it works fairly well, and its saved me once 
already when the laptop I was working on decided to die on me.

Thanks,
Cem Karan

[1] http://nvie.com/posts/a-successful-git-branching-model/
[2] https://github.com/nvie/gitflow
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: unpyc3 - a python bytecode decompiler for Python3

[Devin Jeanpierre]

On Wed, Jan 28, 2015 at 4:34 PM, Steven D'Aprano
 wrote:
> Devin Jeanpierre wrote:
>> Git doesn't help if you lose your files in between commits,
>
> Sure it does? You just lose the changes made since the previous commit, but
> that's no different from restoring from backup. The restored file is only
> as up to date as the last time a backup was taken.

Yeah. My point here is that Drive/Dropbox take snapshots at much
shorter intervals than any reasonable person will commit with a DVCS,
so you lose much less.

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

Sort of Augmented Reality

[franssoa]

Hello,

(please excuse my english as is not my primary language)

- I own a webcam that take a picture of outside of my house once per minute.
- With a DVB sticker, I know the latitude, longitude and altitude of the
planes in my area.

I would like to print the data of the planes visibles on the pictures
taken by the webcam, like "my sky view" from program "planeplotter" [1].

Does anybody know what kind of tools/library I can use, in Python as is
the language I know the best.
Last thing : I'm a dumb in math...

François

[1] http://www.coaa.co.uk/planeplotter.htm
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[random832]

On Wed, Jan 28, 2015, at 13:16, Mark Lawrence wrote:
> C and C++ are weakly and statically typed languages.

"strong typing" has no meaning at all, and "weak typing" means "anything
I don't like".

The fact that you can add an int and a float, or that you can use any
object as a boolean, would make python weakly typed in some people's
eyes.
-- 
https://mail.python.org/mailman/listinfo/python-list

Отв: Python on armv7l router: C++ exceptions issue

[Alex Potapenko]

Found a solution myself. It looks like you have to explicitly link python with 
libgcc_s during build time to solve this problem. This looks like a uClibc bug
Regards,Alex 

 среда, 28 января 2015 19:44 Alex Potapenko  
писал(а):
   

 I run Python on an arm-brcm-linux-uclibcgnueabi router. Python was 
cross-compiled using hndtools-arm-linux-2.6.36-uclibc-4.5.3 toolchain. While 
trying to use deluge, I realised that there's something wrong with handling C++ 
exceptions in C++ extension modules: they're not being caught at all. I tested 
whether C++ exception handling works on my system in general, and concluded it 
does work fine. I then wrote a simple C++ extension module with a try-catch 
block in the init function, that has a "throw 1" in the try section and a 
"catch (...)" section (see module.cpp), and I got "terminate called after 
throwing an instance of 'int'" when trying to load the module. Tested this with 
Python 2.7.9 and 3.4.2, however I had similar issues with other versions, such 
as 2.7.3 and 2.6.9.
Does anyone happen to know what I can try here? Any help is greatly appreciated!


Thanks in advance,
Alex

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

[OT] fortran lib which provide python like data type

[1989lzhh]

Hi,
I am not sure here is the right place to ask this question, but I want to give 
it a shot:)
are there fortran libs providing python like data type, such as set, dict, list?
Thanks,
Yours liuzhenhai
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Ian Kelly]

On Thu, Jan 29, 2015 at 12:16 AM, Steven D'Aprano
 wrote:
> Besides, descriptors are
> handled by the metaclass, so we could write a metaclass that doesn't handle
> them.

Maybe this doesn't affect your argument, but they're actually handled
by the class's __getattribute__, not by the metaclass.

>>> class MyMeta(type):
...   def __getattribute__(cls, attr):
... raise AttributeError(attr)
...
>>> class MyClass(metaclass=MyMeta):
...   @property
...   def spam(self):
... return 42
...
>>> MyClass().spam
42
>>> class MyClass:
...   def __getattribute__(self, attr):
... return type(self).__dict__[attr]
...   @property
...   def spam(self):
... return 42
...
>>> MyClass().spam

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

Re: Python is DOOMED! Again!

[Steven D'Aprano]

random...@fastmail.us wrote:

> On Wed, Jan 28, 2015, at 13:16, Mark Lawrence wrote:
>> C and C++ are weakly and statically typed languages.
> 
> "strong typing" has no meaning at all, and "weak typing" means "anything
> I don't like".

I see you've been reading Chris Smith's essay on typing :-)

https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/

I think his essay is excellent, but his claim that strong and weak typing is
a meaningless distinction is excessive.

> The fact that you can add an int and a float, or that you can use any
> object as a boolean, would make python weakly typed in some people's
> eyes.

I think they would be wrong. Well, mostly wrong. But a little bit right.

We should agree that there is no universal, hard distinction between strong
and weak typing. But the names already suggest that -- there is no dividing
line between strong and weak. But we can certainly *rank* languages by
degrees of strength according to some standard, and if we agree on the
standard, we should agree on the rankings.

Even if we don't agree on a standard, we can surely agree on the two extreme
cases. Let's call them Foo and Bar language. They're both typed languages.

Foo language has no automatic coercions at all. Every type is utterly
distinct. The only way to convert a value of one type to another is with an
explicit XtoY function. Surely we can agree that Foo is a *very strongly
typed* language? (Perhaps even too strong?)

Bar language, on the other hand, tries extremely hard to ensure that every
type is automatically able to be coerced into every other type. The
coercion might not do what you expect, but it will do *something*:

{'a': 100, 'b': 300} + 5.0
=> 7.0

[1, 2, 3] + "hello"
=> [1, 2, 3, 'h', 'e', 'l', 'l', 'o']

"hello" + [1, 2, 3]
=> "hello[1, 2, 3]"

Bar will never give you a TypeError. I think we can agree that Bar is a
*very weakly typed* language.

There are degrees of strength, and I think that Python comes closer to the
Foo end than the Bar end. There are few automatic coercions, and most of
those are in the numeric tower according to the usual mathematical rules.


-- 
Steven

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

Re: Python is DOOMED! Again!

[Steven D'Aprano]

Mario Figueiredo wrote:

> In article ,
> breamore...@yahoo.co.uk says...
>> 
>> C and C++ are weakly and statically typed languages.  Python is a
>> strongly and dynamically typed language.  Therefore anything following
>> based on the above paragraph alone is wrong.
>> 
> 
> Indeed. I confused strongly/weakly with static. I feel a a bit
> embarrased by it. My apologies.
> 
> But no. Nothing that follows from that paragraph is wrong, just because
> of that mistake.
> 
> It still stands that list was artifically created to make it look like
> type annotations on top of executable code is a feature of nearly every
> language in the book. When it is not!
> 
> Most particularly when it comes to statically typed languages, wich
> Steven didn't feel guilty of including there.

Why should I feel guilty? You wrote:


"Static analysis cannot and should not clutter executable code."


But what are type declarations in statically typed languages like C, Pascal,
Haskell, etc.? They are used by the compiler for static analysis. The same
applies to type declarations in dynamically typed languages like Cobra and
Julia. And yet, there they are, in the executable code.

So there are a whole lot of languages, going all the way back to 1950s
languages like Fortran, to some of the newest languages which are only a
few years old like Go, both dynamically typed and statically typed, which
do exactly what you say languages "cannot and should not" do: they put type
information used for static analysis there in the code.

As I said, these languages disagree with you. You are not just arguing
against Guido, but against the majority of programming language designers
for 60+ years.



-- 
Steven

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

Re: Python is DOOMED! Again!

[Ian Kelly]

On Thu, Jan 29, 2015 at 1:34 AM, Mario Figueiredo  wrote:
> In article <54c980cd$0$12981$c3e8da3$54964...@news.astraweb.com>,
> steve+comp.lang.pyt...@pearwood.info says...
>>
>> Ian, that's obvious. Just open your eyes:
>>
>> Scala
>> def addInt( a:Int, b:Int ) : Int
>>
>> Python
>> def addInt( a:int, b:int ) -> int:
>>
>>
>> They're COMPLETELY different. In Scala they are *type declarations*, not
>> annotations. We're talking about annotations, not declarations. They're as
>> different as cheese and a very slightly different cheese. Do try to keep
>> up.
>>
>> *wink*
>
> The sarcasm is unnecessary. They are different yes. Are you on purpose
> confusing the syntax of a feature with its meaning? Because while you
> have a very similar syntax between Julia, Scala and Python. Their
> meanings are very different.
>
> I think it is obvious to anyone that if a feature like type annotations
> are meant to be EVALUATED AT RUNTIME (and I myself gave you another
> example of Julia), it makes every sense for that feature to be a part of
> the programming language syntax. I could never argue against Julia or
> Scala type annotations on that basis. The syntax is an integral part of
> the executable code.

Okay, I don't know enough about Scala's type system to discuss that
example in this context, so I won't try to. Let's instead focus on
another of the languages you listed: C. C includes types in its
syntax, which it uses for static analysis at compile time. At runtime,
it uses them for ... nothing. In fact, if you examine a compiled C
binary, you won't even find any type information in there. If you
dynamically load a C library containing a function that takes a
double, and you pass it a long, it won't even blink. It will just
assume that the data it received represents a double and proceed from
there.

Now with PEP 484 type annotations on the other hand, while the
suggested static analysis tools aren't used at runtime, the
annotations themselves are available to be evaluated at runtime. If
you want to write a decorator that examines the types of the arguments
of the function it decorates and does something nifty with them
(automatic registration of overloaded functions using PEP 443
generics, perhaps), there is absolutely nothing stopping you from
doing that.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Steven D'Aprano]

Mario Figueiredo wrote:

> In article <54c980cd$0$12981$c3e8da3$54964...@news.astraweb.com>,
> steve+comp.lang.pyt...@pearwood.info says...
>> 
>> Ian, that's obvious. Just open your eyes:
>> 
>> Scala
>> def addInt( a:Int, b:Int ) : Int
>> 
>> Python
>> def addInt( a:int, b:int ) -> int:
>> 
>> 
>> They're COMPLETELY different. In Scala they are *type declarations*, not
>> annotations. We're talking about annotations, not declarations. They're
>> as different as cheese and a very slightly different cheese. Do try to
>> keep up.
>> 
>> *wink*
> 
> The sarcasm is unnecessary. They are different yes. Are you on purpose
> confusing the syntax of a feature with its meaning? Because while you
> have a very similar syntax between Julia, Scala and Python. Their
> meanings are very different.

No they aren't. Their primary meaning is to declare the type used by the
parameter.



> I think it is obvious to anyone that if a feature like type annotations
> are meant to be EVALUATED AT RUNTIME (and I myself gave you another
> example of Julia), it makes every sense for that feature to be a part of
> the programming language syntax. I could never argue against Julia or
> Scala type annotations on that basis. The syntax is an integral part of
> the executable code.

Ah, you mean just like Python, where annotations are evaluated at runtime,
just like Julia:

py> def spam(n:int)-> getattr(sys, 'version'):
... return "spam"*n
...
py> spam.__annotations__
{'n': , 'return': '3.3.0rc3 (default, Sep 27 2012, 18:44:58)
\n[GCC 4.1.2 20080704 (Red Hat 4.1.2-52)]'}


Python has had annotations for over five years. They are evaluated at
runtime. They will continue to be evaluated at runtime.

One of the benefits of this system is that people may write *runtime*
type-checkers that use the same annotations that the lexical analysis tools
will use.

It is possible that you aren't following the meaning of this. The idea
behind PEP 484 is that Python will standardise on a single expected syntax
for type-hints, so that all of the following tools can agree on a set of
basic rules for interpreting the annotations:

- lexical type-checkers (those that operate on only the source code, 
  with no runtime information)
- alternate Python compilers, like MyPy, which perform compile-time 
  type checking
- IDEs and text editors, which may use lexical type info available
  in the source code to flag errors and offer auto-completion
- stand-alone tools such as correctness provers
- documentation generators
- runtime type-checkers
- runtime introspection tools

and more.

One of the rules is that the *standard* type-hints have to be simple enough
that a purely lexical tool like an IDE or editor can understand it without
needing to run arbitrary code. But the annotations themselves can be
arbitrarily complex Python expressions. Its just that then the tools
expecting type-hints won't be able to process those annotations from the
source code alone. Runtime introspection tools will not care, because they
don't see the expression, they only see the result of evaluating that
expression.


> But when a feature is not meant for runtime evaluation, why should it
> clutter your executable code? Make me understand your reasoning?

Perhaps you should ask the designers of Pascal, Go, Scheme, C, D, F# and all
those dozens and hundreds of other languages. They have a feature which is
not evaluated at runtime -- the type declarations -- and they put it in the
source code.

And why shouldn't they? Type declarations are source code!


> Your list of programming languages is just plain wrong. To my knowledge
> (there's a few languages there I don't know and never used), none of
> those languages implement anything like Python. 

Not so.


> Type annotations in 
> python are entirely ignored by the interpreter except to make them 
> available to external libraries. 


That is incorrect.

Perhaps you are confusing by the fact that the Python interpreter doesn't
give any meaning to annotations? It still evaluates them at runtime, and
stores the result in the function object.



-- 
Steven

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

ANN: Wing IDE 5.1 released

[Wingware]

Hi,

Wingware has released version 5.1 of Wing IDE, our cross-platform 
integrated development environment for the Python programming language.


Wing IDE features a professional code editor with vi, emacs, visual 
studio, and other key bindings, auto-completion, call tips, 
context-sensitive auto-editing, goto-definition, find uses, refactoring, 
a powerful debugger, version control, unit testing, search, project 
management, and many other features.


Wing IDE 5.1 adds multi-process and child process debugging, syntax 
highlighting in the shells, persistent time-stamped unit test results, 
auto-conversion of indents on paste, an XCode keyboard personality, 
support for Flask and Django 1.7, and many other minor features and 
improvements.  For details see http://wingware.com/news/2015-01-22


Free trial: http://wingware.com/wingide/trial
Downloads: http://wingware.com/downloads
Feature list: http://wingware.com/wingide/features
Sales: http://wingware.com/store/purchase
Upgrades: https://wingware.com/store/upgrade

Questions?  Don't hesitate to email us at supp...@wingware.com.

Thanks,

--

Stephan Deibel
Wingware | Python IDE

The Intelligent Development Environment for Python Programmers

wingware.com

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

Re: why zip64_limit defined as 1<<31 -1?

[Ian Kelly]

On Wed, Jan 28, 2015 at 5:55 PM, jesse  wrote:
> the official zip format spec states clearly that normal zip file should be
> <= 4G size instead 2G.  I just can not believe Python has such an obvious
> bug.
>
> People suggested monkey patch the ZIP64_LIMIT value to pass 2G, I am not
> sure what will be the ramifications.

Is the current value causing any actual problem? I'm not familiar with
the zipfile source, but from a brief scan it looks like all this does
is set the threshold at which it will output zip64 files instead of
classic zip files.
-- 
https://mail.python.org/mailman/listinfo/python-list

The Most Diabolical Python Antipattern

[Mark Lawrence]

The author is quite clear on his views here 
https://realpython.com/blog/python/the-most-diabolical-python-antipattern/ 
but what do you guys and gals think?


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: why zip64_limit defined as 1<<31 -1?

[Ian Kelly]

On Wed, Jan 28, 2015 at 2:36 PM, Chris Angelico  wrote:
> On Thu, Jan 29, 2015 at 5:53 AM, jesse  wrote:
>> should not it be 1<<32 -1(4g)?
>>
>> normal zip archive format should be able to support 4g file.
>>
>> thanks
>
> 1<<31-1 is the limit for a signed 32-bit integer. You'd have to look
> into the details of the zip file format to see whether that's the
> official limit or not; it might simply be that some (un)archivers have
> problems with >2GB files, even if the official stance is that it's
> unsigned.

The bug in which zip64 support was added indicates that the value was
indeed chosen as the limit of a signed 32-bit integer:

http://bugs.python.org/issue1446489
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Most Diabolical Python Antipattern

[Skip Montanaro]

On Thu, Jan 29, 2015 at 11:17 AM, Mark Lawrence  wrote:
>
> ... but what do you guys and gals think?

I saw that blog referenced elsewhere a day or two ago. I think he's
correct. There are the occasional instance where I need to recover
from an exception no matter what caused it. In cases where I fail to
report the traceback somewhere, I'm often left scratching my head.

In my mind, this is approximately as bad as an external library
(silently) calling exit().

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

3d printing slicer

[3D artist]

Hi everyone

I'm trying to run Nick Parker's 3d printing slicer.

https://github.com/nick-parker/python3Dplay/tree/master/Shift%20Method

I am using WinPython 2.7.9.1 to import scipy

https://winpython.github.io/

I get these errors when running main.py

Traceback (most recent call last):
  File "C:\Users\z003EE9Y\Desktop\WinPython-32bit-2.7.9.2\slicer\main.py", line 
10, in 
test = stl_importer.stl_import("model.stl")
  File 
"C:\Users\z003EE9Y\Desktop\WinPython-32bit-2.7.9.2\slicer\stl_importer.py", 
line 44, in stl_import
output=mesh.mesh(currentTris)
  File "C:\Users\z003EE9Y\Desktop\WinPython-32bit-2.7.9.2\slicer\mesh.py", line 
18, in __init__
self.updateLims()
  File "C:\Users\z003EE9Y\Desktop\WinPython-32bit-2.7.9.2\slicer\mesh.py", line 
28, in updateLims
self.region[0][0]=[[max(Xs),max(Ys),max(Zs)],[min(Xs),min(Ys),min(Zs)]]
ValueError: setting an array element with a sequence.
>>> 

Error 1 test = stl_importer.stl_import("model.stl")

Error 2 output=mesh.mesh(currentTris)

Error 3self.updateLims()

Error 4 
self.region[0][0]=[[max(Xs),max(Ys),max(Zs)],[min(Xs),min(Ys),min(Zs)]]

Thanks in advance
-- 
https://mail.python.org/mailman/listinfo/python-list

Results of the python 2.x and 3.x use survey, 2014 edition

[Bruno Cauet]

Hi!
Finally, here are the results:
http://blog.frite-camembert.net/python-survey-2014.html
Here is the auto-generated Google Forms recap:
https://docs.google.com/forms/d/1DqxkNi4GvyTCu54usSdE1DjW29zw1tc52iMeH3z4heg/viewanalytics
(more elegant than my matplotlib graphs - I'd have no future as a
designer).

Overall people started writing more python 3: +15 points in "I ever
wrote python 3 code", +10 points in "I write more python 3 than 2".
Transition is still ongoing and I hope a tipping point will be soon be
attained.
Users definitely seem to want to switch to python 3, but dependencies
keep them with 2.7 (I weep for the few ones still on 2.5).

I also posted the results on HN
(https://news.ycombinator.com/item?id=8967645) and reddit
(http://www.reddit.com/r/Python/comments/2u3oh0/results_of_the_python_2x_and_3x_use_survey_2014/).
Have a nice day, and a year full of python 3!

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

Re: The Most Diabolical Python Antipattern

[Ethan Furman]

On 01/29/2015 09:36 AM, Skip Montanaro wrote:
> On Thu, Jan 29, 2015 at 11:17 AM, Mark Lawrence  
> wrote:
>>
>> ... but what do you guys and gals think?
> 
> I saw that blog referenced elsewhere a day or two ago. I think he's
> correct. There are the occasional instance where I need to recover
> from an exception no matter what caused it. In cases where I fail to
> report the traceback somewhere, I'm often left scratching my head.

I agree -- worst practice.


> In my mind, this is approximately as bad as an external library
> (silently) calling exit().

Yeah, I hate when that happens.  I hate it even more when it's my own library. 
:/  (yeah, I fixed that!)

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[random832]

On Thu, Jan 29, 2015, at 10:56, Steven D'Aprano wrote:
> Bar language, on the other hand, tries extremely hard to ensure that
> every
> type is automatically able to be coerced into every other type. The
> coercion might not do what you expect, but it will do *something*:

See, this is where the concept falls apart. Many people will define a
dynamically-typed language as weakly-typed *only if* the result of the
automatic type coercion is unexpected/distasteful/fattening, even if it
is well-defined and predictable according to the rules of the language.
Which makes it a matter of personal taste.

> Bar will never give you a TypeError. I think we can agree that Bar is a
> *very weakly typed* language.

Statically typed lanugages by definition can never give you a TypeError
- there are no runtime conversions that can succeed or fail based on the
type of the arguments. What makes a statically typed language strong or
weak? Are statically typed languages always weak?

> 
> There are degrees of strength, and I think that Python comes closer to
> the
> Foo end than the Bar end. There are few automatic coercions, and most of
> those are in the numeric tower according to the usual mathematical rules.

Why is converting an int to a float when passed to a math function
better than converting any object to a string when passed to a string
function?
-- 
https://mail.python.org/mailman/listinfo/python-list

joke

[Automn]

What about : 

- "The royal Python is Clean your highness." 
- "Thank you."

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

Re: Python is DOOMED! Again!

[Mark Lawrence]

On 29/01/2015 18:23, random...@fastmail.us wrote:


Statically typed lanugages by definition can never give you a TypeError
- there are no runtime conversions that can succeed or fail based on the
type of the arguments. What makes a statically typed language strong or
weak? Are statically typed languages always weak?



They can give you lots of warnings about possible loss of data or 
similar.  Yes, you can silence these warnings if you know what you're 
doing.  You can also silence them if you don't know what you're doing. 
The end result could be a lovely, friendly segfault to debug.  What joy?


No, they're not always weakly typed.  The aim of the spreadsheet put up 
by Skip was to sort out (roughly) which languages belong in which camp. 
 I do not regard myself as suitably qualified to fill the thing out. 
Perhaps by now others have?


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: joke

[sohcahtoa82]

On Thursday, January 29, 2015 at 10:30:46 AM UTC-8, Automn wrote:
> What about : 
> 
> - "The royal Python is Clean your highness." 
> - "Thank you."

I don't get it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: joke

[Ethan Furman]

On 01/29/2015 10:58 AM, sohcahto...@gmail.com wrote:
> On Thursday, January 29, 2015 at 10:30:46 AM UTC-8, Automn wrote:
>> What about : 
>>
>> - "The royal Python is Clean your highness." 
>> - "Thank you."
> 
> I don't get it.

I suspect it is a reference to an old Eddie Murphy (?) movie in which he is a 
prince and has attendants to bathe him.

If I am correct it is an immature joke and has no place on this list.

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: why zip64_limit defined as 1<<31 -1?

[jesse]

On Jan 29, 2015 9:27 AM, "Ian Kelly"  wrote:
>
> On Wed, Jan 28, 2015 at 2:36 PM, Chris Angelico  wrote:
> > On Thu, Jan 29, 2015 at 5:53 AM, jesse  wrote:
> >> should not it be 1<<32 -1(4g)?
> >>
> >> normal zip archive format should be able to support 4g file.
> >>
> >> thanks
> >
> > 1<<31-1 is the limit for a signed 32-bit integer. You'd have to look
> > into the details of the zip file format to see whether that's the
> > official limit or not; it might simply be that some (un)archivers have
> > problems with >2GB files, even if the official stance is that it's
> > unsigned.
>
> The bug in which zip64 support was added indicates that the value was
> indeed chosen as the limit of a signed 32-bit integer:
>
> http://bugs.python.org/issue1446489

ok,  then why signed 32-bit integer instead of unsigned 32 integer? any
technical limitation reason? the chosen 2G boundary does not conform to zip
standard specification.

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

Re: why zip64_limit defined as 1<<31 -1?

[Ian Kelly]

On Thu, Jan 29, 2015 at 12:12 PM, jesse  wrote:
>
> On Jan 29, 2015 9:27 AM, "Ian Kelly"  wrote:
>>
>> On Wed, Jan 28, 2015 at 2:36 PM, Chris Angelico  wrote:
>> > On Thu, Jan 29, 2015 at 5:53 AM, jesse  wrote:
>> >> should not it be 1<<32 -1(4g)?
>> >>
>> >> normal zip archive format should be able to support 4g file.
>> >>
>> >> thanks
>> >
>> > 1<<31-1 is the limit for a signed 32-bit integer. You'd have to look
>> > into the details of the zip file format to see whether that's the
>> > official limit or not; it might simply be that some (un)archivers have
>> > problems with >2GB files, even if the official stance is that it's
>> > unsigned.
>>
>> The bug in which zip64 support was added indicates that the value was
>> indeed chosen as the limit of a signed 32-bit integer:
>>
>> http://bugs.python.org/issue1446489
>
> ok,  then why signed 32-bit integer instead of unsigned 32 integer? any
> technical limitation reason? the chosen 2G boundary does not conform to zip
> standard specification.

I don't know specifically, but as Chris said it may be to ensure
compatibility with unzip programs that use signed 32-bit integers.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: parsing tree from excel sheet

[alb]

Hi Peter,

Peter Otten <__pete...@web.de> wrote:
[]
>def show2(self):
>yield str(self)
>for child in self.children:
>yield from child.show2()

here is what I get:

> SyntaxError: invalid syntax
> debian@debian:example$ python3 export_latex.py doctree.csv 
>   File "export_latex.py", line 36
> yield from child.show2()
>  ^
> SyntaxError: invalid syntax

and I've tried with both python and python3 (see below versions).

debian@debian:example$ python
Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
debian@debian:example$ python3
Python 3.1.3 (r313:86834, Nov 28 2010, 11:28:10) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 

Is it an issue related to my installation? Shall I upgrade and/or 
downgrade?

Thanks for any hint,

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

Re: Fwd: Re: Comparisons and sorting of a numeric class....

[Andrew Robinson]

On 01/27/2015 02:04 AM, Gregory Ewing wrote:

Andrew Robinson wrote:

The spelling caveat is great -- and in Python the object named in 
bool's honor is spelled bool (lowercase too). ;)


That doesn't change the fact that the man was called
George Boole (not Charles!). If you're going to refer
to him by name, it's only courteous to make some effort
to get it right.

I stand corrected.  Thank you.


http://en.wikipedia.org/wiki/George_Boole



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

Re: Python is DOOMED! Again!

[Rick Johnson]

On Thursday, January 29, 2015 at 10:11:56 AM UTC-6, Steven D'Aprano wrote:
>
> But what are type declarations in statically typed
> languages like C, Pascal, Haskell, etc.? They are used by
> the compiler for static analysis. The same applies to type
> declarations in dynamically typed languages like Cobra and
> Julia. And yet, there they are, in the executable code.
>
> So there are a whole lot of languages, going all the way
> back to 1950s languages like Fortran, to some of the
> newest languages which are only a few years old like Go,
> both dynamically typed and statically typed, which do
> exactly what you say languages "cannot and should not" do:
> they put type information used for static analysis there
> in the code.
>
> As I said, these languages disagree with you. You are not
> just arguing against Guido, but against the majority of
> programming language designers for 60+ years.

Are we really going to base our design decisions on the same
emotional "need to belong" that a 14 year girl bases clothing
purchases on? Following your logic, it's high time we adopt
braces, since they have been just as long!

===
 WELCOME TO COMPUTER LANGUAGE JEOPARDY!
===
|--|---|-doot||
|--|---|-do--||
|--|---|---do||
|--dah---dah---|dahdah-|-do--||
|--|---|---do||
|do---doo-do-do|-dodo--|-do--||
|-doo--|---|-|doot|
===
   @2nd skip---> D.C.  

"And here is your host: Alex Trebek!

TREBEK: I swear i was not drunk when i sideswiped an array of mailboxes and 
ended up kissing a telephone pole in a ditch 45 feet away... so shut up about 
it already!

[snip: totally scripted introductions]

TREBEK: Okay let's begin!

PLAYER1: Alex, i'll take "Language Devolution" for 500 please.

TREBEK: Okay, and the answer is: "Python Type Hints"

(CHIME) PLAYER1: What does a book-licking contest look like?

*WNK*

TREBEK: Sorry, while your answer certainly is a product of such a proposal, 
we're looking for something more specific to the category of: "Language 
Devolution".

(CHIME) PLAYER2: Python Insanity Proposal?

*WNK*

TREBEK: Again, technically correct, but your answer must be in the form of a 
question!

(CHIME) PLAYER3: What happens after an emperor forsakes his clothing?

*DING-DING-DING*

TREBEK: Congrats, you're this weeks winner! Please stay tuned for a special 
episode of "Keeping Up With The Kewl Kids". Good night folks!

[This episode was sponsored by Alex's AA group]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: parsing tree from excel sheet

[MRAB]

On 2015-01-29 21:02, alb wrote:

Hi Peter,

Peter Otten <__pete...@web.de> wrote:
[]

   def show2(self):
   yield str(self)
   for child in self.children:
   yield from child.show2()


here is what I get:


SyntaxError: invalid syntax
debian@debian:example$ python3 export_latex.py doctree.csv
  File "export_latex.py", line 36
yield from child.show2()
 ^
SyntaxError: invalid syntax


and I've tried with both python and python3 (see below versions).

debian@debian:example$ python
Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.



debian@debian:example$ python3
Python 3.1.3 (r313:86834, Nov 28 2010, 11:28:10)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.




Is it an issue related to my installation? Shall I upgrade and/or
downgrade?


"yield from" was introduced in Python 3.3.

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

Re: parsing tree from excel sheet

[alb]

Hi Tim,

Tim Chase  wrote:
[]
>> I know about the xlrd module to get data from excel
> 
> If I have to get my code to read Excel files, xlrd is usually my
> first and only stop.
> 

It provides quite a good interface to manipulating excel files and I 
find it pretty easy even for my entry level!

>> Does anyone recommend any other path other than scripting through
>> these two modules?
> 
> Well, if you export from Excel as CSV, you can use the "csv" module
> in the standard library.  This is actually my preferred route because
> it prevents people (coughclientscough) from messing up the CSV file
> with formatting, joined cells, and other weirdnesses that can choke
> my utilities.

In my case there's no such risk of manipulating the excel file. I'm in 
charge of it! :-) Sure it might at a later stage be misused and messed 
up inadvertedly, but we're just trying to validate an idea, i.e. writing 
specs without using any word processor.

I'm trying to bypass the need to go through a mark up language (to a 
certain point), in order to facilitate the transition from an 
unstructured approach to document writing to a more structured one.

I would have proposed SGML or XML and style sheets but unfortunately is 
hard to move from M$Word to XML (OMG I need to write code?!?!!). So to 
facilitate the transition to a structured approach I've come up with the 
idea to go through an automatic generation of documents using excel as a 
UI.

In a later stage with could move onto a full-fledged database and have 
simpler web access, but using the same backend for generating documents 
(i.e. some parser and latex).

>> Is there any more suitable module/example/project out there that
>> would achieve the same result?
> 
> I don't believe there's anything that will natively do the work for
> you.  Additionally, you'd have to clarify what should happen if two
> rows in the same section had different sub-trees but the same
> content/name.  Based on your use-case (LaTex export using these as
> headers) I suspect you'd want a warning so you can repair the input
> and re-run.  But it would be possible to default to either keeping or
> squashing the duplicates.

Sure, there are corner cases that might mess up the whole structure, 
which at the moment is not too fool proof, but I'm trying to test the 
idea and see what I can come up with. Once the flow is in place I could 
think over some more reliable approach as an interface to a database.
 
>> p.s.: I'm not extremely proficient in python, actually I'm just
>> starting with it!
> 
> Well, you've come to the right place. Most of us are pretty fond of
> Python here. :-)

I've never understood people discarding newsgroups in favor of more 
'recent' technologies like social networks. Long live the USENET!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: parsing tree from excel sheet

[alb]

Hi MRAB,

MRAB  wrote:
[]
>>> SyntaxError: invalid syntax
>>> debian@debian:example$ python3 export_latex.py doctree.csv
>>>   File "export_latex.py", line 36
>>> yield from child.show2()
>>>  ^
>>> SyntaxError: invalid syntax
>>
>> and I've tried with both python and python3 (see below versions).
>>
>> debian@debian:example$ python
>> Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40)
>> [GCC 4.4.5] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>
>> debian@debian:example$ python3
>> Python 3.1.3 (r313:86834, Nov 28 2010, 11:28:10)
>> [GCC 4.4.5] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>
>>
>> Is it an issue related to my installation? Shall I upgrade and/or
>> downgrade?
>>
> "yield from" was introduced in Python 3.3.
> 

Ok, that either means I need to upgrade to 3.3 or need to modify the 
snippet to a suitable syntax that would work with other versions.

Considering that upgrading is something that I'm not keen to do on my 
production system I believe I've only have one available choice.

It seems I could use the generator and iterate with .next() in python 
2.6, at least from what I found here:
http://stackoverflow.com/questions/1756096/understanding-generators-in-python

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

Re: parsing tree from excel sheet

[Mark Lawrence]

On 29/01/2015 21:32, alb wrote:

Hi MRAB,

MRAB  wrote:
[]

SyntaxError: invalid syntax
debian@debian:example$ python3 export_latex.py doctree.csv
   File "export_latex.py", line 36
 yield from child.show2()
  ^
SyntaxError: invalid syntax


and I've tried with both python and python3 (see below versions).

debian@debian:example$ python
Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.



debian@debian:example$ python3
Python 3.1.3 (r313:86834, Nov 28 2010, 11:28:10)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.




Is it an issue related to my installation? Shall I upgrade and/or
downgrade?


"yield from" was introduced in Python 3.3.



Ok, that either means I need to upgrade to 3.3 or need to modify the
snippet to a suitable syntax that would work with other versions.

Considering that upgrading is something that I'm not keen to do on my
production system I believe I've only have one available choice.

It seems I could use the generator and iterate with .next() in python
2.6, at least from what I found here:
http://stackoverflow.com/questions/1756096/understanding-generators-in-python

Al



I'd be inclined to upgrade, see here 
https://www.python.org/dev/peps/pep-0380/#formal-semantics for why :)


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: An object is an instance (or not)?

[Rick Johnson]

On Wednesday, January 28, 2015 at 4:01:41 AM UTC-6, Chris Angelico wrote:
> On Wed, Jan 28, 2015 at 8:16 PM, Steven D'Aprano wrote:
> > Or perhaps that should be a sad face smiley :-( How much
> > time we would all save if academics and language
> > designers would only stick to a single consistent
> > terminology across all languages.
>
> That's like wishing that every human spoke the same
> language, instead of having English, French, Italian,
> Polish, Serbian, Korean, and a host of others. The problem
> isn't the languages; the variety of languages reflects a
> variety of concepts being communicated,

Yes guys, because everyone knows that "selfish adolescent
accessorizing" is the *KEY* to building a sane human
knowledge base! I mean, who needs a single word (or grunt)
to mean, say, "cat-herding", when infinitely more selfish
incarnations can be invented on the fly!!!

##
# Untested Code:
##

 def pollute_the_database(concept):
 for region in world.regions:
 # XXX: Avoid buffer overflows!
 grunt = region.generate_grunt(concept)
 database.setdefault(concept, {"aliases":[]})
 database[concept]["aliases"].append(str(grunt))

 if __game__ == "__existentialism__":
 concepts = humans.collectiveConciseness
 database = humans.collectiveDatabase
 while len(concepts) > 0:
 # XXX: Make thread safe!
 conceptN = concepts.pop()
 if is_selfishly_infantile(humans):
 pollute_the_database(conceptN)
 else:
 # Dead code follows :-'(
 word = world.generate_grunt(conceptN)
 database[concept] = word
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: parsing tree from excel sheet

[Chris Kaynor]

On Thu, Jan 29, 2015 at 1:59 PM, Mark Lawrence  wrote:
> On 29/01/2015 21:32, alb wrote:
>>
>> Hi MRAB,
>>
>> MRAB  wrote:
>> []
>
> SyntaxError: invalid syntax
> debian@debian:example$ python3 export_latex.py doctree.csv
>File "export_latex.py", line 36
>  yield from child.show2()
>   ^
> SyntaxError: invalid syntax


 and I've tried with both python and python3 (see below versions).

 debian@debian:example$ python
 Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40)
 [GCC 4.4.5] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>
 debian@debian:example$ python3
 Python 3.1.3 (r313:86834, Nov 28 2010, 11:28:10)
 [GCC 4.4.5] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>

 Is it an issue related to my installation? Shall I upgrade and/or
 downgrade?

>>> "yield from" was introduced in Python 3.3.
>>>
>>
>> Ok, that either means I need to upgrade to 3.3 or need to modify the
>> snippet to a suitable syntax that would work with other versions.
>>
>> Considering that upgrading is something that I'm not keen to do on my
>> production system I believe I've only have one available choice.
>>
>> It seems I could use the generator and iterate with .next() in python
>> 2.6, at least from what I found here:
>>
>> http://stackoverflow.com/questions/1756096/understanding-generators-in-python
>>
>> Al
>>
>
> I'd be inclined to upgrade, see here
> https://www.python.org/dev/peps/pep-0380/#formal-semantics for why :)

While that is true, most of that code is needed to handle the odd
corner cases and exceptions that could happen, as well as supporting
generator.throw and generator.send, while also ensuring proper and
quick clean-up of the objects.

>From what I could see at a quick glance, none of that is really needed
in the simple case in the posted code, and as such, it is LIKELY safe
to just replace "yield from ..." with "for item in ...: yield item".

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

Re: The Most Diabolical Python Antipattern

[Tim Chase]

On 2015-01-29 17:17, Mark Lawrence wrote:
> The author is quite clear on his views here 
> https://realpython.com/blog/python/the-most-diabolical-python-antipattern/ 
> but what do you guys and gals think?

I just read that earlier today and agree for the most part.  The only
exception (pun only partially intended) I've found is in functions
that need to return a defined type.  I have one that I call int0()
that is my "give me a freakin' int" function which is something like

  def int0(val):
try:
  return int(val)
except:
  return 0

because I deal with a lot of CSV data from client/vendor that has
blanks, "NULL", "---", and plenty of other rubbish to suggest
something that, for my purposes is really just a 0.

Yes, I've been stung by it occasionally, but it's not much trouble to
see that I'm getting a 0 some place that should have a value I need
to extract.

-tkc


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

Re: [OT] fortran lib which provide python like data type

[beliavsky]

On Thursday, January 29, 2015 at 10:01:00 AM UTC-5, Liu Zhenhai wrote:
> Hi,
> I am not sure here is the right place to ask this question, but I want to 
> give it a shot:)
> are there fortran libs providing python like data type, such as set, dict, 
> list?
> Thanks,
> Yours liuzhenhai

The "Fortran library" http://bigdft.org/Wiki/index.php?title=Fortran_library 
appears to have some of what you want. I have not tried the code.

"The flib library provides an object called dictionary which is -- strictly 
speaking -- more than just a dictionary. It is polymorphic and can be a list or 
a dictionary, as in the python language. The other difference is that it keeps 
the order of the elements, which is very useful if we want to dump its contents 
to the yaml output. It represents indeed a tree of data, and for these reasons 
it will most likely change name into f_tree in a future release of the module.

These dictionaries are also used in the other parts of the flib library and are 
thus essential for its proper use. There are many examples in the file 
dicts.f90."
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Most Diabolical Python Antipattern

[Ian Kelly]

On Thu, Jan 29, 2015 at 10:32 AM, Tim Chase
 wrote:
> On 2015-01-29 17:17, Mark Lawrence wrote:
>> The author is quite clear on his views here
>> https://realpython.com/blog/python/the-most-diabolical-python-antipattern/
>> but what do you guys and gals think?
>
> I just read that earlier today and agree for the most part.  The only
> exception (pun only partially intended) I've found is in functions
> that need to return a defined type.  I have one that I call int0()
> that is my "give me a freakin' int" function which is something like
>
>   def int0(val):
> try:
>   return int(val)
> except:
>   return 0
>
> because I deal with a lot of CSV data from client/vendor that has
> blanks, "NULL", "---", and plenty of other rubbish to suggest
> something that, for my purposes is really just a 0.
>
> Yes, I've been stung by it occasionally, but it's not much trouble to
> see that I'm getting a 0 some place that should have a value I need
> to extract.

At least use "except Exception" instead of a bare except. Do you
really want things like SystemExit and KeyboardInterrupt to get turned
into 0?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[BartC]

On 22/01/2015 04:30, Steven D'Aprano wrote:


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



Here's a potential real-world example, from the statistics module in Python
3.4, before and after adding annotations:

def median_grouped(data, interval=1): ...

def median_grouped(data:Iterable[Real], interval:Real=1)->Real: ...



So how does Python's proposed type-hints compared to that used by other
languages?



C:

   double
   median_grouped (IterableOfReal data, double interval)



I think it is clear that Python's annotation syntax remains quite close to
executable pseudo-code. Fears that type-hints will doom Python are not
credible.


I've read most of the thread but haven't been able to figure out /why/ 
this is being proposed. What is the advantage, speed?


And how does it work in practice: is it necessary to use a special 
Python interpreter to gain the advantage, or do you only get a benefit 
after putting the source through some sort of compiler system?


I can understand many of the misgivings. I have a dynamic language of my 
own, to which I've tried adding type hinting a few times, but in the end 
decided to get rid of those type hints and keep things purer and simpler 
(and a hell of a lot easier to implement too).


There was also something unsatisfactory about having to help things 
along by putting in explicit hints, which also cause trouble: what 
happens when the promise you make are wrong? It would mean putting in 
extra checking code to make sure things are what you said.


So when assigning a non-hinted variable to a hinted one, it needs to be 
type-checked, otherwise things can go wrong internally. So far from 
making things faster, it starts by slowing them down!


Putting in hints, (as as I implemented them using primitive types), 
meant that functions and code no longer worked in a generic (or 
polymorphic) manner. Code also changes, but the type hints aren't 
maintained. I understand the Python proposal allows type hints to be a 
union of expected types, but that sounds complicated.


Depending on how it's implemented, it also seems to me that a program 
with type hints might work with a Python implementation that ignores the 
hints, but might not work with one that makes use of the hints (because 
of using a value that is not of the hinted type).


Also, how does it work with numeric types; is there just one numeric 
type, or two (integer and real) or more? With more than one numeric type 
hint, it's going to be a headache trying to determine what the result of 
a function can be. (And if you have to choose real because 1% of the 
time the result will be real, then you lose the advantage of being able 
to work with integers 99% of the time.)


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

Re: Python is DOOMED! Again!

[Chris Angelico]

On Fri, Jan 30, 2015 at 9:57 AM, BartC  wrote:
> I've read most of the thread but haven't been able to figure out /why/ this
> is being proposed. What is the advantage, speed?

Have a read of the PEP:

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

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

Re: The Most Diabolical Python Antipattern

[Chris Angelico]

On Fri, Jan 30, 2015 at 4:32 AM, Tim Chase
 wrote:
> I have one that I call int0()
> that is my "give me a freakin' int" function which is something like
>
>   def int0(val):
> try:
>   return int(val)
> except:
>   return 0
>
> because I deal with a lot of CSV data from client/vendor that has
> blanks, "NULL", "---", and plenty of other rubbish to suggest
> something that, for my purposes is really just a 0.

What's wrong with "except (TypeError, ValueError):" here? Or even just
"except ValueError:", which seems to be what you want? The bare except
is still a problem.

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

Re: Python is DOOMED! Again!

[Chris Kaynor]

On Thu, Jan 29, 2015 at 2:57 PM, BartC  wrote:
> I've read most of the thread but haven't been able to figure out /why/ this
> is being proposed. What is the advantage, speed?

Check out the rationale part of the PEP:
https://www.python.org/dev/peps/pep-0484/#rationale-and-goals. Other
parts of the PEP also answer many of the other questions you have.
I've put in my understandings and opinions below, however.


There are a few perceived advantages to adding type-hints, some of
which are more pie-in-the-sky while others are very likely:
- IDEs can use them to provide better auto-complete.
- Static checkers can do a better job of checking for program
correctness (by erroring if the type-hints are obviously broken).
- Possibility of performance improvements, although CPython (the
official Python interpreter) will still be required to work if the
type-hints are wrong.

> And how does it work in practice: is it necessary to use a special Python
> interpreter to gain the advantage, or do you only get a benefit after
> putting the source through some sort of compiler system?

CPython will, initially, do nothing special with the type-hints that
it does not currently do with the existing annotations, which is
merely parse them and ensure they meet the syntax requirements. My
understanding is that there will be a static checker (possibly derived
from MyPy) that will be endorsed, however, and possibly included in
the STD.

> I can understand many of the misgivings. I have a dynamic language of my
> own, to which I've tried adding type hinting a few times, but in the end
> decided to get rid of those type hints and keep things purer and simpler
> (and a hell of a lot easier to implement too).
>
> There was also something unsatisfactory about having to help things along by
> putting in explicit hints, which also cause trouble: what happens when the
> promise you make are wrong? It would mean putting in extra checking code to
> make sure things are what you said.

As a rule, breaking the type-hint promises will have no effect on the
run-time. Some implementations (Cython or PyPy) may decide to use the
type-hints to guide optimization, perhaps by creating a fast path for
if the promises are met, however conforming implementations cannot
rely on them being correct. PyPy, for example, could JIT the function
presuming the types are right, therefore front-loading the JIT time.
I'm not saying they WILL, just that they COULD.

> So when assigning a non-hinted variable to a hinted one, it needs to be
> type-checked, otherwise things can go wrong internally. So far from making
> things faster, it starts by slowing them down!

See above. The current plan is not to generally use the hinting at
run-time, but only during static checking of the code. For cases like
PyPy, they already have to do run-time type checking to ensure
correctness when running optimized paths.

> Putting in hints, (as as I implemented them using primitive types), meant
> that functions and code no longer worked in a generic (or polymorphic)
> manner. Code also changes, but the type hints aren't maintained. I
> understand the Python proposal allows type hints to be a union of expected
> types, but that sounds complicated.

Regarding the maintenance of type-hints, for people who heavily use
them, I would imagine they will have a static checker setup which will
regularly run and generally produce an error if the hints are not
updated. Most other people will likely only lightly use the type-hints
and may not use static checkers, and thus they probably will get out
of sync. With such a feature, my main use case would be to aid IDEs in
providing auto-complete, which I've done in the past by adding lines
like "if 0: assert isinstance(variable, type)". Most of the functions
I write do not have any such "hints" but instead I've only generally
used it in cases where the type is pretty much fixed, but is a custom
type with a more complicated API.

For the most part, I would almost never use the union types. From past
experience (from languages like C++ and C#), such tends to vastly over
complicate the definitions. The same applies to most cases of generic
types (think list, tuple, set, dict).

> Depending on how it's implemented, it also seems to me that a program with
> type hints might work with a Python implementation that ignores the hints,
> but might not work with one that makes use of the hints (because of using a
> value that is not of the hinted type).
>
> Also, how does it work with numeric types; is there just one numeric type,
> or two (integer and real) or more? With more than one numeric type hint,
> it's going to be a headache trying to determine what the result of a
> function can be. (And if you have to choose real because 1% of the time the
> result will be real, then you lose the advantage of being able to work with
> integers 99% of the time.)

My understanding is that you would generally use one of "int",
"float", "Decimal", "Rational", "complex", e

Re: parsing tree from excel sheet

[Chris Angelico]

On Fri, Jan 30, 2015 at 8:32 AM, alb  wrote:
> Ok, that either means I need to upgrade to 3.3 or need to modify the
> snippet to a suitable syntax that would work with other versions.

You could replace "yield from child.show2()" with:

for val in child.show2(): yield val

and it should work. However, you're running Python 3.1, and a *lot* of
improvements have been made since then, so it's well worth upgrading.

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

Installling ADODB on an offline computer

[Alan Meyer]

I work on an application that uses the ActivePython compilation of 
Python from ActiveState.  It uses three Microsoft COM libraries that are 
needed for talking to SQL Server.  The libraries are:


Microsoft Activex Data Objects
Microsoft Activex Data Objects Recordset
Microsoft ADO Ext

In the past, we have installed those libraries on numerous machines by 
running makepy.py.  It can be done from the ActivePython IDLE GUI, or 
from the command line.  makepy.py downloads and installs the packages 
for us, taking care of COM server or client registration, or whatever it 
is that has to be done (I don't really know much about this stuff.)


Now I've been asked to port the application to a computer that is not 
connected to the Internet.  I haven't found any way to get those 
packages.  I haven't found a way to, for example, download the packages 
to files, place the files on the target computer, and run makepy.py or a 
setup.py to install them.


Can someone suggest a way to do it?

Thank you very much.

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

Re: [OT] fortran lib which provide python like data type

[Rustom Mody]

On Friday, January 30, 2015 at 4:09:19 AM UTC+5:30, beli...@aol.com wrote:
> On Thursday, January 29, 2015 at 10:01:00 AM UTC-5, Liu Zhenhai wrote:
> > Hi,
> > I am not sure here is the right place to ask this question, but I want to 
> > give it a shot:)
> > are there fortran libs providing python like data type, such as set, dict, 
> > list?
> > Thanks,
> > Yours liuzhenhai
> 
> The "Fortran library" http://bigdft.org/Wiki/index.php?title=Fortran_library 
> appears to have some of what you want. I have not tried the code.
> 
> "The flib library provides an object called dictionary which is -- strictly 
> speaking -- more than just a dictionary. It is polymorphic and can be a list 
> or a dictionary, as in the python language. The other difference is that it 
> keeps the order of the elements, which is very useful if we want to dump its 
> contents to the yaml output. It represents indeed a tree of data, and for 
> these reasons it will most likely change name into f_tree in a future release 
> of the module.
> 
> These dictionaries are also used in the other parts of the flib library and 
> are thus essential for its proper use. There are many examples in the file 
> dicts.f90."

Interesting

Note the very first minimal example

FORTRAN

 use dictionary
 type(dictionary), pointer :: d
 d=>dict_new()
 call set(d//'toto',1)
 v = d//'toto'
 call dict_free(d)

The corresponding python

 d = dict()
 d['toto'] = 1
 v = d['toto']
 del(d)

In particular note the del in the python.

Should highlight the point that languages with gc, support data structures
in a way that gc-less languages - Fortran, C, C++ - do not and cannot.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[MRAB]

On 2015-01-29 23:25, Chris Kaynor wrote:

On Thu, Jan 29, 2015 at 2:57 PM, BartC  wrote:

[snip]

Putting in hints, (as as I implemented them using primitive types),
meant that functions and code no longer worked in a generic (or
polymorphic) manner. Code also changes, but the type hints aren't
maintained. I understand the Python proposal allows type hints to
be a union of expected types, but that sounds complicated.


Regarding the maintenance of type-hints, for people who heavily use
them, I would imagine they will have a static checker setup which
will regularly run and generally produce an error if the hints are
not updated. Most other people will likely only lightly use the
type-hints and may not use static checkers, and thus they probably
will get out of sync. With such a feature, my main use case would be
to aid IDEs in providing auto-complete, which I've done in the past
by adding lines like "if 0: assert isinstance(variable, type)". Most
of the functions I write do not have any such "hints" but instead
I've only generally used it in cases where the type is pretty much
fixed, but is a custom type with a more complicated API.


I suppose you could check what types the arguments are by running the
code and outputting the types supplied, and then run a script that uses
the info to modify the source, and then you can diff the result.

Here's a simple example I've come up with:


#! python3.4
# -*- coding: utf-8 -*-
import inspect

def check_hints(func):

def wrapper(*args, **kwargs):
sig = inspect.signature(func)
print('file  :', inspect.getfile(func))
print('function  :', func.__name__)
print('line  :', inspect.getsourcelines(func)[1] + 1)

args_given = list(args)
kwargs_given = dict(kwargs)

for name in sig.parameters:
param = sig.parameters[name]
if param.kind == inspect.Parameter.POSITIONAL_OR_KEYWORD:
annotation = param.annotation
if args_given:
print('parameter : {} : {}'.format(name,
  type(args_given.pop(0)).__name__))
if annotation != inspect.Parameter.empty:
print('annotation: {} : {}'.format(name,
  annotation.__name__))
else:
try:
print('parameter : {} : {}'.format(name,
  type(kwargs_given.pop(name)).__name__))
if annotation != inspect.Parameter.empty:
print('annotation: {} : {}'.format(name,
  annotation.__name__))
except KeyError:
pass

result = func(*args, **kwargs)

print('return: {}'.format(type(result).__name__))
annotation = sig.return_annotation
if annotation != inspect.Parameter.empty:
print('annotation: {}'.format(annotation.__name__))

print()

return result

return wrapper

@check_hints
def foo(arg1: int, arg2: str, arg3: float=2.0) -> int:
pass

@check_hints
def bar(arg1, arg2, arg3=2.0):
pass

foo(1, "bar")
foo("baz", 2, 3.0)

bar(1, "bar")
bar("baz", 2, 3.0)
--
https://mail.python.org/mailman/listinfo/python-list

Re: Sort of Augmented Reality

[Rustom Mody]

On Friday, January 30, 2015 at 7:52:58 AM UTC+5:30, Dennis Lee Bieber wrote:
> On Thu, 29 Jan 2015 14:38:20 +0100, franssoa
> declaimed the following:
> 
> >Hello,
> >
> >(please excuse my english as is not my primary language)
> >
> >- I own a webcam that take a picture of outside of my house once per minute.
> >- With a DVB sticker, I know the latitude, longitude and altitude of the
> >planes in my area.
> >
> >I would like to print the data of the planes visibles on the pictures
> >taken by the webcam, like "my sky view" from program "planeplotter" [1].
> >
> >Does anybody know what kind of tools/library I can use, in Python as is
> >the language I know the best.
> >Last thing : I'm a dumb in math...
> >
>   Yet math is the main factor needed as you will need to know:

Saw this somewhere:

There are two Great Sins in the world - the Sin of Ignorance, 
and the Sin of Stupidity. Only the former may be overcome.

Is 'dumb' in the first or second category??
Your call...

Like smelly cheese and classical music, math is an acquired taste.
Actually enjoyable once you get past the initiation
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Most Diabolical Python Antipattern

[Marko Rauhamaa]

Ian Kelly :

> At least use "except Exception" instead of a bare except. Do you
> really want things like SystemExit and KeyboardInterrupt to get turned
> into 0?

How about:

==
try:
do_interesting_stuff()
except ValueError:
try:
log_it()
except:
pass
raise
==

Surprisingly this variant could raise an unexpected exception:

==
try:
do_interesting_stuff()
except ValueError:
try:
log_it()
finally:
raise
==

A Python bug?


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

Re: The Most Diabolical Python Antipattern

[Michiel Overtoom]

On Jan 29, 2015, at 18:36, Skip Montanaro wrote:

> There are the occasional instance where I need to recover
> from an exception no matter what caused it.

I had the same need, a while ago, when working on a CherryPy webapp which uses 
a BackgroundTask to parse user-uploaded data and image files (and that can 
throw a variety of exceptions). Any uncaught exception from a BackgroundTask 
will terminate the background thread, which is not good, because one rotten 
input file shouldn't spoil it for the rest. It was also unpredictable what kind 
of exceptions underlying modules would throw without going through all the 
sources with a fine comb. Thus, I wrote a decorator which will catch any 
exception (but not KeyboardInterrupt and SystemExit of course):


# alwayscatch.py - Software by Michiel Overtoom, mot...@xs4all.nl
#
# decorator to wrap an entire function in a try..except block
# to prevent any exception to reach the caller (except SystemExit and 
KeyboardInterrupt)
# because in that case some vital backgroundtask in a webframework will stop 
working.

def alwayscatch(logfunc=None, locus=None):
def deco(wrappee):
def wrapper(*args, **kwargs):
try:
return wrappee(*args, **kwargs)
except KeyboardInterrupt, SystemExit:
raise
except Exception as e:
if logfunc:
logfunc(locus, "Developer sloppyness and/or unrecognized 
situation", e)
else:
print "No logging func defined"
return wrapper
return deco


def frameworklogfunc(locus, msg, exc):
print "[%s] %s: '%s'" % (locus, msg, str(exc))


@alwayscatch(frameworklogfunc, "SUBSYSTEM")
def protectedfunc(x, y, color=23):
return x / y / color


@alwayscatch()
def sillyfunc(a, b, c):
return a / b / c


if __name__ == "__main__":
print protectedfunc(900, 2, 0)
print sillyfunc(900, 2, 0)


...and I used it like this, from the main program:

sizer = cherrypy.process.plugins.BackgroundTask(10, sizer.scan)
sizer.start()

...where the worker function is defined like this:

@alwayscatch(scanlogerror, "SIZE")
def scan():
...

...and the custom logging function: (cherrypy.log in its turn uses the standard 
logging framework)

def scanlogerror(locus, msg, exc):
cherrypy.log("Uncaught exception: %s" % exc, locus, logging.ERROR)


Greetings,

-- 
"You can't actually make computers run faster, you can only make them do less." 
- RiderOfGiraffes

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

Re: The Most Diabolical Python Antipattern

[jtan]

I would usually just log the stack trace so that I would still know that
something bad happened while the app looks okay.

On Fri, Jan 30, 2015 at 1:17 AM, Mark Lawrence 
wrote:

> The author is quite clear on his views here https://realpython.com/blog/
> python/the-most-diabolical-python-antipattern/ but what do you guys and
> gals think?
>
> --
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
>
> Mark Lawrence
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Freelance Grails
 and Java
 developer
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Christian Gollwitzer]

Am 30.01.15 um 02:40 schrieb Rustom Mody:
> FORTRAN
> 
>  use dictionary
>  type(dictionary), pointer :: d
>  d=>dict_new()
>  call set(d//'toto',1)
>  v = d//'toto'
>  call dict_free(d)
> 
> The corresponding python
> 
>  d = dict()
>  d['toto'] = 1
>  v = d['toto']
>  del(d)
> 
> In particular note the del in the python.
> 
> Should highlight the point that languages with gc, support data structures
> in a way that gc-less languages - Fortran, C, C++ - do not and cannot.

For C++ this is not correct. Ususally a garbage collector is not used -
though possible - but the constructor/destructor/assignment op in C++
(usually called RAII) provide semantics very similar to the CPython
refcounting behaviour.

For example, I made a set of C++ interface methods to return nested
dicts/list to Python, which is far from complete, but allows to write
something like this:

SWList do_something(SWDict attrs) {
  SWList result;
  for (int i=0; i<5; i++) {
SWDict entry;   
entry.insert("count", i);
entry.insert("name", "something");
result.push_back(entry);
  }
  return result;
}


There is also Boost::Python which does the same, I think, and much more,
but only supports Python, whereas I use SWIG to interface these
dicts/lists to both CPython and Tcl.

You cannot, however, resolve certain cyclic dependencies with pure
reference counting.

Christian

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