Re: Best Practices for Internal Package Structure

[Michael Selik]

On Wed, Apr 6, 2016, 2:51 AM Steven D'Aprano  wrote:

> On Wed, 6 Apr 2016 05:56 am, Michael Selik wrote:
>
> [Sven R. Kunze]
> >> If you work like in the 80's, maybe. Instead of scrolling, (un)setting
> >> jumppoints, or use splitview of the same file, it's just faster/easier
> to
> >> jump between separate files in todays IDEs if you need to jump between 4
> >> places within 3000 lines of code.
>
> [Michael]
> > When you made that suggestion earlier, I immediately guessed that you
> were
> > using PyCharm. I agree that the decision to split into multiple files or
> > keep everything in just a few files seems to be based on your development
> > tools. I use IPython and SublimeText, so my personal setup is more suited
> > to one or a few files.
>
> How does PyCharm make the use of many files easier?
>

I'll let Sven answer that one. I don't know, but I've noticed the
correlation of habit to IDE.

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

Re: ANN: intervalset Was: Set type for datetime intervals

[Michael Selik]

On Tue, Apr 5, 2016, 10:46 PM Nagy László Zsolt 
wrote:

>
> >> How about creating two classes for this? One that supports zero sized
> >> intervals, and another that doesn't?
> > If you don't want zero sized intervals, just don't put any in it. You
> > don't have a separate list type to support even integers vs one that
> > supports all floats. What operations are made different in
> > implementation by this restriction?
> When you substract two sets, zero sized intervals may appear in the
> result. It is not just a question of "putting or not putting them in".
> Are zero sized intervals valid or not? In my particular application,
> they are not. I think Michael was right: this cannot be generalized. It
> is application dependent.
>

To emphasize that in your project, I'd keep the interval code in the same
module you have the time calculations, rather than breaking it into a more
generic sounding module. Once you relax your goals, you might not even need
a class, just one or a few functions.

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

Re: Promoting Python

[Gregory Ewing]

Another option for graphical stuff is pygame:

http://pygame.org/news.html

A rough translation of some of your code:

import pygame, sys
from pygame import display, draw, event, font, Color, QUIT

# Set up the display window
screen = display.set_mode((800, 600))

colors = ["red", "orange", "yellow", "green", "blue", "purple"]

font.init()
f = font.Font(None, 24)
y = 10
for name in colors:
text = f.render("Color " + name, True, Color(name))
screen.blit(text, (10, y))
y += text.get_height()

x = 30
y = 200
for name in colors:
c = Color(name)
draw.circle(screen, c, (x, y), 20)
x += 50

# Refresh the screen
display.flip()

# Pause until the window is closed
while True:
for e in event.get():
if e.type == QUIT:
sys.exit(0)

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

Basic plugin architecture

[Nick Sarbicki]

Hi,

Question on how people here would design a basic plugin architecture:

I'm playing with the idea of having a pluggable system where the users can
create some simple classes which can then be accessed in a Django app.

I want to make it as __simple__ as possible for the user. Hopefully to the
point of being able to make a .py file and then drag and drop it into the
plugins folder. The result should be a dropdown later on with the list of
available classes.

Providing the list of classes once imported should be simple.

Actually importing the classes dynamically has caused a few issues.

I have a solution but wanted to know if anyone had better ideas.

Folder structure is:

├run.py
└loader/
  ├─plugins/
  │ ├─__init__.py
  │ ├─plugin1.py
  │ └─plugin2.py
  ├─__init__.py
  ├─models.py
  ├─views.py
  └─etc.py

My current solution is:

loader/plugins/__init__.py
> import glob
> import importlib
> import os
>
> def is_valid_plugin(plugin):
> return os.path.isfile(plugin) and not
os.path.basename(plugin).startswith('_')
>
> package = 'loader.plugins'
>
> plugins_to_import = [plugin for plugin in
glob.glob(os.path.dirname(__file__) + '/*.py') if is_valid_plugin(plugin)]
>
> plugins = [importlib.import_module('.' + os.path.basename(plugin)[:-3],
package) for plugin in plugins_to_import]

In relative terms I'm looking at the packages from the same position as
run.py, so would import as:

> from loader import plugins

plugins.plugins would then be a list of imported plugin modules.

With this I can use the __dict__ of each plugin module in plugins.plugins
to find which classes we want to use.

This works. But I wonder if there is a better way.

Any suggestions?

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

Re: Promoting Python

[Marko Rauhamaa]

Gregory Ewing :

> Another option for graphical stuff is pygame:

Thanks!

> http://pygame.org/news.html

Especially for this:

   No need to mess with installing it outside of your operating systems
   package manager.

However:

   Does Pygame work with Python 3?

   Yes. Pygame 1.9.2 supports Python 3.2 and up.

But Fedora comes with Pygame 1.9.1.


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

Re: mod_wsgi not compatible with Wamp 2.4 and python 3.4.3

[asimkon .]

I managed to connect Apache 2.2 with django framework successfully using
Python 2.7 and mod_wsgi.so (Apache module) thanks to the instructions from
https://pusonchen.wordpress.com/2013/06/03/build-django-website-with-apache-mod_wsgi-on-windows/.
The problem is that i see the Django project Web page using localhost or
127.0.0.1 in my browser.
 I want to change it to localhost/mysite as i have built other projects in
php with Apache (WampServer) using Cakephp and other php scripts. Is there
any way or i will have to sacrifice my entire Apache Web server for just
only Django project?
Afterwards i just download https://dev.mysql.com/downloads/connector/python/
 (MySQL driver) install it and play with syncdb to create tables in my
MySQL database. I create the db using phpmyadmin and import the info in my
settings.py django project folder.

Regards
Kostas Asimakopoulos

On Wed, Apr 6, 2016 at 8:13 AM, asimkon .  wrote:

> Thanks for your reply! Unfortunately i am working on Windows and i think
> gunicorn is not compatible with that OS, Any other known WSGI server for
> Windows otherwise i will have to work with python 2.7.
>
> Regards
>
>
> On Tue, Apr 5, 2016 at 11:20 PM, justin walters <
> walters.justi...@gmail.com> wrote:
>
>>
>> On Apr 5, 2016 12:51 PM, "asimkon ."  wrote:
>> >
>> > I am using Apache to develop Python Web applications via Django. As i am
>> > new to python web development, i am having problem to find the right
>> > version for mod_wsgi.so (compiled version for Apache 2.4.4 - WampServer
>> 2.4
>> > - and python 3.4.3 latest version from ActivePython on Windows x86) and
>> i
>> > get a 500 internal server error "The server encountered an internal
>> error
>> > or misconfiguration and was unable to complete your request".
>> >
>> > when i try to run the following script:
>> >
>> > def application(environment, start_response):
>> > status = '200 OK'
>> > response_headers = [('Content-type', 'text/html')]
>> > start_response(status, response_headers)
>> > page = """
>> > 
>> > 
>> > Hello world!
>> > This is being served using mod_wsgi
>> > 
>> > 
>> > """
>> > return page
>> >
>> > I just found the following link
>> >
>> http://grapevine.dyndns-ip.com/download/folder.asp?eid=33&folder=%2Fdownload%2Fapache%2Fmod_wsgi-windows-4.4.6%2Fmod_wsgi-windows-4.4.6%2Fapache24-win32-vc10%2Fmodules%2F
>> > but unfortunately i have got incompatibility problems with the compiled
>> > files mentioned. Any kind of help would be convenient to me.
>> >
>> > I am looking for the compiled (.so file) version, as it will save me
>> from a
>> > lot of trouble.
>> >
>> > Regards
>> > Kostas  Asimakopoulos
>> > --
>> > https://mail.python.org/mailman/listinfo/python-list
>>
>> Have you tried using apache as a proxy server to forward requests to a
>> dedicated wsgi server such as gunicorn instead of using mod_wsgi? I find
>> it's a lot easier to set up.
>>
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Promoting Python

[BartC]

On 05/04/2016 06:48, Gordon( Hotmail ) wrote:

I am struggling to understand the basic principles of Python having
spent many years as a pure Amateur tinkering with a variety of BASIC


Last time I looked, there seemed to be around 250 dialects of Basic, and 
with wildly differing implementations from pure interpreters to full 
compilers, from GWBASIC to .NET. (Is there even an official standard?)


With Python there are two dialects, and it's often already installed on 
a system (probably not on Windows though). There are a few different 
implementations too, but code I think is largely compatible across them.



The problem I am finding is most of the sites claiming to help understand 
Python devote
far too much space bragging about the wonders of Python instead of...


I fully agree. But you don't have to use classes, exceptions, 
decorators, generators, iterators, closures, comprehensions, meta 
classes, ... the list of meaningless buzzwords just goes on.


It'll cope with ordinary coding as well, although such programs seem to 
be frowned upon here; they are not 'Pythonic'.



Liberty Basic
for n = 32 to 255: print n;chr$(n) : next n

REM BBC Basic
FOR c = 1 TO 15 : COLOUR c
   PRINT "Color ";c
NEXT c


Python apparently has hundreds of libraries to do this stuff, which is a 
downside: there are as many libraries as Basics probably! And each seems 
to work a little differently from the other...


I haven't tried graphics in Python, but I would start by googling 
'python basic graphics' or some such phrase.


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

Re: Promoting Python

[Ned Batchelder]

On Wednesday, April 6, 2016 at 7:06:28 AM UTC-4, BartC wrote:
> On 05/04/2016 06:48, Gordon( Hotmail ) wrote:
> > The problem I am finding is most of the sites claiming to help understand 
> > Python devote
> > far too much space bragging about the wonders of Python instead of...
> 
> I fully agree. But you don't have to use classes, exceptions, 
> decorators, generators, iterators, closures, comprehensions, meta 
> classes, ... the list of meaningless buzzwords just goes on.

These are not meaningless buzzwords.  They are technical terms describing
the features of the language.  You don't see the need for these features,
so perhaps you haven't bothered to learn about them, but that does not
make them meaningless.

In order to make the claim that something is a meaningless buzzword, you'd
have to show the simpler better way to describe the same thing.  How would
you replace the word "class", or "decorator"?  And I don't mean, how would
you write code without using those features.  Python has classes, which are
a specific technical thing that can be clearly defined.

You might as well say that toolboxes have too many meaningless buzzwords like
hammer, screwdriver, wrench, chisel, etc.  It seems like a willful refusal to
learn about what the language offers.

But let's please not run down the rathole again of you telling us that things
like classes and exceptions are useless, and us trying to show you why they
are useful. We've been around and around those arguments, and there doesn't
seem to be anything more to say about it.

Just say that you prefer simpler languages, and leave it at that.

Perhaps what you mean is that there are too many "explanations" out there 
that are not good at explaining the concepts.  I'm sure that's true. But
there are also explanations out there that are good.  Find one that speaks
to you, and learn.

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

Re: Promoting Python

[Marko Rauhamaa]

BartC :

> But you don't have to use classes, exceptions, decorators, generators,
> iterators, closures, comprehensions, meta classes, ... the list of
> meaningless buzzwords just goes on.

Also, you don't have to use the letter "e" in your identifiers or the
number 2 anywhere in your programs.

Really, there's only one high-level construct you can't live without:
the "while" statement. Virtually every Python program has at least one
"while" statement, and in general, it is unavoidable.

Basic programs, on the other hand, don't need that meaningless buzzword,
but can live just fine with GOTO.

> It'll cope with ordinary coding as well, although such programs seem
> to be frowned upon here; they are not 'Pythonic'.

I wonder what is left of Python after your list of exclusions.


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

Re: ANN: intervalset Was: Set type for datetime intervals

[Random832]

On Tue, Apr 5, 2016, at 17:37, Nagy László Zsolt wrote:
> 
> >> It is blurred by design. There is an interpretation where an interval
> >> between [0..4] equals to a set of intervals ([0..2],[2..4]).
> > No, because 2.5 is in one and not the other. 
> My notation was: 0..4 for any number between 0 and 4. And 2..4 for any
> number between 2 and 4. So yes, 2.5 is in both of them.

My mistake, I'd confused this with a continuation of your earlier "just
move it back one for open intervals" stuff, and I thought you'd said
0..2, 3..4.

> > Uh, exactly. I don't understand why any of this makes it useful to have
> > these operations on interval objects.
> It doesn't make it a problem. :-)

It's conceptual blurriness. It makes it confusing what type is being
used at a given point in the code.

> >> By definition, a set is given with its elements, e.g. for any possible
> >> item, you can tell if it is part of the set or not. So if
> >> ([0..2],[2..4]) and ([0..4]) have exactly the same elements (by the
> >> given definition), then they are not just equal: they are the same set.
> >> The same reasoning is used in math when they say: there cannot be
> >> multiple empty sets. There exists a single empty set. It happens that we
> >> can only represent a finite number of elements in any set on a computer.
> >> I wanted to have a well defined single way to represent any given set.
> > What? *I* am the one who wants a well defined single way to represent a
> > given set. *You* are the one who wants to make [0..4] a set-like object
> > that is different from ([0..4]) and doesn't quite support the same
> > operations.
> Are you suggesting, that iterating over a set should yield sets?

Well, I was saying that iterating over the set should yield interval
objects... there's just no reason interval objects should be _at all_
set-like. There's no reason to use an interval object for any purpose
other than basic utility stuff like iterating.

> Just
> like iterating over a string yields single character strings? To make it
> useful, we must be able to access the begin and end value of such
> yielded sets.
> >
> >> I can also see your point. From another point a view, a set and a set of
> >> sets is not the same type.
> > I'm saying an interval is _not_ a set. It is merely part of the way of
> > describing the set. Just like the word "of" isn't a set just because
> > "the set of all even numbers" is a set.
> >
> > You could consider "the set of [dates|numbers|etc] in a single interval"
> > to be a type of set, certainly. But there's no reason to have such a set
> > _not_ fully support set operations even when those operations will not
> > return a set of a single interval.

> Okay, I hope I'm beginning to understand you. Analogy: the ord()
> function has a string parameter but it must be of length 1. Simiarily,
> when you iterate over a set, the yielded items will be sets with a
> "begin" and "end" attribute, wich can only be used when the set has a
> single element. Otherwise it should throw an error. The same way my
> Interval type throws an error when you try to unify it with a non
> overlapping interval. (???)

I think that's one reasonable way to do it.

> >> If you make a strinct distinction between intervals and interval sets,
> >> then the above equation does not make sense, because you cannot remove
> >> an element from a set that is not an "element" of it. The above equation
> >> makes sense only if the "intervalset" is a general representation of
> >> possible values, and the "interval" type is a special representation of
> >> (the same) possible values.
> > I don't understand why you want to let the user use the "interval" type
> > for purposes other than adding to an intervalset in the first place
> > Nothing you've posted has explained this.

> For iteration over the set and accessing begin/end values, of course.
> But then again: we could use simple tuples for that, right?

I wonder, what operations require iteration over the set? Formatting as
a string, sure, and there's a limited number of comparison operations
you can do. Maybe these should just all be built-in methods.

> As far as I understand, you recommend to throw out the Interval type,
> let the user use simple tuples in the IntervalSet constructor, and let
> the iterator iterate over tuples. Right?

Whether they use tuples or an interval type isn't important, I just
think either way the "begin/end pair type" should either not be
something that supports set operations, _or_ it should be a full set.
Having a type with a union method but that method can only be used in
certain specific circumstances makes it hard to follow what's going on
in code that uses it.

I just think that anything that supports a union/intersect/etc method
should support them fully, because otherwise there's the risk that
someone won't understand what's going on when they change a place where
it's used and it doesn't work anymore.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Promoting Python

[Mark Lawrence via Python-list]

On 06/04/2016 12:06, BartC wrote:

On 05/04/2016 06:48, Gordon( Hotmail ) wrote:

I am struggling to understand the basic principles of Python having
spent many years as a pure Amateur tinkering with a variety of BASIC


Last time I looked, there seemed to be around 250 dialects of Basic, and
with wildly differing implementations from pure interpreters to full
compilers, from GWBASIC to .NET. (Is there even an official standard?)

With Python there are two dialects, and it's often already installed on
a system (probably not on Windows though). There are a few different
implementations too, but code I think is largely compatible across them.


The problem I am finding is most of the sites claiming to help
understand Python devote
far too much space bragging about the wonders of Python instead of...


See if you can find one or more here 
http://noeticforce.com/best-free-tutorials-to-learn-python-pdfs-ebooks-online-interactive 
that suits.




I fully agree. But you don't have to use classes, exceptions,
decorators, generators, iterators, closures, comprehensions, meta
classes, ... the list of meaningless buzzwords just goes on.


You were five days late.



It'll cope with ordinary coding as well, although such programs seem to
be frowned upon here; they are not 'Pythonic'.



How can you (plural) write Python code when you don't know Python?

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

Checking function's parameters (type, value) or not ?

[ast]

Hello

I would like to know if it is advised or not to test
a function's parameters before running it, e.g
for functions stored on a public library ?

Example:

def to_base(nber, base=16, use_af=True, sep=''):

   assert isinstance(nber, int) and nber >= 0
   assert isinstance(base, int) and base >= 2
   assert isinstance(use_af, bool)
   assert isinstance(sep, str) and len(sep) == 1

  tbc

With these tests, you are sure that the function to_base is
well used. But it slows down the program.
Without, python interpreter may crash later in the function
or worse provide a meaningless result.

What library designers do ?
   


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

Re: Untrusted code execution

[Random832]

On Tue, Apr 5, 2016, at 21:43, Steven D'Aprano wrote:
> As Zooko says, Guido's "best argument is that reducing usability (in
> terms
> of forbidding language features, especially module import) and reducing
> the
> usefulness of extant library code" would make the resulting interpreter
> too
> feeble to be useful.

You don't have to forbid module import. The sandbox could control what
modules can be loaded, and what happens when you try to load a module.

import sys
module = type(sys)
fm = {}

def fimp(name, *etc):
# In a real implementation, this could also load whitelisted modules
try:
return fm[name]
except KeyError:
raise ImportError("Tried to load restricted module " + name)

fm['builtins'] = fb = module('builtins')
fb.int = int
fb.str = str
fb.len = len
fb.print = print
fb.__import__ = fimp
fm['sys'] = fsys = module('sys')
fsys.modules = fm

exec("""
import sys
print(sys.modules.keys())
""", {'__builtins__': fb})
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Promoting Python

[BartC]

On 06/04/2016 12:38, Ned Batchelder wrote:

On Wednesday, April 6, 2016 at 7:06:28 AM UTC-4, BartC wrote:

On 05/04/2016 06:48, Gordon( Hotmail ) wrote:

The problem I am finding is most of the sites claiming to help understand 
Python devote
far too much space bragging about the wonders of Python instead of...


I fully agree. But you don't have to use classes, exceptions,
decorators, generators, iterators, closures, comprehensions, meta
classes, ... the list of meaningless buzzwords just goes on.


These are not meaningless buzzwords.  They are technical terms describing
the features of the language.  You don't see the need for these features,
so perhaps you haven't bothered to learn about them, but that does not
make them meaningless.


OK, I'll withdraw the word 'meaningless'. Out of the eight things I 
listed, I would only need to go and look up the meaning of three of them.


Out of the rest, I've only used classes to implement records, and have 
been obliged to use exceptions because that was how some functions worked.



You might as well say that toolboxes have too many meaningless buzzwords like
hammer, screwdriver, wrench, chisel, etc.


No, those are the basics. Unless you want to suggest a lump of rock and 
a stick are the basic tools of DIY!



It seems like a willful refusal to
learn about what the language offers.


The context here is of someone moving over from Basic, which barely had 
proper function calls. Then you don't need that advanced stuff. That can 
be acquired gradually later on, if someone wants to. But get people 
hooked into the language first rather than frightening them off.



But let's please not run down the rathole again of you telling us that things
like classes and exceptions are useless, and us trying to show you why they
are useful. We've been around and around those arguments, and there doesn't
seem to be anything more to say about it.

Just say that you prefer simpler languages, and leave it at that.


I'm saying that people should be allowed to use Python in simple ways. 
The language seems to have nearly everything necessary to make that 
possible.


(Except 'goto', which imposes some limitations. 'if' and 'goto' allow 
any kind of control flow to be programmed.)


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

Re: Checking function's parameters (type, value) or not ?

[Chris Angelico]

On Wed, Apr 6, 2016 at 11:07 PM, ast  wrote:
> def to_base(nber, base=16, use_af=True, sep=''):
>
>assert isinstance(nber, int) and nber >= 0
>assert isinstance(base, int) and base >= 2
>assert isinstance(use_af, bool)
>assert isinstance(sep, str) and len(sep) == 1
>
>   tbc
>
> With these tests, you are sure that the function to_base is
> well used. But it slows down the program.
> Without, python interpreter may crash later in the function
> or worse provide a meaningless result.
>
> What library designers do ?

Most likely, it'll raise an exception at some point - or, even more
likely, function *correctly*. For instance, why should your sep have
to be a one-character string? Most likely, you'll simply append it
periodically, or use sep.join(parts) to assemble everything; a
multi-character string should be fine. I don't know what "use_af"
means, but again, you're probably going to simply use it in a boolean
context (most basically, that would mean "if use_af: do_stuff"), so
truthiness/falsiness will do.

So, what I'd do is: Drop the assertions. If you actually need the
checks, DO NOT use assert, but actually check and raise something else
(maybe ValueError). 'assert' should NEVER be used to check external
input.

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

Re: Checking function's parameters (type, value) or not ?

[Mark Lawrence via Python-list]

On 06/04/2016 14:07, ast wrote:

Hello

I would like to know if it is advised or not to test
a function's parameters before running it, e.g
for functions stored on a public library ?

Example:

def to_base(nber, base=16, use_af=True, sep=''):

assert isinstance(nber, int) and nber >= 0
assert isinstance(base, int) and base >= 2
assert isinstance(use_af, bool)
assert isinstance(sep, str) and len(sep) == 1

   tbc

With these tests, you are sure that the function to_base is
well used. But it slows down the program.
Without, python interpreter may crash later in the function
or worse provide a meaningless result.

What library designers do ?




Please see 
http://ftp.dev411.com/t/python/python-list/13bhcknhan/when-to-use-assert


--
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: Set type for datetime intervals

[Martin A. Brown]

>> Sorry to be late to the party--I applaud that you have already 
>> crafted something to attack your problem.  When you first posted, 
>> there was a library that was tickling my memory, but I could not 
>> remember its (simple) name.  It occurred to me this morning, after 
>> you posted your new library:
>>
>>   https://pypi.python.org/pypi/intervaltree
>>
>> This handles overlapping ranges nicely and provides some tools for 
>> managing them.  Before posting this, I checked that it works with 
>> datetime types, and, unsurprisingly, it does.
>
>Thank you! It is so much better than the one I have created. 
>Possibly I'll delete my own module from pypi. :-)

I'm glad to have been able to help, László.

And, even if you don't delete your new module, you have certainly 
stimulated quite a discussion on the mailing list.

Best regards and have a good day!

-Martin

-- 
Martin A. Brown
http://linux-ip.net/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Promoting Python

[Michael Selik]

On Wed, Apr 6, 2016, 12:51 PM Marko Rauhamaa  wrote:

> BartC :
> Really, there's only one high-level construct you can't live without:
> the "while" statement. Virtually every Python program has at least one
> "while" statement, and in general, it is unavoidable.
>
> Basic programs, on the other hand, don't need that meaningless buzzword,
> but can live just fine with GOTO.
>

You don't need WHILE or GOTO, you can just copy-paste code. You probably
need an IF at some point.

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

Re: Promoting Python

[BartC]

On 06/04/2016 12:46, Marko Rauhamaa wrote:

BartC :



It'll cope with ordinary coding as well, although such programs seem
to be frowned upon here; they are not 'Pythonic'.


I wonder what is left of Python after your list of exclusions.


There are plenty of features that /I/ consider must-have, which Python 
doesn't have. It has to emulate them, unsatisfactorily, with variables 
or classes or functions, or do without.


But you're right in that little is actually essential. Basic has shown that.

You need expressions, IF, GOTO, variables and assignments, and some 
means of doing I/O.


Pretty much every language has (had) those, although it's fashionable 
now to do away with GOTO, and some are getting rid of (rewritable) 
variables too! Others seem intent on doing away with control flow 
altogether, just having expressions. Apparently they think coding should 
become more elitist with only mathematicians allowed to participate.


I have the opposite view.


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

Re: Promoting Python

[Marko Rauhamaa]

BartC :

> But you're right in that little is actually essential. Basic has shown
> that.
>
> You need expressions, IF, GOTO, variables and assignments, and some
> means of doing I/O.
>
> Pretty much every language has (had) those, although it's fashionable
> now to do away with GOTO, and some are getting rid of (rewritable)
> variables too! Others seem intent on doing away with control flow
> altogether, just having expressions. Apparently they think coding
> should become more elitist with only mathematicians allowed to
> participate.

Oh, I'm also in the minimalist camp. Let me introduce you to the
simplest imaginable fully-featured programming language, iota:

   http://semarch.linguistics.fas.nyu.edu/barker/Iota/>

When I first ran into iota, my mind was blown. Also, follow the link to
zot:

   http://semarch.linguistics.fas.nyu.edu/barker/Iota/zot.html>


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

Re: Promoting Python

[Chris Angelico]

On Wed, Apr 6, 2016 at 11:54 PM, BartC  wrote:
> There are plenty of features that /I/ consider must-have, which Python
> doesn't have. It has to emulate them, unsatisfactorily, with variables or
> classes or functions, or do without.

Blub's Paradox epitomized.

> But you're right in that little is actually essential. Basic has shown that.

Actually, BASIC has a lot that isn't essential. A Turing-complete
language can be implemented with just three tokens, although that's
slightly cheating; they form eight opcodes (by being used in pairs).

http://www.dangermouse.net/esoteric/ook.html

> You need expressions, IF, GOTO, variables and assignments, and some means of
> doing I/O.

Depending on your meaning of "language", I would say that I/O does
*not* have to be an intrinsic part of it - it can be implemented far
more cleanly with built-in functions. Python 2 gave good syntactic
support to printing to the console, and messy syntactic support to
printing elsewhere, but Python 3 proved that it's not only
unnecessary, but counter-productive - it's better to push that to
regular functions.

Technically, expressions aren't required. However, a modern imperative
language will normally have expression support because it's so, well,
expressive.

Variable assignment, yes. And you need some form of flow control
(either 'if' or 'while').

> Pretty much every language has (had) those, although it's fashionable now to
> do away with GOTO, and some are getting rid of (rewritable) variables too!
> Others seem intent on doing away with control flow altogether, just having
> expressions. Apparently they think coding should become more elitist with
> only mathematicians allowed to participate.
>
> I have the opposite view.

Or maybe they think that coding should become more accessible to
people with a strong mathematical background. There was a time when
programming was a thing that only programmers did; that time is no
more. A brilliant physicist who sets up synchrotron experiments should
be able to learn enough Python to tinker with his simulation code; a
mathematician who devises cryptographic algorithms should be able to
transfer the algebraic notes directly into code. A language that makes
it easier to translate algebra into executable code is *easier*, not
harder, for those kinds of people. It might be harder *for you*, but
that just proves that, once again, you don't like what you don't
understand, and it scares you, and this feature is mysterious at
least. [1] Also, languages with no mutable state and everything
implemented as expressions lend themselves well to massive
parallelization; the compiler can look at the code and see easily that
these two subexpressions are entirely independent, and evaluate them
in parallel. That's pretty powerful.

Welcome to Blub's Paradox, once again.

ChrisA

[1] https://youtu.be/xCENkwPiuU0?t=1m59s
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Promoting Python

[Marko Rauhamaa]

Michael Selik :

> On Wed, Apr 6, 2016, 12:51 PM Marko Rauhamaa  wrote:
>
>> Really, there's only one high-level construct you can't live without:
>> the "while" statement. Virtually every Python program has at least
>> one "while" statement, and in general, it is unavoidable.
>>
>> Basic programs, on the other hand, don't need that meaningless
>> buzzword, but can live just fine with GOTO.
>
> You don't need WHILE or GOTO, you can just copy-paste code. You
> probably need an IF at some point.

Seriously, Python wouldn't be, couldn't be Turing-complete without
"while" (mainly because it doesn't support tail-recursion elimination).

Now, if Python had an unlimited range() iterator/iterable, you could use
a "for" statement to emulate "while".

As it stands, Python without "while" could only compute
primitive-recursive functions. However, you only need "while" a maximum
of one time in your whole program to perform an arbitrary computation.


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

Re: Promoting Python

[Chris Angelico]

On Thu, Apr 7, 2016 at 12:14 AM, Marko Rauhamaa  wrote:
> Seriously, Python wouldn't be, couldn't be Turing-complete without
> "while" (mainly because it doesn't support tail-recursion elimination).

Side point: Turing completeness actually assumes a mythical Turing
machine with infinite memory. So Python could be implemented without
tail call elimination, executed on a machine with infinite stack
space, and would only need removal of sys.*recursion_limit, and it'd
be valid. The *language* isn't broken because of that. Plus, anyone
could implement a Python interpreter with TCE. There might well be
some out there already. The only issue is that you'd mess with
tracebacks, so Guido doesn't want it.

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

Re: Checking function's parameters (type, value) or not ?

[ast]

"Mark Lawrence"  a écrit dans le message de 
news:mailman.131.1459949361.32530.python-l...@python.org...

On 06/04/2016 14:07, ast wrote:




Please see 
http://ftp.dev411.com/t/python/python-list/13bhcknhan/when-to-use-assert




Thanks for this paper

Running Python with the -O or -OO optimization flags
removes the assert. This has to be known. 


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

Re: Promoting Python

[Mark Lawrence via Python-list]

On 06/04/2016 14:54, BartC wrote:

On 06/04/2016 12:46, Marko Rauhamaa wrote:

BartC :



It'll cope with ordinary coding as well, although such programs seem
to be frowned upon here; they are not 'Pythonic'.


I wonder what is left of Python after your list of exclusions.


There are plenty of features that /I/ consider must-have, which Python
doesn't have. It has to emulate them, unsatisfactorily, with variables
or classes or functions, or do without.


Please list all these features.  Precisely what is unsatisfactory about 
the emulation?  Please state why you're still here if Python is such a 
poorly designed language that it doesn't fit your needs.  Or is it 
simply that your mindset cannot get to grips with something that is 
different to that you've previously used?




But you're right in that little is actually essential. Basic has shown
that.

You need expressions, IF, GOTO, variables and assignments, and some
means of doing I/O.


Are you suggesting that 21st century programming should return to the 
era of spaghetti code?




Pretty much every language has (had) those, although it's fashionable
now to do away with GOTO, and some are getting rid of (rewritable)
variables too!


It's 50 years to my knowledge since the first paper stating that GOTO 
isn't needed, hardly "fashionable now".  I get a very strong impression 
that you've never had to maintain appalingly written code.  The overuse 
of GOTO will certainly help in that area.  How does it go, something 
like "always consider that the person maintaining your code in six 
months time is a homicidal maniac armed with an axe"?


--
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: Promoting Python

[Ned Batchelder]

On Wednesday, April 6, 2016 at 10:25:13 AM UTC-4, Mark Lawrence wrote:
> On 06/04/2016 14:54, BartC wrote:
> > On 06/04/2016 12:46, Marko Rauhamaa wrote:
> >> BartC :
> >
> >>> It'll cope with ordinary coding as well, although such programs seem
> >>> to be frowned upon here; they are not 'Pythonic'.
> >>
> >> I wonder what is left of Python after your list of exclusions.
> >
> > There are plenty of features that /I/ consider must-have, which Python
> > doesn't have. It has to emulate them, unsatisfactorily, with variables
> > or classes or functions, or do without.
> 
> Please list all these features.  Precisely what is unsatisfactory about 
> the emulation?  Please state why you're still here if Python is such a 
> poorly designed language that it doesn't fit your needs.  Or is it 
> simply that your mindset cannot get to grips with something that is 
> different to that you've previously used?

No, please, let's not ask BartC to list these features.  We've already
well established Bart's point of view, let's not revisit this debate.
He prefers very different languages than Python.  We get it.  We don't
have to try to convince him to like Python, it's been tried, it doesn't
work.

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

Re: Promoting Python

[Larry Martell]

On Wed, Apr 6, 2016 at 10:08 AM, Marko Rauhamaa  wrote:
> BartC :
>
>> But you're right in that little is actually essential. Basic has shown
>> that.
>>
>> You need expressions, IF, GOTO, variables and assignments, and some
>> means of doing I/O.
>>
>> Pretty much every language has (had) those, although it's fashionable
>> now to do away with GOTO, and some are getting rid of (rewritable)
>> variables too! Others seem intent on doing away with control flow
>> altogether, just having expressions. Apparently they think coding
>> should become more elitist with only mathematicians allowed to
>> participate.
>
> Oh, I'm also in the minimalist camp. Let me introduce you to the
> simplest imaginable fully-featured programming language, iota:
>
>http://semarch.linguistics.fas.nyu.edu/barker/Iota/>
>
> When I first ran into iota, my mind was blown. Also, follow the link to
> zot:
>
>http://semarch.linguistics.fas.nyu.edu/barker/Iota/zot.html>

https://en.wikipedia.org/wiki/INTERCAL
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Promoting Python

[Mark Lawrence via Python-list]

On 06/04/2016 15:34, Ned Batchelder wrote:

On Wednesday, April 6, 2016 at 10:25:13 AM UTC-4, Mark Lawrence wrote:

On 06/04/2016 14:54, BartC wrote:

On 06/04/2016 12:46, Marko Rauhamaa wrote:

BartC :



It'll cope with ordinary coding as well, although such programs seem
to be frowned upon here; they are not 'Pythonic'.


I wonder what is left of Python after your list of exclusions.


There are plenty of features that /I/ consider must-have, which Python
doesn't have. It has to emulate them, unsatisfactorily, with variables
or classes or functions, or do without.


Please list all these features.  Precisely what is unsatisfactory about
the emulation?  Please state why you're still here if Python is such a
poorly designed language that it doesn't fit your needs.  Or is it
simply that your mindset cannot get to grips with something that is
different to that you've previously used?


No, please, let's not ask BartC to list these features.  We've already
well established Bart's point of view, let's not revisit this debate.
He prefers very different languages than Python.  We get it.  We don't
have to try to convince him to like Python, it's been tried, it doesn't
work.

--Ned.



So why isn't he politely told to shove off as he's not welcome on this 
Python list?


--
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: Checking function's parameters (type, value) or not ?

[Chris Angelico]

On Thu, Apr 7, 2016 at 12:18 AM, ast  wrote:
> "Mark Lawrence"  a écrit dans le message de
> news:mailman.131.1459949361.32530.python-l...@python.org...
>>
>> On 06/04/2016 14:07, ast wrote:
>
>
>>
>> Please see
>> http://ftp.dev411.com/t/python/python-list/13bhcknhan/when-to-use-assert
>>
>
>
> Thanks for this paper
>
> Running Python with the -O or -OO optimization flags
> removes the assert. This has to be known.

Exactly. So your two options are not "remove the assertions" and "keep
the assertions"; they are "remove the assertions" and "replace the
assertions with explicit exception raising". My recommendation is
still on simply removing them, but if you are to keep the checks,
they'll look something like this:

def to_base(nber, base=16, use_af=True, sep=''):
"""docstring goes here (don't forget that)"""
nber = int(nber)
if nber < 0: raise ValueError("Negative numbers not supported")
base = int(base)
if base < 2: raise ValueError("base must be at least 2")
use_af = bool(use_af)
sep = str(sep)


These are either conversions or assertions, depending on your point of
view. Actually, it would be better for these to have some kind of
"ensure that this is X" call; you could replace int(x) with
operator.index(x), but there's no equivalent for str - any object can
be converted to a string. You could perhaps do that one with
isinstance. (IMO bool is fine as it is.)

But I would just leave out this code altogether. Less code means less
chance of bugs creeping in; you might change the code elsewhere to
require, for instance, that base not exceed 36, and then you'd have to
come and change this code too. Without the checks, you'd only make
that change in one place.

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

Re: Untrusted code execution

[Ian Kelly]

On Tue, Apr 5, 2016 at 7:43 PM, Steven D'Aprano  wrote:
> I think Jon is on the right approach here for restricting evaluation of
> evaluation, which is a nicely constrained and small subset of Python. He's
> not allowing unrestricted arbitrary code execution: he has a very
> restricted (too restricted -- what the hell can you do with just int, str
> and len?) whitelist of functions that are allowed, and the significant
> restriction that dunder names aren't allowed.

I took that set of builtins to be just for the benefit of example.
Presumably a real-world implementer would need to go through a much
larger set and evaluate them individually for safety.

Most of the builtins apart from compile, eval, exec, exit, input,
open, print, quit and the *attr functions are likely safe to include.
type might also be a concern since it can be used to assemble
arbitrary classes. locals, globals and vars are questionable since it
might be possible to trick some non-sandboxed function into calling
them. memoryview is also likely best to exclude.

I've no doubt I've missed something either. A script that succeeds in
finding a way to raise SystemExit would be just as bad as one that
calls exit().
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: mod_wsgi not compatible with Wamp 2.4 and python 3.4.3

[justin walters]

On Wed, Apr 6, 2016 at 3:57 AM, asimkon .  wrote:

> I managed to connect Apache 2.2 with django framework successfully using
> Python 2.7 and mod_wsgi.so (Apache module) thanks to the instructions from
> https://pusonchen.wordpress.com/2013/06/03/build-django-website-with-apache-mod_wsgi-on-windows/.
> The problem is that i see the Django project Web page using localhost or
> 127.0.0.1 in my browser.
>  I want to change it to localhost/mysite as i have built other projects in
> php with Apache (WampServer) using Cakephp and other php scripts. Is there
> any way or i will have to sacrifice my entire Apache Web server for just
> only Django project?
> Afterwards i just download
> https://dev.mysql.com/downloads/connector/python/  (MySQL driver) install
> it and play with syncdb to create tables in my MySQL database. I create the
> db using phpmyadmin and import the info in my settings.py django project
> folder.
>
> Regards
> Kostas Asimakopoulos
>

So, you are running this on your local machine then?

I did some quick googling for you because I wasn't sure if Apache could run
mod_php and mod_wsgi together. Apparently it can. See this google search:
https://www.google.com/search?client=ubuntu&channel=fs&q=can+apache+run+mod_php+and+mod_wsgi+at+the+same+time%3F&ie=utf-8&oe=utf-8

The basic premise is that you set one port to your php application, and
another port to your Python application.

So, if you visit, say 127.0.0.1:80, you will arrive at your php
application. If you instead visit 127.0.0.1:8000, you will arrive at your
Python application.

Unfortunately, I do not believe there is any way to have both applications
listen on the same port. You could, however, create an alias so that when
you visit 'htttp://localhost/mysite' it actually points to 127.0.0.1:8000
which is the port for your Python application.

>Afterwards i just download
https://dev.mysql.com/downloads/connector/python/  (MySQL driver) install
it and play with syncdb to create tables in my MySQL database. I create the
db using phpmyadmin and import the info in my settings.py django project
folder.

Can you explain this further? Are you not using the Django ORM?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Untrusted code execution

[Chris Angelico]

On Thu, Apr 7, 2016 at 1:41 AM, Ian Kelly  wrote:
> type might also be a concern since it can be used to assemble
> arbitrary classes.

Sadly, this means denying the ability to interrogate an object for its
type. And no, this won't do:

def safe_type(obj): return type(obj)

because all you need is safe_type(safe_type(1)) and you've just
regained access to the original 'type' type.

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

Re: mod_wsgi not compatible with Wamp 2.4 and python 3.4.3

[Chris Angelico]

On Thu, Apr 7, 2016 at 1:47 AM, justin walters
 wrote:
> I did some quick googling for you because I wasn't sure if Apache could run
> mod_php and mod_wsgi together. Apparently it can. See this google search:
> https://www.google.com/search?client=ubuntu&channel=fs&q=can+apache+run+mod_php+and+mod_wsgi+at+the+same+time%3F&ie=utf-8&oe=utf-8
>
> The basic premise is that you set one port to your php application, and
> another port to your Python application.

Don't even need that - I have Apache with both modules active. It's fine.

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

Re: numpy arrays

[Heli]

Thanks for your replies. I have a question in regard with my previous question. 
I have a file that contains x,y,z and a value for that coordinate on each line. 
Here I am giving an example of the file using a numpy array called f. 

f=np.array([[1,1,1,1],
[1,1,2,2], 
[1,1,3,3],
[1,2,1,4],
[1,2,2,5],
[1,2,3,6],
[1,3,1,7],
[1,3,2,8],
[1,3,3,9],
[2,1,1,10],
[2,1,2,11],
[2,1,3,12],
[2,2,1,13],
[2,2,2,14],
[2,2,3,15],
[2,3,1,16],
[2,3,2,17],
[2,3,3,18],
[3,1,1,19],
[3,1,2,20],
[3,1,3,21],
[3,2,1,22],
[3,2,2,23],
[3,2,3,24],
[3,3,1,25],
[3,3,2,26],
[3,3,3,27],
])

then after tranposing f, I get the x,y and z coordinates:
f_tranpose=f.T
x=np.sort(np.unique(f_tranpose[0]))
y=np.sort(np.unique(f_tranpose[1]))
z=np.sort(np.unique(f_tranpose[2]))

Then I will create a 3D array to put the values inside. The only way I see to 
do this is the following:
arr_size=x.size
val2=np.empty([3, 3,3])

for sub_arr in f:
idx = (np.abs(x-sub_arr[0])).argmin()
idy = (np.abs(y-sub_arr[1])).argmin()
idz = (np.abs(z-sub_arr[2])).argmin()
val2[idx,idy,idz]=sub_arr[3]

I know that in the example above I could simple reshape f_tranpose[3] to a 
three by three by three array, but in my real example the coordinates are not 
in order and the only way I see to do this is by looping over the whole file 
which takes a lot of time. 

I would appreciate any workarounds to make this quicker. 

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

Re: Checking function's parameters (type, value) or not ?

[Steven D'Aprano]

On Wed, 6 Apr 2016 11:07 pm, ast wrote:

> Hello
> 
> I would like to know if it is advised or not to test
> a function's parameters before running it, e.g
> for functions stored on a public library ?

It depends. Sometimes it is best to do an explicit type check, sometimes it
is better to call a built-in function that will do the type checking for
you, and sometimes it is best to use "duck typing":

https://en.wikipedia.org/wiki/Duck_typing


> Example:
> 
> def to_base(nber, base=16, use_af=True, sep=''):
> 
> assert isinstance(nber, int) and nber >= 0
> assert isinstance(base, int) and base >= 2
> assert isinstance(use_af, bool)
> assert isinstance(sep, str) and len(sep) == 1

Do not use assert for checking arguments, that is completely wrong and
dangerous, as the user can disable your error checking.

Please read this article about assert:

https://import-that.dreamwidth.org/676.html


> With these tests, you are sure that the function to_base is
> well used. But it slows down the program.
> Without, python interpreter may crash later in the function
> or worse provide a meaningless result.
> 
> What library designers do ?


Why don't you read the source code to the Python standard library? You will
learn what library designers do.

If you have Python installed, you will have the source code. Or you can read
it here:

https://hg.python.org/cpython/file/3.5/Lib/


I'm especially fond of this one, since I wrote it:

https://hg.python.org/cpython/file/3.5/Lib/statistics.py

You will notice that there are very few explicit type-checks, but if you
look at the unit-tests, there are tests to ensure that the functions raise
the correct TypeError as needed:

https://hg.python.org/cpython/file/3.5/Lib/test/test_statistics.py

(Search for test_bad_arg_types and test_strings_fail, for example.)



-- 
Steven

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

Re: Untrusted code execution

[Ian Kelly]

On Wed, Apr 6, 2016 at 10:04 AM, Chris Angelico  wrote:
> On Thu, Apr 7, 2016 at 1:41 AM, Ian Kelly  wrote:
>> type might also be a concern since it can be used to assemble
>> arbitrary classes.
>
> Sadly, this means denying the ability to interrogate an object for its
> type. And no, this won't do:
>
> def safe_type(obj): return type(obj)
>
> because all you need is safe_type(safe_type(1)) and you've just
> regained access to the original 'type' type.

How about:

def safe_type(obj):
if isinstance(obj, type):
raise ValueError("'safe_type()' not allowed on type subclasses")
return type(obj)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Promoting Python

[BartC]

On 06/04/2016 15:20, Mark Lawrence wrote:

On 06/04/2016 14:54, BartC wrote:



Please state why you're still here if Python is such a
poorly designed language that it doesn't fit your needs.


I was replying to the OP who was being put off the language. The vast 
majority have to choose an off-the-shelf language, and in that 
situation, Python is probably one of the best choices for someone 
progressing from Basic.


It might have been difficult to tell, but I was /for/ Python in that 
post, not against it. But I'm not afraid to mention cons as well as pros.


> Or is it
> simply that your mindset cannot get to grips with something that is
> different to that you've previously used?

(I've actually implemented versions of 3 or 4 of the 8 things I listed. 
Coming up with and implementing this stuff is fun (and I can see how 
languages and libraries can end up brimming full of every possible 
feature you can think of). But ending up with a new must-have feature 
that is used all the time is harder.)



Pretty much every language has (had) those, although it's fashionable
now to do away with GOTO, and some are getting rid of (rewritable)
variables too!


It's 50 years to my knowledge since the first paper stating that GOTO
isn't needed, hardly "fashionable now".


I mean for it it to disappear completely from languages.


I get a very strong impression
that you've never had to maintain appalingly written code.  The overuse
of GOTO will certainly help in that area.


(I've not defending its use, but there are good reasons for retaining it.

Suppose you had the job of translating language X to Y. X contains 
control structures that don't exist in Y. Or it maybe it just uses GOTO. 
Would the task be easier if Y had GOTO, or without?)


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

Re: Checking function's parameters (type, value) or not ?

[Michael Selik]

> On Apr 6, 2016, at 2:07 PM, ast  wrote:
> 
> I would like to know if it is advised or not to test
> a function's parameters before running it, e.g
> for functions stored on a public library ?
> 
> def to_base(nber, base=16, use_af=True, sep=''):
>   assert isinstance(nber, int) and nber >= 0

> Without, python interpreter may crash later in the function
> or worse provide a meaningless result.

Crashing later isn the function is a *good* thing in many cases, because it 
provides a more specific error. Not only what input was bad, but *why* it was 
bad. [0]

Meaningless results might be meaningless to you, but your users may have 
thought of new ways to use your code. Assume they've thought of things you 
haven't.

You don't want to lock people into only your prescribed usage. Remember, they 
might have monkey-patched your dependency to do something really cool. Don't 
ruin their day with "discipline".

However, you might want to protect them from a subtle infinite loop or other 
traps that are tough to recover from. If it's an obvious infinity, well, that's 
their own fault. For example, ``range`` stops you from a zero step-size, but 
won't stop you from ``range(int(1e200))``.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Promoting Python

[Steven D'Aprano]

On Wed, 6 Apr 2016 09:06 pm, BartC wrote:

> On 05/04/2016 06:48, Gordon( Hotmail ) wrote:

>> The problem I am finding is most of the sites claiming to help understand
>> Python devote far too much space bragging about the wonders of Python
>> instead of...

I'd like to see these sites. I suspect that "bragging" actually
means "taking for granted powerful features that are unthinkable in BASIC".

If it makes you feel better, Bart, your opinion about Python is somewhat
similar to my opinion on the more esoteric areas of Lisp and Haskell
programming. That's the Blub paradox in action again. But the difference is
that I'm completely aware that my ignorance of Lisp and Haskell is *my*
ignorance, not their wilful obscuration.

Well, except for Monads. I'm convinced that Monads are a long-running April
Fool's gag that has gotten completely out of hand...

*wink*


> I fully agree. But you don't have to use classes, exceptions,
> decorators, generators, iterators, closures, comprehensions, meta
> classes, ... the list of meaningless buzzwords just goes on.

"Meaningless buzzwords"? Every one of those terms have meaning. They are
technical jargon, not buzzwords.

Honestly, hearing you say that makes you sound just tired and lost, an old
dog who has given up on the possibility of learning any new tricks. That's
sad, because none of those technologies above (with the possible exception
of metaclasses, which are kinda mind-bending the first eighty or ninety
times you read about them) are that complicated or difficult to use.
They're just *different*.

I feel for you -- when I hear folks talking about asynchronous programming,
or databases, I feel just as lost. But I'm not so arrogant to imagine that
those people are just flapping their mouths making random noises that have
no meaning, or that they're just sprouting buzzwords.

I don't get async programming because I've never taken the time to learn it.
That doesn't make it a "meaningless buzzword", it makes it something I
personally know little or nothing about. I should do something about it,
and the fact that I don't is *my loss*.

Unless you think that you have learned everything there is to know about
programming, you should know better than to describe modern programming
features as "meaningless buzzwords".


> It'll cope with ordinary coding as well, although such programs seem to
> be frowned upon here; they are not 'Pythonic'.

What's "ordinary coding" mean?

Most people, I imagine, know what a Zippo lighter is, even if they've never
owned one or smoked:

http://www.zippo.com/lighters.aspx?c=1230

You can light a fire with one by flicking them open and letting the lighter
do most of the work. That's "Pythonic".

But there's another way: you could, if you wish, clutch the lighter in one
hand, and a piece of flint in another, and strike the flint against the
lighter hard enough for sparks to come off. Direct the sparks into a small
pile of extremely fine wood shavings, or punk wood, and blow ever-so-gently
until the tinder catches alight. It won't be as easy or efficient as using
a proper flint and steel, but it will (probably) work.

https://en.wikipedia.org/wiki/Fire_striker

Is that what you mean by "ordinary coding"?

There's nothing wrong with lighting a fire with steel and flint, if you're
in the wilderness, or after civilization has collapsed, and you can no
longer get hold of lighter fluid or friction matches. It was a technology
that lasted for literally thousands of years, it works, and isn't
inherently *bad*. And for those who prefer to use human effort rather than
products of advanced technology (like butane lighter fluid), a steel and
flint is the more attractive option.

But, frankly, using a Zippo lighter as the steel *is* inherently bad, since
its the wrong sort of steel and will be very inefficient. That's not what
Zippo lighters are designed to be. In an emergency, with no other steel
around, using a Zippo lighter as a fire-striker may be justified by
necessity, but it should never be PREFERRED over using it the way it was
designed to be used.

Of course programming is rather more complex that lighting fires, and
there's no hard and fast line between using Python in a Pythonic fashion
and misusing it in a non-Pythonic fashion. This isn't unique to Python: in
*every* language, there is "good coding style" and "poor coding style",
both of which depends on the strengths and weaknesses of the specific
language being used.



>> Liberty Basic
>> for n = 32 to 255: print n;chr$(n) : next n
>>
>> REM BBC Basic
>> FOR c = 1 TO 15 : COLOUR c
>>PRINT "Color ";c
>> NEXT c
> 
> Python apparently has hundreds of libraries to do this stuff, which is a
> downside: there are as many libraries as Basics probably! And each seems
> to work a little differently from the other...
> 
> I haven't tried graphics in Python, but I would start by googling
> 'python basic graphics' or some such phrase.

Unfortunately, technology has moved on, and there's nothing I'v

Re: Checking function's parameters (type, value) or not ?

[ast]

"Chris Angelico"  a écrit dans le message de 
news:mailman.13.1459955565.1197.python-l...@python.org...

On Thu, Apr 7, 2016 at 12:18 AM, ast  wrote:

"Mark Lawrence"  a écrit dans le message de
news:mailman.131.1459949361.32530.python-l...@python.org...


On 06/04/2016 14:07, ast wrote:






Running Python with the -O or -OO optimization flags
removes the assert. This has to be known.


Exactly. So your two options are not "remove the assertions" and "keep
the assertions"; they are "remove the assertions" and "replace the
assertions with explicit exception raising". My recommendation is
still on simply removing them, but if you are to keep the checks,
they'll look something like this:

def to_base(nber, base=16, use_af=True, sep=''):
   """docstring goes here (don't forget that)"""
   nber = int(nber)
   if nber < 0: raise ValueError("Negative numbers not supported")
   base = int(base)
   if base < 2: raise ValueError("base must be at least 2")
   use_af = bool(use_af)
   sep = str(sep)


These are either conversions or assertions, depending on your point of
view. Actually, it would be better for these to have some kind of
"ensure that this is X" call; you could replace int(x) with
operator.index(x), but there's no equivalent for str - any object can
be converted to a string. You could perhaps do that one with
isinstance. (IMO bool is fine as it is.)

But I would just leave out this code altogether. Less code means less
chance of bugs creeping in; you might change the code elsewhere to
require, for instance, that base not exceed 36, and then you'd have to
come and change this code too. Without the checks, you'd only make
that change in one place.

ChrisA


thanks for these informations 


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

Re: Promoting Python

[Chris Angelico]

On Thu, Apr 7, 2016 at 3:04 AM, BartC  wrote:
>
>> I get a very strong impression
>> that you've never had to maintain appalingly written code.  The overuse
>> of GOTO will certainly help in that area.
>
>
> (I've not defending its use, but there are good reasons for retaining it.
>
> Suppose you had the job of translating language X to Y. X contains control
> structures that don't exist in Y. Or it maybe it just uses GOTO. Would the
> task be easier if Y had GOTO, or without?)

Before you say whether the task's easier, you have to first define the
task. Do you have code in a language for which there are no
compilers/interpreters that run on modern hardware, and your sole goal
is to get it runnable again? Are you trying to write idiomatic and
maintainable code in the target language? Or are you just trying to do
this for the sake of doing it, and aren't bothered by the fact that
your code won't be at all sensible in the target language?

Whenever you reimplement code from one language into another, you have
to first take a step back and figure out what the code is attempting
to do. Otherwise, all you're doing is reimplementing, line by line and
operation by operation, in a different syntax. And sure, having GOTO
would make that easier. But I've ported a lot of code from language to
language, and the *ONLY* time I've ever reached for GOTO was
reimplementing this idiom in C:

for foo in foo_collection:
if is_what_we_want(foo):
use_me = foo
break
else:
use_me = Foo()
foo_collection.append(use_me)
use(use_me)

In C, 'for' loops don't have 'else' clauses, so I ended up replacing
the 'break' with a goto. Would it have been harder if C hadn't had
'goto'? Not hugely - I'd just have needed some kind of sentinel and an
'if' after the loop. And that was one tiny part of a
several-thousand-line C program, so it didn't make much difference.

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

functools puzzle

[George Trojan - NOAA Federal]

Here is my test program:

''' generic test '''

import functools
import inspect

def f():
'''I am f'''
pass

g = functools.partial(f)
g.__doc__ = '''I am g'''
g.__name__ = 'g'

def partial(func, *args, **keywords):
def newfunc(*fargs, **fkeywords):
newkeywords = keywords.copy()
newkeywords.update(fkeywords)
return func(*(args + fargs), **newkeywords)
newfunc.func = func
newfunc.args = args
newfunc.keywords = keywords
return newfunc

h = partial(f)
functools.update_wrapper(h, f)
h.__doc__ = '''I am h'''
h.__name__ = 'h'

print(type(g), g.__name__, inspect.getdoc(g))
print(type(h), h.__name__, inspect.getdoc(h))
help(g)
help(h)

The output is what I expect:

(devenv-3.5.1) dilbert@gtrojan> python x.py
 g I am g
 h I am h

However the help screens for h and g are different. help(h) is again what I
expect:

Help on function h in module __main__:

h()
I am h

But help(g) is (almost) identical to help(functools.partial), the doc
string disappears:

Help on partial object:

g = class partial(builtins.object)
 |  partial(func, *args, **keywords) - new function with partial application
 |  of the given arguments and keywords.
...

The module functools has partial() defined as above, then overrides the
definition by importing partial from _functools. That would explain the
above behaviour. My question is why?

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

Re: Promoting Python

[Ned Batchelder]

On Wednesday, April 6, 2016 at 10:40:36 AM UTC-4, Mark Lawrence wrote:
> On 06/04/2016 15:34, Ned Batchelder wrote:
> > No, please, let's not ask BartC to list these features.  We've already
> > well established Bart's point of view, let's not revisit this debate.
> > He prefers very different languages than Python.  We get it.  We don't
> > have to try to convince him to like Python, it's been tried, it doesn't
> > work.
> >
> > --Ned.
> >
> 
> So why isn't he politely told to shove off as he's not welcome on this 
> Python list?

Because there's no purity test for membership here.  You can dislike Python,
and still participate. Bart is not unwelcome.

I did take issue with his mischaracterization of Python's terminology, and
it worked out fine.

It took us a while to understand where Bart was coming from, but now we
understand, and we don't have to go around in circles.

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

You can be welcoming and understanding.

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

Re: Promoting Python

[Chris Angelico]

On Thu, Apr 7, 2016 at 3:40 AM, Steven D'Aprano  wrote:
>> I fully agree. But you don't have to use classes, exceptions,
>> decorators, generators, iterators, closures, comprehensions, meta
>> classes, ... the list of meaningless buzzwords just goes on.
>
> Honestly, hearing you say that makes you sound just tired and lost, an old
> dog who has given up on the possibility of learning any new tricks. That's
> sad, because none of those technologies above (with the possible exception
> of metaclasses, which are kinda mind-bending the first eighty or ninety
> times you read about them) are that complicated or difficult to use.
> They're just *different*.
>
> I feel for you -- when I hear folks talking about asynchronous programming,
> or databases, I feel just as lost.

Interestingly, most of the technologies cited as "meaningless
buzzwords" are derivatives of one concept: code reuse. What are
classes? Structured code reuse. What are decorators? A form of
metaprogramming; in its mechanics, it's general and flexible, but in
usage, it's most often a means of refactoring something so you don't
have to write the same code more than once. Generators are a
specialized form of iterator class - you can always rewrite a
generator function such that all locals become instance attributes,
and execution state is maintained in more attributes, and then put all
the work into __next__. Closures let you generate functions on the
fly, saving you the hassle of creating them all as classes.
Comprehensions let you avoid the boilerplate of iteration and
appending. Metaclasses let you push all the coolness of class
instantiation up a level, and mess with the class's class. The only
one that *isn't* largely about code reuse is exceptions, and even
then, you can argue that structured exception handling is a means of
eliminating the boilerplate of return value checking. (Personally, I
see it more as a simplicity and correctness thing, because return
value checking is NEVER done thoroughly enough.)

Now, asynchronous programming and databases, they're completely
different beasts. But it's fascinating how many cool technologies we
have just for that one purpose of avoiding code duplication.

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

Re: functools puzzle

[Peter Otten]

George Trojan - NOAA Federal wrote:

> Here is my test program:
> 
> ''' generic test '''
> 
> import functools
> import inspect
> 
> def f():
> '''I am f'''
> pass
> 
> g = functools.partial(f)
> g.__doc__ = '''I am g'''
> g.__name__ = 'g'
> 
> def partial(func, *args, **keywords):
> def newfunc(*fargs, **fkeywords):
> newkeywords = keywords.copy()
> newkeywords.update(fkeywords)
> return func(*(args + fargs), **newkeywords)
> newfunc.func = func
> newfunc.args = args
> newfunc.keywords = keywords
> return newfunc
> 
> h = partial(f)
> functools.update_wrapper(h, f)
> h.__doc__ = '''I am h'''
> h.__name__ = 'h'
> 
> print(type(g), g.__name__, inspect.getdoc(g))
> print(type(h), h.__name__, inspect.getdoc(h))
> help(g)
> help(h)
> 
> The output is what I expect:
> 
> (devenv-3.5.1) dilbert@gtrojan> python x.py
>  g I am g
>  h I am h
> 
> However the help screens for h and g are different. help(h) is again what
> I expect:
> 
> Help on function h in module __main__:
> 
> h()
> I am h
> 
> But help(g) is (almost) identical to help(functools.partial), the doc
> string disappears:
> 
> Help on partial object:
> 
> g = class partial(builtins.object)
>  |  partial(func, *args, **keywords) - new function with partial
>  |  application of the given arguments and keywords.
> ...
> 
> The module functools has partial() defined as above, then overrides the
> definition by importing partial from _functools. That would explain the
> above behaviour. My question is why?

This is not specific to functools.partial.

partial(some_func, ...)

creates an instance of the partial class. Unfortunately the instance.__doc__ 
is generally ignored in favour of class.__doc__:

>>> class Foo:
... "CLASS"
... 
>>> foo = Foo()
>>> foo.__doc__ = "INSTANCE"
>>> help(foo)
Help on Foo in module __main__ object:

class Foo(builtins.object)
 |  CLASS
[...]

Being looked up in the class is standard behaviour for __dunder__ 
attributes:

>>> class A:
...def __len__(self): return 42
... 
>>> a = A()
>>> a.__len__ = lambda: 123
>>> a.__len__()
123
>>> len(a)
42

Most of the time it saves at least a dict lookup, but sometimes it bites 
you.

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

Re: Promoting Python

[Marko Rauhamaa]

Chris Angelico :

> Plus, anyone could implement a Python interpreter with TCE.

Tricky in practice because None is the default return value.

If the programmer were careful to return the value of the tail call, it
can be eliminated.


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

Re: Checking function's parameters (type, value) or not ?

[Chris Angelico]

On Thu, Apr 7, 2016 at 3:36 AM, Michael Selik  wrote:
> However, you might want to protect them from a subtle infinite loop or other 
> traps that are tough to recover from. If it's an obvious infinity, well, 
> that's their own fault. For example, ``range`` stops you from a zero 
> step-size, but won't stop you from ``range(int(1e200))``.
>

>>> range(int(1e200))
range(0, 
6973312221251036165947450327545502362648241750950346848435554075534196338404706251868027512415973882408182135734368278484639385041047239877871023591066789981811181813306167128854888448)

Looks fine to me :)

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

Re: Untrusted code execution

[Random832]

On Wed, Apr 6, 2016, at 12:04, Chris Angelico wrote:
> On Thu, Apr 7, 2016 at 1:41 AM, Ian Kelly  wrote:
> > type might also be a concern since it can be used to assemble
> > arbitrary classes.
> 
> Sadly, this means denying the ability to interrogate an object for its
> type. And no, this won't do:
> 
> def safe_type(obj): return type(obj)
> 
> because all you need is safe_type(safe_type(1)) and you've just
> regained access to the original 'type' type.

tpdict = {}
class typeproxy:
def __new__(cls, t):
if t in tpdict: return tpdict[t] # so is-comparison works
tpdict[t] = self = object.__new__(cls)
self._type = t
return self
def __instancecheck__(self, obj):
return isinstance(obj, self._type)
def __subclasscheck__(self, cls2):
if isinstance(cls2, typeproxy): cls2 = cls2._type
return issubclass(self._type, cls2)
def __call__(self, obj):
if isinstance(obj, type):
return typeproxy(type(obj))
else:
return type(obj)

safe_type = typeproxy(type)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Promoting Python

[Random832]

On Wed, Apr 6, 2016, at 14:23, Marko Rauhamaa wrote:
> Chris Angelico :
> 
> > Plus, anyone could implement a Python interpreter with TCE.
> 
> Tricky in practice because None is the default return value.
> 
> If the programmer were careful to return the value of the tail call, it
> can be eliminated.

Well, the interpreter can know that the calling function doesn't return
anything (returns None). Maybe it could pass a secret argument to the
called function telling it not to return its value and to return None
instead.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: functools puzzle

[Michael Selik]

> On Apr 6, 2016, at 6:57 PM, George Trojan - NOAA Federal 
>  wrote:
> 
> The module functools has partial() defined as above, then overrides the
> definition by importing partial from _functools. That would explain the
> above behaviour. My question is why?

A couple speculations why an author might retain a vestigial Python 
implementation after re-implementing in C: to provide a backup in case the C 
fails to compile or to simply provide an easier-to-read example of what the C 
is doing.

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

Re: WP-A: A New URL Shortener

[Thomas 'PointedEars' Lahn]

Chris Angelico wrote:

> In other words, you are assuming that the string escaping *in the
> module* is buggy. Well, duh. This is exactly what I said about not
> having stupid bugs. The developer of a MySQL binding library should
> know the *entire* rules for escaping, and, duh, that's going to
> include escaping the backslash. So the escaped query would be
> something like:
> 
>   insert into some_table (some_column) values ("\\"");
>   DROP TABLE some_table;
>   --")
> 
> which would be interpreted correctly by MySQL.

There is no way a version of a module can safely use an escaping mechanism 
that handles all possible *future* cases.  Further, there are escaping costs 
on the client to be considered for *every* query.

So my recommendation, based on best current practice (OWASP), stands: Use 
prepared statements or stored procedures and let the database do the job.  
*Better be safe than sorry.*  See xkcd.

Bonuses with prepared statements: Not only can the client skip the escaping, 
but queries are faster if you have to do the same query just with different 
parameters.  And you can do things with prepared statements that you cannot 
do in another way (for example, parameterized LIMIT [1]).

Bonus with stored procedures: You can do more complex tasks with less 
overhead.

Off-topic --> EOD.

[1] 

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Promoting Python

[Ian Kelly]

On Wed, Apr 6, 2016 at 8:14 AM, Marko Rauhamaa  wrote:
> Now, if Python had an unlimited range() iterator/iterable, you could use
> a "for" statement to emulate "while".

You can already do this.

>>> class While:
... def __init__(self, predicate):
... self._predicate = predicate
... self._exited = False
... def __iter__(self):
... return self
... def __next__(self):
... if self._exited or not self._predicate():
... self._exited = True
... raise StopIteration
...
>>> i = 0
>>> for _ in While(lambda: i < 10):
... print(i)
... i += 1
...
0
1
2
3
4
5
6
7
8
9


> As it stands, Python without "while" could only compute
> primitive-recursive functions. However, you only need "while" a maximum
> of one time in your whole program to perform an arbitrary computation.

So this is wrong.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: WP-A: A New URL Shortener

[Chris Angelico]

On Thu, Apr 7, 2016 at 4:42 AM, Thomas 'PointedEars' Lahn
 wrote:
> Chris Angelico wrote:
>
>> In other words, you are assuming that the string escaping *in the
>> module* is buggy. Well, duh. This is exactly what I said about not
>> having stupid bugs. The developer of a MySQL binding library should
>> know the *entire* rules for escaping, and, duh, that's going to
>> include escaping the backslash. So the escaped query would be
>> something like:
>>
>>   insert into some_table (some_column) values ("\\"");
>>   DROP TABLE some_table;
>>   --")
>>
>> which would be interpreted correctly by MySQL.
>
> There is no way a version of a module can safely use an escaping mechanism
> that handles all possible *future* cases.  Further, there are escaping costs
> on the client to be considered for *every* query.

The cost of escaping is to be considered against the costs of other
options. It's not a question of correctness.

I don't know what future cases you're talking about. If a future
version of the MySQL server alters the parsing rules of strings, it's
not just this escaping that'll be broken - it's *every string
literal*. That would be a major backward compatibility break, and
people would cope appropriately. You're still somehow assuming that
escaping implies that your library is fundamentally buggy.

> So my recommendation, based on best current practice (OWASP), stands: Use
> prepared statements or stored procedures and let the database do the job.
> *Better be safe than sorry.*  See xkcd.

Or use parameterized queries and let the database protocol do the job.
Of course, that DOES require that you not use MySQL. Like you say,
better safe than sorry.

> Bonuses with prepared statements: Not only can the client skip the escaping,
> but queries are faster if you have to do the same query just with different
> parameters.  And you can do things with prepared statements that you cannot
> do in another way (for example, parameterized LIMIT [1]).

How does a generic client know which statements to save?

Also, what is the issue with parameterized LIMIT? Your footnote is of
no value to large numbers of python-list readers.

> Bonus with stored procedures: You can do more complex tasks with less
> overhead.

And one of the bonuses of floating point numbers over integers is that
you can store fractional values. They're solving different problems.

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

Re: Promoting Python

[Marko Rauhamaa]

Random832 :

> On Wed, Apr 6, 2016, at 14:23, Marko Rauhamaa wrote:
>> Chris Angelico :
>> > Plus, anyone could implement a Python interpreter with TCE.
>> 
>> Tricky in practice because None is the default return value.
>> 
>> If the programmer were careful to return the value of the tail call,
>> it can be eliminated.
>
> Well, the interpreter can know that the calling function doesn't
> return anything (returns None). Maybe it could pass a secret argument
> to the called function telling it not to return its value and to
> return None instead.

Oh, I forgot about the secret whisper-with-a-wink channel...


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

Re: Promoting Python

[Chris Angelico]

On Thu, Apr 7, 2016 at 4:44 AM, Random832  wrote:
> On Wed, Apr 6, 2016, at 14:23, Marko Rauhamaa wrote:
>> Chris Angelico :
>>
>> > Plus, anyone could implement a Python interpreter with TCE.
>>
>> Tricky in practice because None is the default return value.
>>
>> If the programmer were careful to return the value of the tail call, it
>> can be eliminated.
>
> Well, the interpreter can know that the calling function doesn't return
> anything (returns None). Maybe it could pass a secret argument to the
> called function telling it not to return its value and to return None
> instead.

This is the exact sort of shenanigans that it takes to convert
recursion into tail recursion - and in MOST cases, it's very little
effort to go from there to explicit while loops. That's why TCE is so
infrequently important that it's just not worth the cost - which in
this case is damage to tracebacks.

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

Re: Best Practices for Internal Package Structure

[Sven R. Kunze]

On 06.04.2016 09:28, Michael Selik wrote:

On Wed, Apr 6, 2016, 2:51 AM Steven D'Aprano  wrote:


On Wed, 6 Apr 2016 05:56 am, Michael Selik wrote:

[Michael]

When you made that suggestion earlier, I immediately guessed that you

were

using PyCharm. I agree that the decision to split into multiple files or
keep everything in just a few files seems to be based on your development
tools. I use IPython and SublimeText, so my personal setup is more suited
to one or a few files.


Interesting to know. I remember us while looking for our next IDE, we 
investigated Sublime as well. I don't remember the exact reasons anymore 
but I remember this lightweight feeling of control and doing all sorts 
of boilerplatey, distracting things extremely easily and most 
importantly extremely fast. It just feels like doing plain'ol files 
editing but with less typing; you can think more (mental activity) than 
you need to write (physical activity). That brought us to another level 
when designing stuff. Keeps us able to handle the workload.


Thus, I use it for my small PyPI projects as well. Why should I use less 
capable tools for those projects:


https://github.com/srkunze/xheap
https://github.com/srkunze/fork
https://github.com/srkunze/xcache

They are small but deserve the same professionalism I daresay.


How does PyCharm make the use of many files easier?

I'll let Sven answer that one. I don't know, but I've noticed the
correlation of habit to IDE.


Definitely true. I think that's natural and doing otherwise would impair 
the productivity improvements provided by the tools.


About the "many files easier" question: not sure what I said exactly, 
but one could also ask: "what makes the alternatives harder?"


1) learning them and using them regularly
2) you need "switching to a file" as a requirement for those other 
alternatives I mentioned in the other post


So, you before you can even start learning the alternatives, you do 1000 
times "switch to a file".



Moreover, if you split things up properly, you don't need to jump 
between 20 files at once. Usually you fix a problem/build a feature in a 
narrow slot of your code (1-4 files). If you don't do that regularly, 
it's an indication you've split your stuff up the wrong way. ;-)



Last but not least, you basically don't look for files anymore. You look 
for names, and PyCharm opens the file you need. You jump from code 
position to code position by interacting (clicking, shortcuts, etc.) 
with the code. In one file, you have only one cursor. So, when PyCharm 
jumps within in a single file, you loose your previous cursor position 
(You can jump back but that's not permanent - especially when you do 
something else in the same file). If you have two files open, you have 
two cursors and you almost always reside at the same spot there. You 
COULD do that with a single view (split view as mentioned in the last 
post) but yeah that's not as easy as just another file.



Again this is a just an attempt of explaining an observation.

Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list

Re: functools puzzle

[George Trojan - NOAA Federal]

True, but the pure Python and C implementation differ. Is that
intentional?  I find the current behaviour confusing. The doc states only
that partial object does not set the __doc__ attribute, not that the
attribute might be ignored. I had a peek at the pydoc module. It uses
inspect to determine the type of object in question through the
inspect.isXXX() functions. My h is a function, while g is not.

This is a follow-up on my previous problem with sphinx not recognizing the
doc string. I don't know whether this and sphinx issues are related. My
basic question is how to document functions created by functools.partial,
such that the documentation can be viewed not only by reading the code. Of
course, as the last resort, I could create my own implementation (i.e. copy
the pure Python code).

George

On Wed, Apr 6, 2016 at 6:39 PM, Michael Selik 
wrote:

>
> > On Apr 6, 2016, at 6:57 PM, George Trojan - NOAA Federal <
> george.tro...@noaa.gov> wrote:
> >
> > The module functools has partial() defined as above, then overrides the
> > definition by importing partial from _functools. That would explain the
> > above behaviour. My question is why?
>
> A couple speculations why an author might retain a vestigial Python
> implementation after re-implementing in C: to provide a backup in case the
> C fails to compile or to simply provide an easier-to-read example of what
> the C is doing.
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Promoting Python

[Marko Rauhamaa]

Ian Kelly :

> On Wed, Apr 6, 2016 at 8:14 AM, Marko Rauhamaa  wrote:
>> Now, if Python had an unlimited range() iterator/iterable, you could use
>> a "for" statement to emulate "while".
>
> You can already do this.
>
 class While:
> ... def __init__(self, predicate):
> ... self._predicate = predicate
> ... self._exited = False
> ... def __iter__(self):
> ... return self
> ... def __next__(self):
> ... if self._exited or not self._predicate():
> ... self._exited = True
> ... raise StopIteration
> ...
 i = 0
 for _ in While(lambda: i < 10):
> ... print(i)
> ... i += 1
> ...
> 0
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9

Impressive!

>> As it stands, Python without "while" could only compute
>> primitive-recursive functions. However, you only need "while" a
>> maximum of one time in your whole program to perform an arbitrary
>> computation.
>
> So this is wrong.

I stand corrected.

However, BartC's No-Buzzword Python doesn't have classes... If he
allowed for types.SimpleNamespace, we could have:


import types

def While(predicate):
def __iter__():
return thingy
def __next__():
if thingy._exited or not predicate():
thingy._exited = True
raise StopIteration
thingy = types.SimpleNamespace(
_exited=False, __iter__=__iter__, __next__=__next__)
return thingy


However, that results in:

TypeError: 'types.SimpleNamespace' object is not iterable

Where's my bug? Or is CPython buggy? Or is it the documentation:

The iterator objects themselves are required to support the
following two methods, which together form the iterator protocol:

iterator.__iter__()

[...]

iterator.__next__()

https://docs.python.org/3/library/stdtypes.html#typeiter>

Why is a SimpleNamespace object not an iterator even though it provides
__iter__ and __next__?


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

Re: Best Practices for Internal Package Structure

[Sven R. Kunze]

On 06.04.2016 01:47, Chris Angelico wrote:

Generally, I refactor code not because the files are getting "too
large" (for whatever definition of that term you like), but because
they're stretching the file's concept. Every file should have a
purpose; every piece of code in that file should ideally be supporting
exactly that purpose.


Well said.

The definition of purpose and concept are blurry, though. So, what is 
within the boundary of a concept is hard to define.



@Steven
You might not understand the purpose of the guideline. That's what makes 
them so valuable. It's hard to get them right and it's hard to 
understand them if you don't have any experience with them.




An attempt of an explanation (which maybe in itself not 100% correct): 
there are two different forces acting on the source code:


1) make it short and concise (the 2-pages guideline)
2) keep conceptually close things together (cf. Chris)

So, there's always a bargaining of what can be put in/removed from a 
module in the first place:


"just these 14 lines, please; we need that feature"
"but the module already has 310 lines"
"only this one last one, please; it belongs here"
"but it's an if-else and another def; nasty nesting and more complexity"
"hmm, what if we remove those 5 over here? we don't need them anymore"
"really? then, we can remove 2 superfluous newlines and 2 import lines 
as well"

"I could even squeeze those 14 lines to 10 using dict comprehensions"
"that's even more readable; +1 line, that's okay"

Life is full of compromises.

This guideline is more about discussing, shaping existing code and 
extracting the essence (with yourself or with colleagues) to keep things 
on a usable level.


Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list

Re: Promoting Python

[Marko Rauhamaa]

Chris Angelico :

> This is the exact sort of shenanigans that it takes to convert
> recursion into tail recursion - and in MOST cases, it's very little
> effort to go from there to explicit while loops. That's why TCE is so
> infrequently important that it's just not worth the cost - which in
> this case is damage to tracebacks.

In Python, that is.

In Scheme, you write loops with tail recursion.

While you *could* use the (while code body ...) form in Scheme, that
would be falling out of religion.


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

Re: Promoting Python

[Ian Kelly]

On Wed, Apr 6, 2016 at 1:22 PM, Marko Rauhamaa  wrote:
> However, BartC's No-Buzzword Python doesn't have classes... If he
> allowed for types.SimpleNamespace, we could have:
>
> 
> import types
>
> def While(predicate):
> def __iter__():
> return thingy
> def __next__():
> if thingy._exited or not predicate():
> thingy._exited = True
> raise StopIteration
> thingy = types.SimpleNamespace(
> _exited=False, __iter__=__iter__, __next__=__next__)
> return thingy
> 
>
> However, that results in:
>
> TypeError: 'types.SimpleNamespace' object is not iterable
>
> Where's my bug? Or is CPython buggy? Or is it the documentation:
>
> The iterator objects themselves are required to support the
> following two methods, which together form the iterator protocol:
>
> iterator.__iter__()
>
> [...]
>
> iterator.__next__()
>
> https://docs.python.org/3/library/stdtypes.html#typeiter>
>
> Why is a SimpleNamespace object not an iterator even though it provides
> __iter__ and __next__?

Because Python expects those methods to be defined in the class dict,
not the instance dict. In a world with only SimpleNamespace and no
classes, I think we could reasonably expect that to work (assuming
that the iterator protocol is even still a thing in that world).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: good way to avoid recomputations?

[mauricioliveiraguarda]

Hi Erik. It's an Excel file. Thanks for the suggestions. Will check them. - 
Maurice
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Promoting Python

[Terry Reedy]

On 4/6/2016 10:14 AM, Marko Rauhamaa wrote:


Seriously, Python wouldn't be, couldn't be Turing-complete without
"while" (mainly because it doesn't support tail-recursion elimination).

Now, if Python had an unlimited range() iterator/iterable, you could use
a "for" statement to emulate "while".


For practical purposes, this equals 'while True: pass'

for i in itertools.count: pass

This is equivalent, regardless of memory.

class whiletrue:
def __iter__(self): return self
def __next__(self): return None

for none in whiletrue(): pass


--
Terry Jan Reedy

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

Re: [beginner] What's wrong?

[Thomas 'PointedEars' Lahn]

Rustom Mody wrote:

> On Sunday, April 3, 2016 at 5:17:36 PM UTC+5:30, Thomas 'PointedEars' Lahn
> wrote:
>> Rustom Mody wrote:
>> > When python went to full unicode identifers it should have also added
>> > pragmas for which blocks the programmer intended to use -- something
>> > like a charset declaration of html.
>> > 
>> > This way if the programmer says "I want latin and greek"
>> > and then A and Α get mixed up well he asked for it.
>> > If he didn't ask then springing it on him seems unnecessary and
>> > uncalled for
>> 
>> Nonsense.
> 
> Some misunderstanding of what I said it looks
> [Guessing also from Marko's "...silly..."]

First of all, while bandwidth might not be precious anymore to some, free 
time still is.  So please trim your quotations to the relevant minimum, to 
the parts you are actually referring to, and summarize properly if 
necessary.  For if you continue this mindbogglingly stupid full-quoting, 
this is going to be my last reply to you for a long time.  You have been 
warned.



> So here are some examples to illustrate what I am saying:
> 
> Example 1 -- Ligatures:
> 
> Python3 gets it right
 flag = 1
 flag
> 1

Fascinating; confirmed with

| $ python3 
| Python 3.4.4 (default, Jan  5 2016, 15:35:18) 
| [GCC 5.3.1 20160101] on linux
| […]

I do not think this is correct, though.  Different Unicode code sequences, 
after normalization, should result in different symbols.

> Whereas haskell gets it wrong:
> Prelude> let flag = 1
> Prelude> flag
> 
> :3:1: Not in scope: ‘flag’
> Prelude> flag
> 1
> Prelude>

I think Haskell gets it right here, while Py3k does not.  The “fl” is not to 
be decomposed to “fl”.
 
> Example 2 Case Sensitivity
> Scheme¹ gets it right
> 
>> (define a 1)
>> A
> 1
>> a
> 1

So Scheme is case-insensitive there.  So is (Visual) Basic.  That does not 
make it (any) better.
 
> Python gets it wrong
 a=1
 A
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'A' is not defined

This is not wrong; it is just different.  And given that identifiers 
starting with uppercase ought to be class names in Python (and other OOPLs 
that are case-sensitive there), and that a class name serves in constructor 
calls (in Python, instantiating a class is otherwise indistinguishable from 
a function call), it makes sense that the (maybe local) variable “a” should 
be different from the (probably global) class “A”.

> [Likewise filenames windows gets right; Unix wrong]

Utter nonsense.  Apparently you are blissfully unaware of how much grief it 
has caused WinDOS lusers and users alike over the years that Micro$~1 
decided in their infinite wisdom that letter case was not important.

Example: By contrast to previous versions, FAT32 supports long filenames 
(VFAT).  Go try changing a long filename from uppercase (“Really Long 
Filename.txt”) to partial lowercase (“Really long filename.txt”).  It does 
not work, you get an error, because the underlying “short filename” is the 
same as it is has to be case-insensitive for backwards compatibility 
(“REALLY~1.TXT”)  First you have to rename the file so that its name results 
in a different “short filename” (“REALLY~2.TXT”).  Then you have to rename 
it again to get the proper letter case (by which the “short filename” might 
either become “REALLY~1.TXT” again or “REALLY~3.TXT”).

> Unicode Identifiers in the spirit of IDN homograph attack.
> Every language that 'supports' unicode gets it wrong

NAK, see above.
 
> Python3
 A=1
 Α
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'Α' is not defined
 A
> 1
> 
> Can you make out why A both is and is not defined?

Fallacy.  “A” is _not_ both defined and not defined.  There is only one “A”.

However, given the proper font, I might see at a glance what is wrong there.  
In fact, in my Konsole[tm] where the default font is “Courier 10 Pitch” I 
clearly see what is wrong there.  “A” (U+0041 LATIN CAPITAL LETTER A) is 
displayed using that serif font where the letter has a serif to the left at 
cap height and serifs left and right on the baseline, while “Α” (U+0391 
GREEK CAPITAL LETTER ALPHA) is displayed using a sans-serif font, where also 
the cap height is considerably higher.
 
> When the language does not support it eg python2 the behavior is better

NAK.  Being able to use Unicode strings verbatim in a program without having 
to declare them is infinitely useful.  Unicode identifiers appear to be 
merely a (happy?) side effect of that.

> The notion of 'variable' in programming language is inherently based on
> that of 'identifier'.

ACK.

> With ASCII the problems are minor: Case-distinct identifiers are distinct
> -- they dont IDENTIFY.

I do not think this is a problem.

> This contradicts standard English usage and practice 

No, it does not.  English distinguishes between proper *nouns* and proper 
*names* (the latter can be the former).  For example,

Re: Promoting Python

[Marko Rauhamaa]

Ian Kelly :

> On Wed, Apr 6, 2016 at 1:22 PM, Marko Rauhamaa  wrote:
>> Why is a SimpleNamespace object not an iterator even though it
>> provides __iter__ and __next__?
>
> Because Python expects those methods to be defined in the class dict,
> not the instance dict.

The documentation does state: 

   these are used to allow user-defined classes to support iteration

although the rest of it only refers to objects.

It seems to me CPython is being a bit too picky here. Why should it care
if the method is a class method or an object method?

Anyway, that leaves the clever iterator trick out of No-Buzzword Python.


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

Re: Promoting Python

[Marko Rauhamaa]

Terry Reedy :

> On 4/6/2016 10:14 AM, Marko Rauhamaa wrote:
>
>> Seriously, Python wouldn't be, couldn't be Turing-complete without
>> "while" (mainly because it doesn't support tail-recursion
>> elimination).
>>
>> Now, if Python had an unlimited range() iterator/iterable, you could
>> use a "for" statement to emulate "while".
>
> For practical purposes, this equals 'while True: pass'
>
> for i in itertools.count: pass
>
> This is equivalent, regardless of memory.
>
> class whiletrue:
> def __iter__(self): return self
> def __next__(self): return None
>
> for none in whiletrue(): pass

By George, she's got it!

i = 0
for _ in itertools.count():
if i >= 10:
break
print(i)
i += 1

That is, assuming "break" is allowed.


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

recursive methods require implementing a stack?

[Charles T. Smith]

I just tried to write a recursive method in python - am I right that local
variables are only lexically local scoped, so sub-instances have the same
ones?  Is there a way out of that?  Do I have to push and pop my own simulated
stack frame entry? 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Promoting Python

[Ian Kelly]

On Wed, Apr 6, 2016 at 1:59 PM, Marko Rauhamaa  wrote:
> Ian Kelly :
>
>> On Wed, Apr 6, 2016 at 1:22 PM, Marko Rauhamaa  wrote:
>>> Why is a SimpleNamespace object not an iterator even though it
>>> provides __iter__ and __next__?
>>
>> Because Python expects those methods to be defined in the class dict,
>> not the instance dict.
>
> The documentation does state:
>
>these are used to allow user-defined classes to support iteration
>
> although the rest of it only refers to objects.
>
> It seems to me CPython is being a bit too picky here. Why should it care
> if the method is a class method or an object method?

Because the purpose of a class is to define the behavior of its
instances. A function stored in an object attribute technically isn't
a method at all. It's just a function that happens to be stored in an
object attribute, i.e. *data*. Why should the behavior of a
SimpleNamespace change just because somebody decided they wanted to
store something under the name "__iter__" (or worse,
"__getattribute__")?

Also, because not having to check the instance dict for the presence
of dunder methods is faster.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: recursive methods require implementing a stack?

[Rob Gaddi]

Charles T. Smith wrote:

> I just tried to write a recursive method in python - am I right that local
> variables are only lexically local scoped, so sub-instances have the same
> ones?  Is there a way out of that?  Do I have to push and pop my own simulated
> stack frame entry? 

You have been badly misled.  Python local variables are frame local, and
recursion just works.

-- 
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: Promoting Python

[Mark Lawrence via Python-list]

On 06/04/2016 18:55, Ned Batchelder wrote:


It took us a while to understand where Bart was coming from, but now we
understand, and we don't have to go around in circles.



No it didn't, it was quite clear from the beginning that he knew squat, 
and since then he's admitted that he knows squat.  About Python.  On the 
main Python list.  Perhaps he should hence forward be known as RUE2? 
Actually that is unfair, the original RUE only complains about PEP393 
unicode, BartC complains about everything.  I still do not believe that 
he could organise a piss up in a brewery, let alone write decent code. 
Until such time as I see proof that he has any idea at all as to what 
he's talking about, he stays firmly in my dream team.


--
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: Promoting Python

[Marko Rauhamaa]

Ian Kelly :

> On Wed, Apr 6, 2016 at 1:59 PM, Marko Rauhamaa  wrote:
>> It seems to me CPython is being a bit too picky here. Why should it
>> care if the method is a class method or an object method?
>
> Because the purpose of a class is to define the behavior of its
> instances. A function stored in an object attribute technically isn't
> a method at all. It's just a function that happens to be stored in an
> object attribute, i.e. *data*. Why should the behavior of a
> SimpleNamespace change just because somebody decided they wanted to
> store something under the name "__iter__" (or worse,
> "__getattribute__")?
>
> Also, because not having to check the instance dict for the presence
> of dunder methods is faster.

Not convinced. Probably just an oversight.

For example, file-like objects have no such reservations:

import sys
import types
import xml.dom.minidom

filelike = types.SimpleNamespace()
def write(s):
for c in s:
sys.stdout.write("{{{}}}".format(c))
filelike.write = write
filelike.close = lambda: None
doc = xml.dom.minidom.getDOMImplementation().createDocument(
None, "tag", None).writexml(filelike)
sys.stdout.write("\n")



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

Re: recursive methods require implementing a stack?

[Random832]

On Wed, Apr 6, 2016, at 16:21, Charles T. Smith wrote:
> I just tried to write a recursive method in python - am I right that
> local
> variables are only lexically local scoped, so sub-instances have the same
> ones?  Is there a way out of that?  Do I have to push and pop my own
> simulated
> stack frame entry? 

No, and I'm not sure why you would think that.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Promoting Python

[Ian Kelly]

On Wed, Apr 6, 2016 at 2:39 PM, Marko Rauhamaa  wrote:
> Ian Kelly :
>
>> On Wed, Apr 6, 2016 at 1:59 PM, Marko Rauhamaa  wrote:
>>> It seems to me CPython is being a bit too picky here. Why should it
>>> care if the method is a class method or an object method?
>>
>> Because the purpose of a class is to define the behavior of its
>> instances. A function stored in an object attribute technically isn't
>> a method at all. It's just a function that happens to be stored in an
>> object attribute, i.e. *data*. Why should the behavior of a
>> SimpleNamespace change just because somebody decided they wanted to
>> store something under the name "__iter__" (or worse,
>> "__getattribute__")?
>>
>> Also, because not having to check the instance dict for the presence
>> of dunder methods is faster.
>
> Not convinced. Probably just an oversight.

It's documented here:
https://docs.python.org/3/reference/datamodel.html#special-method-lookup

> For example, file-like objects have no such reservations:
>
> import sys
> import types
> import xml.dom.minidom
>
> filelike = types.SimpleNamespace()
> def write(s):
> for c in s:
> sys.stdout.write("{{{}}}".format(c))
> filelike.write = write
> filelike.close = lambda: None
> doc = xml.dom.minidom.getDOMImplementation().createDocument(
> None, "tag", None).writexml(filelike)
> sys.stdout.write("\n")

The minidom implementation is probably just calling
filelike.write('blah'). That will succeed in calling either a method
or a function-in-an-attribute. Note that the write function you
defined in this example has no self argument. This points to the fact
that it's not truly a method.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: recursive methods require implementing a stack?

[Carl Meyer]

On 04/06/2016 03:08 PM, Random832 wrote:
> On Wed, Apr 6, 2016, at 16:21, Charles T. Smith wrote:
>> I just tried to write a recursive method in python - am I right that
>> local
>> variables are only lexically local scoped, so sub-instances have the same
>> ones?  Is there a way out of that?  Do I have to push and pop my own
>> simulated
>> stack frame entry? 
> 
> No, and I'm not sure why you would think that.

Sounds like a confusion that might arise due to using a mutable default
arg? Or generally passing a mutable arg and not understanding Python's
calling semantics?

Carl



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

Re: Promoting Python

[Marko Rauhamaa]

Ian Kelly :

> On Wed, Apr 6, 2016 at 2:39 PM, Marko Rauhamaa  wrote:
>> Not convinced. Probably just an oversight.
>
> It's documented here:
> https://docs.python.org/3/reference/datamodel.html#special-method-lookup

Ok, not an oversight but some inherent trouble with the way object
methods are related with their prototypes in the class. An unexpected
deficiency in the object-class relationship of sorts.

> The minidom implementation is probably just calling
> filelike.write('blah'). That will succeed in calling either a method
> or a function-in-an-attribute. Note that the write function you
> defined in this example has no self argument. This points to the fact
> that it's not truly a method.

No true Scotsman, there?

Once you look up an object method, it doesn't have a self argument. The
self argument is cooked up for the benefit of the function definition in
the class.

IOW, if I have this class:

class A:
def f(self):
print("f")

and this object:

a = A()

then,

a.f

is a function that doesn't have a self argument. That function is
generated on the fly, and it delegates to A.f, providing it with self
argument.

However, a.f itself is just a function that doesn't accept any
arguments.

Defining:

def f():
print("f")
a.f = f

simply short-circuits the attribute lookup process; no need to consult
the class when the attribute (method!) is right there in the object's
dict.


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

Re: Promoting Python

[BartC]

On 06/04/2016 21:38, Mark Lawrence wrote:


No it didn't, it was quite clear from the beginning that he knew squat,
and since then he's admitted that he knows squat.  About Python.


I see. According to you:

(1) To have an opinion about a language, you have to know everything in 
it 100%, inside out and backwards.


(2) It's impossible for someone who's coded for decades to switch to a 
different language, just by familiarising themselves with the 
'controls', as people do when driving a different vehicle


(3) The only people who can give advice to newcomers in a language are 
complete experts in it, and not those who have experienced some of the 
same problems.




On the
main Python list.


I'm posting to a usenet group. I haven't subscribed to any list.

AFAIK this is a public group where anyone can post.


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

Evaluating error strings for 'unittest' assert methods.

[John Pote]

I have been writing a very useful test script using the standard Python 
'unittest' module. This works fine and has been a huge help in keeping 
the system I've been writing fully working even when I make changes that 
could break many features of the system. eg major rewrite of the 
interrupt routines. The target system in question is written in 'C' and 
runs on a 50p microcontroller at the end of a serial line.


I like each assert...() to output helpful information when things go 
wrong. So I have put in quite complicated code to generate the error 
string the assert() method uses only when things go wrong. The normal 
case, when everything is working, means that all these error strings are 
constructed only to be discarded immediately when the assert() detects 
the test result is correct and no exception is throw.


To my mind this seems a waste and adding unnecessary delays in the 
running of the whole test script.


So I was wondering if there was some convienient, Python, way of calling 
an assert() method so the error string is only evaluated/constructed if 
the assert() fails and throws an exception. For example,


self.assertEqual( (nBytes,expectedValues), (nBytesRd,valuesRead),
"""Unexpected reg value.
Expected values nBytes:%02x (%s)
"""%(nBytes,' '.join( [ "%04x"%v for v in expectedValues] )) +
"Read values nBytes:%02x (%s)"%(nBytesRd,' '.join( [ "%04x"%v for v 
in valuesRead] ))

)

Ideas invited, thanks everyone,
John
--
https://mail.python.org/mailman/listinfo/python-list

ola

[majoxd hola]

me podrían enviar el programa Python spyder para Windows?








Enviado desde Correo de Windows
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: functools puzzle

[Michael Selik]

On Wed, Apr 6, 2016 at 8:16 PM George Trojan - NOAA Federal <
george.tro...@noaa.gov> wrote:

> My basic question is how to document functions created by
> functools.partial, such that the documentation can be viewed not only by
> reading the code. Of course, as the last resort, I could create my own
> implementation (i.e. copy the pure Python code).
>

I don't think this is a complete solution, but it might get you a bit
closer.

import functools
import math

def party(func, *args, **kwargs):
d = {'__name__': func.__name__,
 '__doc__': func.__doc__,}
partial = type('partial', (functools.partial,), d)
foo = partial(func, *args, **kwargs)
return foo

exp = party(pow, math.e)
help(exp)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Evaluating error strings for 'unittest' assert methods.

[Ethan Furman]

On 04/06/2016 03:58 PM, John Pote wrote:

I have been writing a very useful test script using the standard Python
'unittest' module. This works fine and has been a huge help in keeping
the system I've been writing fully working even when I make changes that
could break many features of the system. eg major rewrite of the
interrupt routines. The target system in question is written in 'C' and
runs on a 50p microcontroller at the end of a serial line.

I like each assert...() to output helpful information when things go
wrong. So I have put in quite complicated code to generate the error
string the assert() method uses only when things go wrong. The normal
case, when everything is working, means that all these error strings are
constructed only to be discarded immediately when the assert() detects
the test result is correct and no exception is throw.

To my mind this seems a waste and adding unnecessary delays in the
running of the whole test script.

So I was wondering if there was some convienient, Python, way of calling
an assert() method so the error string is only evaluated/constructed if
the assert() fails and throws an exception. For example,

self.assertEqual( (nBytes,expectedValues), (nBytesRd,valuesRead),
 """Unexpected reg value.
Expected values nBytes:%02x (%s)
"""%(nBytes,' '.join( [ "%04x"%v for v in expectedValues] )) +
"Read values nBytes:%02x (%s)"%(nBytesRd,' '.join( [ "%04x"%v for v
in valuesRead] ))
 )


My first thought is don't sweat it, it probably doesn't matter.  You 
could test this by timing both before and after removing all the custom 
error messages.


If you do want to sweat it -- maybe a custom object that replaces the 
__str__ and __repr__ methods with the code that creates the message?  No 
idea if it would work, but it would look something like:


class DelayedStr(object):  # pesky 2/3 code ;)
def __init__(self, func):
self.func = func
def __str__(self):
return self.func()

and your assert would look like:


self.assertEqual(
(nBytes,expectedValues),
(nBytesRd,valuesRead),
lambda : """Unexpected reg value.
Expected values nBytes:%02x (%s)""" %
(nBytes,' '.join( [ "%04x"%v for v in expectedValues] )) +
"Read values nBytes:%02x (%s)"%(nBytesRd,
 ' '.join( [ "%04x"%v for v in valuesRead] )))

Certainly no more readable, but /maybe/ more performant.  (Assuming it 
even works.)


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

import opencv error (DLL load failed)

[Xristos Xristoou]

hi

i have windows 10 and python 3.5.1 and i want to install open cv.
first i go to http://www.lfd.uci.edu/~gohlke/pythonlibs/#opencv
and download the opencv_python-3.1.0-cp35-none-win_amd64.whl
from command prompt i install with pip.
pip install \opencv_python-3.1.0-cp35-none-win_amd64.whl
and show me successfuly installed opencv-python-3.1.0.
i look the files in the site-packages and now i have opencv files
cv.py
cv2.cp35-win_amd64.pyd
and more 
opencv.dll files
 

after successfuly installed open python idle i a try to import
cv2 and i take that error massege ..

error massege 

import cv2
Traceback (most recent call last):
  File "", line 1, in 
import cv2
ImportError: DLL load failed :

after this error downloaded opencv 3.0 and extracted it.copying cv2.pyd to the 
site-packages folder and show me again this error massege .

can you tell why?and how to FIX THAT ?

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

Joining Strings

[Emeka]

Hello All,

import urllib.request
import re

url = 'https://www.everyday.com/



req = urllib.request.Request(url)
resp = urllib.request.urlopen(req)
respData = resp.read()


paragraphs = re.findall(r'\[(.*?)\]',str(respData))
for eachP in paragraphs:
print("".join(eachP.split(',')[1:-2]))
print("\n")



I got the below:
"Coke -  Yala Market Branch""NO. 113 IKU BAKR WAY YALA"""
But what I need is

'Coke -  Yala Market Branch NO. 113 IKU BAKR WAY YALA'

How to I achieve the above?

Regards Janus


-- 
P.S Please join our groups*:  *nigeriaarduinogr...@googlegroups.com
* or *jifunze-kufiki...@googlegroups.com  These are platforms for learning
and sharing  of knowledge.
 www.satajanus.com | *Satajanus  Nig.
Ltd*
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [beginner] What's wrong?

[Chris Angelico]

On Thu, Apr 7, 2016 at 5:56 AM, Thomas 'PointedEars' Lahn
 wrote:
>> Example 1 -- Ligatures:
>>
>> Python3 gets it right
> flag = 1
> flag
>> 1
>
> Fascinating; confirmed with
>
> | $ python3
> | Python 3.4.4 (default, Jan  5 2016, 15:35:18)
> | [GCC 5.3.1 20160101] on linux
> | […]
>
> I do not think this is correct, though.  Different Unicode code sequences,
> after normalization, should result in different symbols.
>
>> Whereas haskell gets it wrong:
>> Prelude> let flag = 1
>> Prelude> flag
>>
>> :3:1: Not in scope: ‘flag’
>> Prelude> flag
>> 1
>> Prelude>
>
> I think Haskell gets it right here, while Py3k does not.  The “fl” is not to
> be decomposed to “fl”.

Unicode disagrees with you. It is decomposed exactly that way.

>>> unicodedata.normalize("NFKD","fl")
'fl'

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

Re: Joining Strings

[Ben Finney]

Emeka  writes:

> Hello All,
>
> import urllib.request
> import re
>
> url = 'https://www.everyday.com/

This URL doesn't resolve for me, so I can't reproduce the behaviour.

> I got the below:
> "Coke -  Yala Market Branch""NO. 113 IKU BAKR WAY YALA"""
> But what I need is
>
> 'Coke -  Yala Market Branch NO. 113 IKU BAKR WAY YALA'
>
> How to I achieve the above?

To diagnose the problem, I would recommend dividing it into smaller
problems:

* Get the content from that URL, confirm it is as you expect. Deal with
  it as Unicode text from that point forward.

* Transform the Unicode text somehow to produce output. Compare that
  output against the expected output.

That way you can see at what point the behaviour is not as you expect.
Then, please make a more self-contained example that demonstrates the
behaviour confusing you.

-- 
 \  “[Entrenched media corporations will] maintain the status quo, |
  `\   or die trying. Either is better than actually WORKING for a |
_o__)  living.” —ringsnake.livejournal.com, 2007-11-12 |
Ben Finney

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

Re: ola

[Joel Goldstick]

2016-04-05 20:35 GMT-04:00 majoxd hola :
> me podrían enviar el programa Python spyder para Windows?
>
>
>
>
>
>
>
>
> Enviado desde Correo de Windows
> --
> https://mail.python.org/mailman/listinfo/python-list

This is an english language list.  And besides, your question I could
send the Python program spyder for Windows? is awfully vague

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

Re: Promoting Python

[Rolf Camps]

Op 07-04-16 om 00:03 schreef Marko Rauhamaa:

Once you look up an object method, it doesn't have a self argument. The
self argument is cooked up for the benefit of the function definition in
the class.

IOW, if I have this class:

 class A:
 def f(self):
 print("f")

and this object:

 a = A()

then,

 a.f

is a function that doesn't have a self argument. That function is
generated on the fly, and it delegates to A.f, providing it with self
argument.

a.f is not a function, A.f is a function.
a.f is an instance method. The function is not generated on the fly, 
when the method is called, it calls the function A.f with an extra 
argument __self__ (the instance a) inserted before the argument list the 
instance method was called with.

So calling a.f() is a convenient way to write A.f(a)


However, a.f itself is just a function that doesn't accept any
arguments.
As i wrote, a.f is an instance method not a function. It accepts any 
argument you trow at it, insert 'a' in front of the argument list and 
calls the function A.f with this new argument list.


Defining:

 def f():
 print("f")
 a.f = f

simply short-circuits the attribute lookup process; no need to consult
the class when the attribute (method!) is right there in the object's
dict.
Here a.f is a function so Python will treat is as a function. When you 
call it, the lookup process will find f in the class instance 
dictionary, discover it's a function and run it with the arguments 
provided. If you would like to use  attributes of the class A or of the 
instance 'a' in f, you would need to hard code it in the function since 
the function f does not know it was called from 'a', an instance of the 
class A.



Marko

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

Unicode normalisation [was Re: [beginner] What's wrong?]

[Steven D'Aprano]

On Thu, 7 Apr 2016 05:56 am, Thomas 'PointedEars' Lahn wrote:

> Rustom Mody wrote:

>> So here are some examples to illustrate what I am saying:
>> 
>> Example 1 -- Ligatures:
>> 
>> Python3 gets it right
> flag = 1
> flag
>> 1

Python identifiers are intentionally normalised to reduce security issues,
or at least confusion and annoyance, due to visually-identical identifiers
being treated as different.

Unicode has technical standards dealing with identifiers:

http://www.unicode.org/reports/tr31/

and visual spoofing and confusables:

http://www.unicode.org/reports/tr39/

I don't believe that CPython goes to the full extreme of checking for mixed
script confusables, but it does partially mitigate the problem by
normalising identifiers.

Unfortunately PEP 3131 leaves a number of questions open. Presumably they
were answered in the implementation, but they aren't documented in the PEP.

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




> Fascinating; confirmed with
> 
> | $ python3
> | Python 3.4.4 (default, Jan  5 2016, 15:35:18)
> | [GCC 5.3.1 20160101] on linux
> | […]
> 
> I do not think this is correct, though.  Different Unicode code sequences,
> after normalization, should result in different symbols.

I think you are confused about normalisation. By definition, normalising
different Unicode code sequences may result in the same symbols, since that
is what normalisation means.


Consider two distinct strings which nevertheless look identical:

py> a = "\N{LATIN SMALL LETTER U}\N{COMBINING DIAERESIS}"
py> b = "\N{LATIN SMALL LETTER U WITH DIAERESIS}"
py> a == b
False
py> print(a, b)
ü ü


The purpose of normalisation is to turn one into the other:

py> unicodedata.normalize('NFKC', a) == b  # compose 2 code points --> 1
True
py> unicodedata.normalize('NFKD', b) == a  # decompose 1 code point --> 2
True


In the case of the fl ligature, normalisation splits the ligature into
individual 'f' and 'l' code points regardless of whether you compose or
decompose:

py> unicodedata.normalize('NFKC', "flag") == "flag"
True
py> unicodedata.normalize('NFKD', "flag") == "flag"
True


That's using the combatability composition form. Using the default
composition form leaves the ligature unchanged.

Note that UTS #39 (security mechanisms) suggests that identifiers should be
normalised using NFKC.

[...]
> I think Haskell gets it right here, while Py3k does not.  The “fl” is not
> to be decomposed to “fl”.

The Unicode consortium seems to disagree with you. Table 1 of UTS #39 (see
link above) includes "Characters that cannot occur in strings normalized to
NFKC" in the Restricted category, that is, characters which should not be
used in identifiers. fl cannot occur in such normalised strings, and so it
is classified as Restricted and should not be used in identifiers.


I'm not entirely sure just how closely Python's identifiers follow the
standard, but I think that the intention is to follow something close to
"UAX31-R4. Equivalent Normalized Identifiers":

http://www.unicode.org/reports/tr31/#R4


[Rustom] 
>> Python gets it wrong
> a=1
> A
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> NameError: name 'A' is not defined
> 
> This is not wrong; it is just different.

I agree with Thomas here. Case-insensitivity is a choice, and I don't think
it is a good choice for programming identifiers. Being able to make case
distinctions between (let's say):

SPAM  # a constant, or at least constant-by-convention
Spam  # a class or type
spam  # an instance


is useful.


[Rustom]
>> With ASCII the problems are minor: Case-distinct identifiers are distinct
>> -- they dont IDENTIFY.
> 
> I do not think this is a problem.
> 
>> This contradicts standard English usage and practice
> 
> No, it does not.


I agree with Thomas here too. Although it is rare for case to make a
distinction in English, it does happen. As the old joke goes:

Capitalisation is the difference between helping my Uncle Jack off a horse,
and helping my uncle jack off a horse.


So even in English, capitalisation can make a semantic difference.




-- 
Steven

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

Re: Best Practices for Internal Package Structure

[Chris Angelico]

On Thu, Apr 7, 2016 at 5:37 AM, Sven R. Kunze  wrote:
> On 06.04.2016 01:47, Chris Angelico wrote:
>>
>> Generally, I refactor code not because the files are getting "too
>> large" (for whatever definition of that term you like), but because
>> they're stretching the file's concept. Every file should have a
>> purpose; every piece of code in that file should ideally be supporting
>> exactly that purpose.
>
>
> Well said.
>
> The definition of purpose and concept are blurry, though. So, what is within
> the boundary of a concept is hard to define.

Oh, I never said it was easy to define :) That's the goal, to be sure,
but there are plenty of times when code goes into file X because it's
called by stuff in file X, even if conceptually it might be closer to
file Y. And then when file Z needs it, does it get moved to file Y, or
left where it is? Hard problem.

> @Steven
> You might not understand the purpose of the guideline. That's what makes
> them so valuable. It's hard to get them right and it's hard to understand
> them if you don't have any experience with them.

I'm not sure what you mean here. Are you saying that the guideline is
valuable precisely because people don't understand its purpose? I can
believe you, in the sense that the guideline becomes a summary of a
whole lot of rules (eg "you may not check in your code if it doesn't
comply with PEP 8" rather than arguing the specifics of why specific
style rules are important), but generally, there should be a
straight-forward explanation. And since this is a question of style,
there's usually going to be arguments on both sides :)

> An attempt of an explanation (which maybe in itself not 100% correct): there
> are two different forces acting on the source code:
>
> 1) make it short and concise (the 2-pages guideline)
> 2) keep conceptually close things together (cf. Chris)
>
> So, there's always a bargaining of what can be put in/removed from a module
> in the first place:
>
> "just these 14 lines, please; we need that feature"
> "but the module already has 310 lines"
> "only this one last one, please; it belongs here"
> "but it's an if-else and another def; nasty nesting and more complexity"
> "hmm, what if we remove those 5 over here? we don't need them anymore"
> "really? then, we can remove 2 superfluous newlines and 2 import lines as
> well"
> "I could even squeeze those 14 lines to 10 using dict comprehensions"
> "that's even more readable; +1 line, that's okay"
>
> Life is full of compromises.

This kind of bargaining sounds like a great way to force compromises
on people. Let's take it up a level: I need you to maintain this
project, but you're not allowed to make it exceed 10K lines of code
across all files. And it's already at 9,994 lines. So if you want to
add code to it, you have to find someplace else to remove code first.
Like all such guidelines, it has some plausible justification (it
prevents software bloat), but this rule can only hurt your project.
What happens when you have fifteen lines of code to add, to cope with
an obscure edge case involving user input? Which of these options do
you pick?

1) Edit your code down to just six lines, cramming everything in as
tightly as possible. To stay within an 80-char limit, you shorten
names and avoid comments. OR...
2) Find fifteen lines of internal API documentation somewhere and
delete it. Everyone should know that stuff by now, and if not, they
can always look back through source control. OR...
3) Find two twenty-line blocks of code that look identical and really
quickly break it out into a function. HA! WIN! And in your haste, you
don't notice that there was a subtle difference between them. OR...
4) Spend three hours working on a file, completely reworking it in a
more compact way, saving 50-100 lines of code, but losing track of
what you were doing, costing you an additional half an hour on your
original job as well.

All of them comply with the arbitrary 10KLOC limit. All of them have
hefty costs in future maintainability. And having a code file size
limit is exactly the same, except that you add a fifth option "find
something to move to another file", which just moves the problem
around a bit. Arbitrary limits might solve one problem, but they tend
to introduce another.

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

Re: Promoting Python

[Chris Angelico]

On Thu, Apr 7, 2016 at 5:30 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> This is the exact sort of shenanigans that it takes to convert
>> recursion into tail recursion - and in MOST cases, it's very little
>> effort to go from there to explicit while loops. That's why TCE is so
>> infrequently important that it's just not worth the cost - which in
>> this case is damage to tracebacks.
>
> In Python, that is.
>
> In Scheme, you write loops with tail recursion.
>

Yes, in Python. I don't know anything about how you debug code in
Scheme, or what sort of error tracebacks you get, so I can't speak to
the consequences *in Scheme* of TCE. All I know is that infinite
recursion in finite space requires the stack frames to be dropped
completely, which means you can't follow through them in the
traceback. And that's a direction GvR doesn't want Python to go.

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

Re: Untrusted code execution

[Steven D'Aprano]

On Wed, 6 Apr 2016 11:14 pm, Random832 wrote:

> On Tue, Apr 5, 2016, at 21:43, Steven D'Aprano wrote:
>> As Zooko says, Guido's "best argument is that reducing usability (in
>> terms
>> of forbidding language features, especially module import) and reducing
>> the
>> usefulness of extant library code" would make the resulting interpreter
>> too
>> feeble to be useful.
> 
> You don't have to forbid module import. The sandbox could control what
> modules can be loaded, and what happens when you try to load a module.


Sure, but you do have to forbid import of *arbitrary* modules. One could
include a white list of allowed modules, but it would probably be quite
small.

And you would have to do something about the unfortunate matter that modules
have a reference to the unrestricted __builtins__:

py> os.__builtins__['eval']



And because modules are singletons, it's not just a matter of replacing the
__builtins__ with a more restrictive one, as that would affect trusted
modules outside the sandbox too.



-- 
Steven

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

Re: Untrusted code execution

[Chris Angelico]

On Thu, Apr 7, 2016 at 11:45 AM, Steven D'Aprano  wrote:
> And you would have to do something about the unfortunate matter that modules
> have a reference to the unrestricted __builtins__:
>
> py> os.__builtins__['eval']
> 

This *in itself* is blocked by the rule against leading-underscore
attribute lookup. However, if you can get the sys module, the world's
your oyster; and any other module that imports sys will give it to
you:

>>> import os
>>> os.sys

>>> codecs.sys


Can't monkey-patch that away, and codecs.sys.modules["builtins"] will
give you access to the original builtins. And you can go to any number
of levels, tracing a chain from a white-listed module to the
unrestricted sys.modules. The only modules that would be safe to
whitelist are those that either don't import anything significant (I'm
pretty sure 'math' is safe), or import everything with underscores
("import sys as _sys").

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

Re: Evaluating error strings for 'unittest' assert methods.

[Steven D'Aprano]

On Thu, 7 Apr 2016 08:58 am, John Pote wrote:

[...]
> I like each assert...() to output helpful information when things go
> wrong. So I have put in quite complicated code to generate the error
> string the assert() method uses only when things go wrong. The normal
> case, when everything is working, means that all these error strings are
> constructed only to be discarded immediately when the assert() detects
> the test result is correct and no exception is throw.
> 
> To my mind this seems a waste and adding unnecessary delays in the
> running of the whole test script.

This sounds like premature optimization. I would be very surprised if this
actually makes much difference to the run time of the test suite, unless
the tests are *really* basic and the error strings *impressively* complex.
Your example below:


> So I was wondering if there was some convienient, Python, way of calling
> an assert() method so the error string is only evaluated/constructed if
> the assert() fails and throws an exception. For example,
> 
> self.assertEqual( (nBytes,expectedValues), (nBytesRd,valuesRead),
>  """Unexpected reg value.
> Expected values nBytes:%02x (%s)
> """%(nBytes,' '.join( [ "%04x"%v for v in expectedValues] )) +
> "Read values nBytes:%02x (%s)"%(nBytesRd,' '.join( [ "%04x"%v for v
> in valuesRead] ))
>  )

doesn't look too complicated too me. So my *guess* is that you are worried
over a tiny proportion of your actual runtime. Obviously I haven't seen
your code, but thinking about my own test suites, I would be shocked if it
was as high as 1% of the total. But I might be wrong.

You might try running the profiler over your test suite and see if it gives
you any useful information, but I suspect not.

Otherwise -- and I realise that this is a lot of work -- I'd consider making
a copy of your test script, then go through the copy and replace every
single one of the error messages with the same short string, say, "x". Now
run the two versions, repeatedly, and time how long they take.

On Linux, I would do something like this (untested):


time python -m unittest test_mymodule > /dev/null 2>&1


the intent being to ignore the overhead of actual printing any error
messages to the screen, and just seeing the execution time. Run that (say)
ten times, and pick the *smallest* runtime. Now do it again with the
modified tests:

time python -m unittest test_mymodule_without_messages > /dev/null 2>&1


My expectation is that if your unit tests do anything like a significant
amount of processing, the difference caused by calculating a few extra
error messages will be insignificant.



But, having said that, what version of Python are you using? Because the
unittest module in Python 3 is *significantly* enhanced and prints much
more detailed error messages without any effort on your part at all.

https://docs.python.org/3/library/unittest.html

For example, starting in Python 3.1, assertEqual() on two strings will
display a multi-line diff of the two strings if the test fails. Likewise,
there are type-specific tests for lists, dicts, etc. which are
automatically called by assertEqual, and the default error message contains
a lot more information than the Python 2 version does.


If you're stuck with Python 2, I *think* that the new improved unittest
module is backported as unittest2:


https://pypi.python.org/pypi/unittest2



-- 
Steven

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

Re: Untrusted code execution

[Random832]

On Wed, Apr 6, 2016, at 21:45, Steven D'Aprano wrote:
> And you would have to do something about the unfortunate matter that
> modules
> have a reference to the unrestricted __builtins__:
> 
> py> os.__builtins__['eval']
> 

Well, I thought that the solution being discussed uses AST to generally
forbid accessing attributes beginning with _ (you could also implement a
whitelist there)

> And because modules are singletons, it's not just a matter of replacing
> the
> __builtins__ with a more restrictive one, as that would affect trusted
> modules outside the sandbox too.

There's nothing actually preventing creating a module with the same name
as a "real" one, not registered in sys.modules, and having it in the
sandbox's sys.modules (the sandbox's sys module itself being a fake
module) to be imported by the sandbox's __import__.

__import__ doesn't even have to return a module - you could return some
other object, maybe one that proxies whitelisted name accesses to the
real module.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Untrusted code execution

[Steven D'Aprano]

On Thursday 07 April 2016 13:40, Random832 wrote:

> On Wed, Apr 6, 2016, at 21:45, Steven D'Aprano wrote:
>> And you would have to do something about the unfortunate matter that
>> modules
>> have a reference to the unrestricted __builtins__:
>> 
>> py> os.__builtins__['eval']
>> 
> 
> Well, I thought that the solution being discussed uses AST to generally
> forbid accessing attributes beginning with _ (you could also implement a
> whitelist there)


Sure, but I'm just demonstrating that the unrestricted builtins are just one 
attribute lookup away. And as Chris points out, if you have (say) the os 
module, then:

magic = os.sys.modules[
''.join(chr(i-1) for i in (96,96,99,118,106,109,117,106,111,116,96,96))
][''.join(chr(i+17) for i in (84,101,80,91))]


and that's Game Over.


It's not that this necessarily can't be done, but that it's sufficiently 
hard that very few people are willing to tackle it, and those who are, even 
fewer have come even close to a working restricted Python. PyPy has a 
sandbox, but I believe that relies on OS-level features like jails, and I 
don't really know how well it works.

The problem with sandboxing Python is that it's a game of cat and mouse: you 
eliminate one hole, and then wait for somebody to publish the next hole, 
then eliminate that, and so on. Will this process converge on a useful 
subset of Python? Perhaps. Will it happen soon? Even more doubtful.

Nobody says that its impossible. Only that its hard, real hard, and probably 
much harder than anyone thinks.



-- 
Steve

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

Re: Joining Strings

[Jussi Piitulainen]

Emeka writes:

> Hello All,
>
> import urllib.request
> import re
>
> url = 'https://www.everyday.com/
>
>
>
> req = urllib.request.Request(url)
> resp = urllib.request.urlopen(req)
> respData = resp.read()
>
>
> paragraphs = re.findall(r'\[(.*?)\]',str(respData))
> for eachP in paragraphs:
> print("".join(eachP.split(',')[1:-2]))
> print("\n")
>
>
>
> I got the below:
> "Coke -  Yala Market Branch""NO. 113 IKU BAKR WAY YALA"""
> But what I need is
>
> 'Coke -  Yala Market Branch NO. 113 IKU BAKR WAY YALA'
>
> How to I achieve the above?

A couple of things you could do to understand your problem and work
around it: Change your code to print(eachP). Change your "".join to
"!".join to see where the commas were. Experiment with data of that form
in the REPL. Sometimes it's good to print repr(datum) instead of datum,
though not in this case.

But are you trying to extract and parse paragraphs from a JSON response?
Do not use regex for that at all. Use json.load or json.loads to parse
it properly, and access the relevant data by indexing:

x = json.loads('{"foo":[["Weather Forecast","It\'s Rain"],[]]}')

x ==> {'foo': [['Weather Forecast', "It's Rain"], []]}

x['foo'] ==> [['Weather Forecast', "It's Rain"], []]

x['foo'][0] ==> ['Weather Forecast', "It's Rain"]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Promoting Python

[Marko Rauhamaa]

Rolf Camps :

> Op 07-04-16 om 00:03 schreef Marko Rauhamaa:
>> IOW, if I have this class:
>>
>>  class A:
>>  def f(self):
>>  print("f")
>>
>> and this object:
>>
>>  a = A()
>>
>> then,
>>
>>  a.f
>>
>> is a function that doesn't have a self argument. That function is
>> generated on the fly, and it delegates to A.f, providing it with self
>> argument.
> a.f is not a function, A.f is a function.
> a.f is an instance method. The function is not generated on the fly,
> when the method is called, it calls the function A.f with an extra
> argument __self__ (the instance a) inserted before the argument list the
> instance method was called with.

What you call an instance method *is* a function, meaning it is bound to
a callable object that in almost no outward way differs from any other
function.

It is generated on the fly:

   >>> id(a.f)
   140059683793288
   >>> id(a.f)
   140059683793864
   >>> a.f is a.f
   False

You are correct that the generated function is a simple trampoline that
supplies a self argument and delegates to A.f.

Or:

   When a class attribute reference (for class C, say) would yield a
   class method object, it is transformed into an instance method object
   whose __self__ attributes is C.
   https://docs.python.org/3/reference/datamodel.html?highlight=__g
   etattr__#the-standard-type-hierarchy>

So the only difference between a regular function and an instance method
object is the fact that the latter has a __self__ attribute set.

Although even that small difference can be paved over:

def g():
print("g")
g.__self__ = a
a.f = g


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

Re: Unicode normalisation [was Re: [beginner] What's wrong?]

[Marko Rauhamaa]

Steven D'Aprano :

> So even in English, capitalisation can make a semantic difference.

It can even make a pronunciation difference: polish vs Polish.


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

Re: recursive methods require implementing a stack?

[Charles T. Smith]

On Wed, 06 Apr 2016 20:28:47 +, Rob Gaddi wrote:

> Charles T. Smith wrote:
> 
>> I just tried to write a recursive method in python - am I right that local
>> variables are only lexically local scoped, so sub-instances have the same
>> ones?  Is there a way out of that?  Do I have to push and pop my own 
>> simulated
>> stack frame entry? 
> 
> You have been badly misled.  Python local variables are frame local, and
> recursion just works.


Well, I probably stumbled astray due to my own stupidity, can't blame anybody
of having misled me...  ;)

So it's a bug in my program!  Good news!  Thank you. 

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

Unacceptable behavior

[Ethan Furman]

On 04/05/2016 01:05 PM, Thomas 'PointedEars' Lahn wrote:

> | >>> from email import ID10T

Thomas, as has been pointed out to you in previous threads it is not 
necessary to be rude to be heard.


You are hereby placed in moderation for the Python List mailing list.

Every one else:  If you see offensive posts from Thomas on the usenet 
side, please just ignore them.  I have no desire to see his posts in 
your replies.


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