The message was not delivered

[noreply]

The attached message was mark as  SPAM. The message was not delivered.--- Begin Message ---

Some parts of this message were removed because they violated your mail 
server's policies.


message.zip was removed from the message because it violates your mail server's 
policy.

--- Begin Message ---
The original message was received at Sat, 13 Oct 2012 11:45:52 +0530
from python.org [61.241.245.113]

- The following addresses had permanent fatal errors -
t...@combimaragemar.it



--- End Message ---
--- End Message ---
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feedback on my python framework I'm building.

[Etienne Robillard]

On Fri, 12 Oct 2012 21:49:55 -0700 (PDT)
nbvf...@gmail.com wrote:

> http://giotto.readthedocs.org/en/latest/tutorial.html
> 
> Can someone give me some feedback on what they think of this framework? I 
> came up with the idea of this framework a few months ago. I gave a talk at a 
> local python user group regarding these ideas, but no one seemed to think I 
> was onto anything special or useful.
> 
> Basically its a framework that forces the developer(s) to strictly separate 
> the model from the view and controller. You can 'hook up' multiple 
> controllers to a project. The model layer can be completely mocked out so 
> front end designers don't have to bother setting up 
> Postgres/rabbitmq/whatever.
> 
> Does anyone have any throughts or feedback?


Docs are useless for developers with an quarter of imagination. :-)

-- 
Etienne Robillard
Green Tea Hackers Club
Fine Software Carpentry For The Rest Of Us!
http://gthc.org/
e...@gthcfoundation.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to use "while" within the command in -c option of python?

[Thomas Bach]

On Sat, Oct 13, 2012 at 12:32:41AM +, Steven D'Aprano wrote:
> 
>  He gets SyntaxError because you can't follow a semicolon with a
> statement that begins a block.

Can someone provide a link on where to find this type of information?
I was just hunting through “The Python Language Reference” and could
not find anything explicit. The only thing I found is

http://docs.python.org/reference/simple_stmts.html

“Several simple statements may occur on a single line separated by
semicolons.”

Anyways, this does not explicitly say “You shall not put a compound
statement after a simple statement separated by a semicolon.”, right?

Regards,
Thomas Bach.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to use "while" within the command in -c option of python?

[Chris Angelico]

On Sat, Oct 13, 2012 at 7:41 PM, Thomas Bach
 wrote:
> On Sat, Oct 13, 2012 at 12:32:41AM +, Steven D'Aprano wrote:
>>
>>  He gets SyntaxError because you can't follow a semicolon with a
>> statement that begins a block.
>
> Can someone provide a link on where to find this type of information?
> I was just hunting through “The Python Language Reference” and could
> not find anything explicit. The only thing I found is
>
> http://docs.python.org/reference/simple_stmts.html
>
> “Several simple statements may occur on a single line separated by
> semicolons.”
>
> Anyways, this does not explicitly say “You shall not put a compound
> statement after a simple statement separated by a semicolon.”, right?

It's more that Python treats simple and compound statements as
completely separate beasts. You can combine simple statements on one
line, but compound statements mustn't be.

In my opinion, this is a major wart in Python syntax. You can argue
all you like about how it reduces code clarity to put these sorts of
things together, but that's a job for a style guide, NOT a language
requirement. Most code won't put an assignment followed by an
if/while/for, but when I'm working interactively, I often want to
recall an entire statement to edit and reuse, complete with its
initialization - something like (contrived example):

>>> a=collections.defaultdict(int)
>>> for x in open("RilvierRex.txt"): a[x]+=1

Then I keep doing stuff, keep doing stuff, and then come back to this
pair of lines. Since they're two lines, I have to recall them as two
separate entities, rather than as an initializer and the code that
uses it. Logically, they go together. Logically, they're on par with a
list comprehension, which initializes, loops, and assigns, all as a
single statement. But syntactically, they're two statements that have
to go on separate lines.

To force that sort of thing to be a single recallable statement, I can
do stupid tricks like:

>>> if True:
a=collections.defaultdict(int)
for x in open("RilvierRex.txt"): a[x]+=1

but that only works in IDLE, not in command-line interactive Python.

Note, by the way, that it's fine to put the statement _inside_ the for
on the same line. It's even legal to have multiple such statements:

>>> for x in (1,2,3): print(x); print(x);
1
1
2
2
3
3

If there's any ambiguity, it would surely be that, and not the simple
statement being first.

Okay, rant over. I'll go back to being nice now. :)

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

Re: Checking for dlls in ctypes

[Nobody]

On Fri, 12 Oct 2012 12:28:17 -0400, Dave Angel wrote:

> Using bare excepts is almost never a good idea.  If it "works" you get no
> clues what went wrong.  For example, a typo in source code can trigger a
> bare exception, as can a user typing Ctrl-C.   So when you're using bare
> excepts, you have robbed the user of any way to terminate the program.

If you want to catch any error, use "except StandardError:". That covers
all errors but not things like KeyboardInterrupt (Ctrl-C) or SystemExit
(sys.exit()).

In situations such as this, where you try multiple candidates until one
succeeds, there's no reason to be any more specific than that. In any
case, Python's lack of formal interfaces makes it hard to reliably be more
specific.

However: you should bear in mind that loading the wrong DLL may just
result in an OS-level exception (e.g. segfault), which can't be caught.
It's preferable to allow the DLL to be explicitly selected e.g. in a
configuration file.

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

readline trick needed

[Steven D'Aprano]

I'm working with the readline module, and I'm trying to set a key 
combination to process the current command line by calling a known 
function, *and* enter the command line.

Something along the lines of:

* execute function spam() in some context where it can access 
  the current command line as a string
* enter the command line

Function spam() may or may not modify the command line.

Here is what I have got so far: I can discard the current line and call a 
function:

readline.parse_and_bind(r'"\C-p": "%cspam()\n"' % 0x15)  # ^U

binds ctrl-P to the key combinations `ctrl-U spam() Enter`, which clears 
the command line before entering spam().

If I leave out the ctrl-U, I'll get a SyntaxError or other exception, 
e.g. command line `x = 123` gets transformed into `x = 123spam()`.


This is not suitable:

readline.parse_and_bind(r'"\C-p": "; spam()\n"')

because it changes the command line. It's okay for spam() itself to 
modify the command line, but the key binding should not.

I tried to do this:

readline.parse_and_bind(r'"\C-p": "\nspam()\n"')

but it gives me a segmentation fault, which is a little less helpful than 
I had expected.

This Stackoverflow question suggests that what I want is not possible in 
vanilla Python:

http://stackoverflow.com/questions/11680356


but I'm a stubborn guy and I have not given up yet. Any suggestions?


(P.S. I'm aware of IPython, I want to get this working in the standard 
CPython interpreter.)


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: readline trick needed

[Etienne Robillard]

On 13 Oct 2012 13:30:14 GMT
Steven D'Aprano  wrote:

> I'm working with the readline module, and I'm trying to set a key 
> combination to process the current command line by calling a known 
> function, *and* enter the command line.
> 
> Something along the lines of:
> 
> * execute function spam() in some context where it can access 
>   the current command line as a string
> * enter the command line
> 
> Function spam() may or may not modify the command line.
> 
> Here is what I have got so far: I can discard the current line and call a 
> function:
> 
> readline.parse_and_bind(r'"\C-p": "%cspam()\n"' % 0x15)  # ^U
> 
> binds ctrl-P to the key combinations `ctrl-U spam() Enter`, which clears 
> the command line before entering spam().
> 
> If I leave out the ctrl-U, I'll get a SyntaxError or other exception, 
> e.g. command line `x = 123` gets transformed into `x = 123spam()`.
> 
> 
> This is not suitable:
> 
> readline.parse_and_bind(r'"\C-p": "; spam()\n"')
> 
> because it changes the command line. It's okay for spam() itself to 
> modify the command line, but the key binding should not.
> 
> I tried to do this:
> 
> readline.parse_and_bind(r'"\C-p": "\nspam()\n"')
> 
> but it gives me a segmentation fault, which is a little less helpful than 
> I had expected.
> 
> This Stackoverflow question suggests that what I want is not possible in 
> vanilla Python:
> 
> http://stackoverflow.com/questions/11680356
> 
> 
> but I'm a stubborn guy and I have not given up yet. Any suggestions?
> 
> 
> (P.S. I'm aware of IPython, I want to get this working in the standard 
> CPython interpreter.)
> 
> 
> -- 
> Steven
> -- 
> http://mail.python.org/mailman/listinfo/python-list


Why dont you grow yourself some usable neurons instead ? Don't you realize now 
stackoverflow.com is starting
to hurt your capacity to cogitate on your own or have you not realized this yet?

Cheers,

Etienne


-- 
Etienne Robillard
Green Tea Hackers Club
Fine Software Carpentry For The Rest Of Us!
http://gthc.org/
e...@gthcfoundation.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Checking for dlls in ctypes

[88888 Dihedral]

Wanderer於 2012年10月12日星期五UTC+8下午11時36分27秒寫道：
> I'm trying to write some code that will load one of three dll depending on 
> the one available. I've tried the code below, but it doesn't work. The try 
> except doesn't catch the exception. Is there a way to do this?
> 
> 
> 
> try:
> 
> self.dll = windll.pvcam64
> 
> except:
> 
> print "No pvcam64"
> 
> try:
> 
> self.dll = windll.pvcam32
> 
> except:
> 
> print "No pvcam32"
> 
> try:
> 
> self.dll = windll.pvcam
> 
> except:
> 
> print "No pvcam"
> 
> return
> 
> else:
> 
> print "installed pvcam"
> 
> else:
> 
> print "installed pvcam32"
> 
> else:
> 
> print "installed pvcam64"

In linux  there are shared libraries that could be linked in the runtime.

But for the security concerns this requres the system administrator account 
to install shared libraries.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: readline trick needed

[Chris Angelico]

On Sun, Oct 14, 2012 at 12:44 AM, Etienne Robillard
 wrote:
> Why dont you grow yourself some usable neurons instead ? Don't you realize 
> now stackoverflow.com is starting
> to hurt your capacity to cogitate on your own or have you not realized this 
> yet?

Excuse me?

I'm not overly familiar with readline, so perhaps there is a really
obvious way to do what Steven's trying to do, but this post does not
appear to be the result of a lack of thinking.

If it really IS that obvious to you, post a link to appropriate
documentation without the rudeness... that way it'll be useful to
everyone, not just cathartic to you.

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

Re: readline trick needed

[Etienne Robillard]

On Sun, 14 Oct 2012 00:47:52 +1100
Chris Angelico  wrote:

> Excuse me?
> 
> I'm not overly familiar with readline, so perhaps there is a really
> obvious way to do what Steven's trying to do, but this post does not
> appear to be the result of a lack of thinking.
> 
> If it really IS that obvious to you, post a link to appropriate
> documentation without the rudeness... that way it'll be useful to
> everyone, not just cathartic to you.
> 
> ChrisA
> -- 
> http://mail.python.org/mailman/listinfo/python-list

whatever. i don't feel much like replying to idiots today so your apologies
and useless if not irrelevant. 



-- 
Etienne Robillard
Green Tea Hackers Club
Fine Software Carpentry For The Rest Of Us!
http://gthc.org/
e...@gthcfoundation.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feedback on my python framework I'm building.

[Chris Angelico]

On Sat, Oct 13, 2012 at 3:49 PM,   wrote:
> Basically its a framework that forces the developer(s) to strictly separate 
> the model from the view and controller. You can 'hook up' multiple 
> controllers to a project. The model layer can be completely mocked out so 
> front end designers don't have to bother setting up 
> Postgres/rabbitmq/whatever.

I don't like frameworks that force too much. Actually, I guess that
means I don't like frameworks at all, I like toolsets. Let the
programmer decide what he wants to do.

That said, though, there are times when a good framework can do 90% of
your work for you. The trouble comes when you want to do something the
author didn't think of - you might well end up either fighting against
the system, or modifying the framework to suit your task (and that
works only if you created it yourself). Thin frameworks are usually
immune to this, but on the flip side, they're less likely to be doing
most of your work for you.

It's really easy to demo something and show how awesome it is. How
easily can it be turned to a task it was never built for?

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

Re: Feedback on my python framework I'm building.

[Etienne Robillard]

On Sun, 14 Oct 2012 01:12:30 +1100
Chris Angelico  wrote:

> On Sat, Oct 13, 2012 at 3:49 PM,   wrote:
> > Basically its a framework that forces the developer(s) to strictly separate 
> > the model from the view and controller. You can 'hook up' multiple 
> > controllers to a project. The model layer can be completely mocked out so 
> > front end designers don't have to bother setting up 
> > Postgres/rabbitmq/whatever.
> 
> I don't like frameworks that force too much. Actually, I guess that
> means I don't like frameworks at all, I like toolsets. Let the
> programmer decide what he wants to do.
> 
> That said, though, there are times when a good framework can do 90% of
> your work for you. The trouble comes when you want to do something the
> author didn't think of - you might well end up either fighting against
> the system, or modifying the framework to suit your task (and that
> works only if you created it yourself). Thin frameworks are usually
> immune to this, but on the flip side, they're less likely to be doing
> most of your work for you.
> 
> It's really easy to demo something and show how awesome it is. How
> easily can it be turned to a task it was never built for?

Perhaps we deserve such lame/mediocre web frameworks after all, as Imagination 
is for those who
deserve the freedom to use it properly.

> ChrisA
> -- 
> http://mail.python.org/mailman/listinfo/python-list


-- 
Etienne Robillard
Green Tea Hackers Club
Fine Software Carpentry For The Rest Of Us!
http://gthc.org/
e...@gthcfoundation.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Aggressive language on python-list

[Zero Piraeus]

:

Not sure exactly how to put this ...

I'm a mostly passive subscriber to this list - my posts here over the
years could probably be counted without having to take my socks off -
so perhaps I have no right to comment, but I've noticed a marked
increase in aggressive language here lately, so I'm putting my head
above the parapet to say that I don't appreciate it.

Robust disagreement is one thing [and can be quite enjoyable for those
of us merely spectating], but there's really no need to go around
calling people idiots at the drop of a hat. Quite apart from anything
else, when the contributor you're calling names is as helpful and
knowledgeable a member of the community as some of those targeted have
been, it makes you look a bit daft.

And, yes, I know bringing it up could be construed as stoking the
flames ... but, well, "silence = acquiescence" and all that.

 -[]z.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Aggressive language on python-list

[Etienne Robillard]

On Sat, 13 Oct 2012 11:21:28 -0400
Zero Piraeus  wrote:

> :
> 
> Not sure exactly how to put this ...
> 
> I'm a mostly passive subscriber to this list - my posts here over the
> years could probably be counted without having to take my socks off -
> so perhaps I have no right to comment, but I've noticed a marked
> increase in aggressive language here lately, so I'm putting my head
> above the parapet to say that I don't appreciate it.
> 
> Robust disagreement is one thing [and can be quite enjoyable for those
> of us merely spectating], but there's really no need to go around
> calling people idiots at the drop of a hat. Quite apart from anything
> else, when the contributor you're calling names is as helpful and
> knowledgeable a member of the community as some of those targeted have
> been, it makes you look a bit daft.
> 
> And, yes, I know bringing it up could be construed as stoking the
> flames ... but, well, "silence = acquiescence" and all that.
> 
>  -[]z.
> -- 
> http://mail.python.org/mailman/listinfo/python-list

OT. you obviously has no clue what agressive behavior mean. :-)

So please continue with the passive tone saying nothing relevant 
and login to facebook.


-- 
Etienne Robillard
Green Tea Hackers Club
Fine Software Carpentry For The Rest Of Us!
http://gthc.org/
e...@gthcfoundation.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feedback on my python framework I'm building.

[nbvfour]

On Saturday, October 13, 2012 10:13:22 AM UTC-4, Chris Angelico wrote:
> On Sat, Oct 13, 2012 at 3:49 PM,   wrote:
> 
> > Basically its a framework that forces the developer(s) to strictly separate 
> > the model from the view and controller. You can 'hook up' multiple 
> > controllers to a project. The model layer can be completely mocked out so 
> > front end designers don't have to bother setting up 
> > Postgres/rabbitmq/whatever.
> 
> 
> 
> I don't like frameworks that force too much. Actually, I guess that
> 
> means I don't like frameworks at all, I like toolsets. Let the
> 
> programmer decide what he wants to do.
> 
> 
> 
> That said, though, there are times when a good framework can do 90% of
> 
> your work for you. The trouble comes when you want to do something the
> 
> author didn't think of - you might well end up either fighting against
> 
> the system, or modifying the framework to suit your task (and that
> 
> works only if you created it yourself). Thin frameworks are usually
> 
> immune to this, but on the flip side, they're less likely to be doing
> 
> most of your work for you.
> 
> 
> 
> It's really easy to demo something and show how awesome it is. How
> 
> easily can it be turned to a task it was never built for?
> 
> 
> 
> ChrisA

Do you have an example of a task that giotto can't handle that other frameworks 
can? One of my goals is to have this framework "turing complete" in the sense 
that everything that other frameworks can do, giotto should be able to do. I 
think my controller -> input_middleware -> model -> cache -> view -> 
output_middleware pattern pretty much allows for anything. Throughout the 
development process, I've radically changed the API many times when it was 
discovered that a certain task would be very hard (for instance authentication)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feedback on my python framework I'm building.

[Etienne Robillard]

On Sat, 13 Oct 2012 08:57:47 -0700 (PDT)
nbvf...@gmail.com wrote:


> Do you have an example of a task that giotto can't handle that other 
> frameworks can? One of my goals is to have this framework "turing complete" 
> in the sense that everything that other frameworks can do, giotto should be 
> able to do. I think my controller -> input_middleware -> model -> cache -> 
> view -> output_middleware pattern pretty much allows for anything. Throughout 
> the development process, I've radically changed the API many times when it 
> was discovered that a certain task would be very hard (for instance 
> authentication)
> -- 
> http://mail.python.org/mailman/listinfo/python-list

how about eliminating poverty and employment discrimination?

Or can your script prevent childs to kill themselves on facebook?

let me know!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Aggressive language on python-list

[Joshua Landau]

On 13 October 2012 16:21, Zero Piraeus  wrote:

> :
>
> Not sure exactly how to put this ...
>
> I'm a mostly passive subscriber to this list - my posts here over the
> years could probably be counted without having to take my socks off -
> so perhaps I have no right to comment, but I've noticed a marked
> increase in aggressive language here lately, so I'm putting my head
> above the parapet to say that I don't appreciate it.
>
> Robust disagreement is one thing [and can be quite enjoyable for those
> of us merely spectating], but there's really no need to go around
> calling people idiots at the drop of a hat. Quite apart from anything
> else, when the contributor you're calling names is as helpful and
> knowledgeable a member of the community as some of those targeted have
> been, it makes you look a bit daft.
>
> And, yes, I know bringing it up could be construed as stoking the
> flames ... but, well, "silence = acquiescence" and all that.
>

I was going to passively agree to this, but Etienne's obvious trolling
impulsed me to state that I do.

I can't say I'm free from blame, but I feel we have had a bit more name
calling and internet-punching than usual, but I also have a trust in this
list in that whenever it's gotten bad before we've always calmed down.

Plus, aside from 8*, we have a lot of brains on this list, so we really
shouldn't be calling *anyone* "idiots".

* Then again, 8 is pretty bright for a bot.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to use "while" within the command in -c option of python?

[Joshua Landau]

On 13 October 2012 10:03, Chris Angelico  wrote:

> On Sat, Oct 13, 2012 at 7:41 PM, Thomas Bach
>  wrote:
> > On Sat, Oct 13, 2012 at 12:32:41AM +, Steven D'Aprano wrote:
> >>
> >>  He gets SyntaxError because you can't follow a semicolon with a
> >> statement that begins a block.
> >
> > Can someone provide a link on where to find this type of information?
> > I was just hunting through “The Python Language Reference” and could
> > not find anything explicit. The only thing I found is
> >
> > http://docs.python.org/reference/simple_stmts.html
> >
> > “Several simple statements may occur on a single line separated by
> > semicolons.”
> >
> > Anyways, this does not explicitly say “You shall not put a compound
> > statement after a simple statement separated by a semicolon.”, right?
>
> It's more that Python treats simple and compound statements as
> completely separate beasts. You can combine simple statements on one
> line, but compound statements mustn't be.
>
> In my opinion, this is a major wart in Python syntax. You can argue
> all you like about how it reduces code clarity to put these sorts of
> things together, but that's a job for a style guide, NOT a language
> requirement. Most code won't put an assignment followed by an
> if/while/for, but when I'm working interactively, I often want to
> recall an entire statement to edit and reuse, complete with its
> initialization - something like (contrived example):
>
> >>> a=collections.defaultdict(int)
> >>> for x in open("RilvierRex.txt"): a[x]+=1
>
> Then I keep doing stuff, keep doing stuff, and then come back to this
> pair of lines. Since they're two lines, I have to recall them as two
> separate entities, rather than as an initializer and the code that
> uses it. Logically, they go together. Logically, they're on par with a
> list comprehension, which initializes, loops, and assigns, all as a
> single statement. But syntactically, they're two statements that have
> to go on separate lines.
>
> To force that sort of thing to be a single recallable statement, I can
> do stupid tricks like:
>
> >>> if True:
> a=collections.defaultdict(int)
> for x in open("RilvierRex.txt"): a[x]+=1
>
> but that only works in IDLE, not in command-line interactive Python.
>
> Note, by the way, that it's fine to put the statement _inside_ the for
> on the same line. It's even legal to have multiple such statements:
>
> >>> for x in (1,2,3): print(x); print(x);
> 1
> 1
> 2
> 2
> 3
> 3
>
> If there's any ambiguity, it would surely be that, and not the simple
> statement being first.
>
> Okay, rant over. I'll go back to being nice now. :)


This here isn't a flaw in Python, though. It's a flaw in the command-line
interpreter. By putting it all on one line, you are effectively saying:
"group these". Which is the same as an "if True:" block, and some things
like Reinteract even supply a grouping block like "build".

That said, because some shells suck it would be nice if:

> python -c "a=1\nif a:print(a)"

worked (just for -c).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feedback on my python framework I'm building.

[Chris Angelico]

On Sun, Oct 14, 2012 at 2:57 AM,   wrote:
> Do you have an example of a task that giotto can't handle that other 
> frameworks can? One of my goals is to have this framework "turing complete" 
> in the sense that everything that other frameworks can do, giotto should be 
> able to do. I think my controller -> input_middleware -> model -> cache -> 
> view -> output_middleware pattern pretty much allows for anything.

No, I don't, because I haven't tried to use it. But allow me to give
two examples, one on each side of the argument.

The 'tee' utility is primarily for writing a pipe to disk AND to
further pipelining, for instance:

./grind | tee grind.log | egrep '(2012|tps|@)'

It'll show me, in real-time, the lines that are of interest to me, but
it also writes the whole log to disk. But tee can be used in a quite
different way:

echo "Hello, world!" | sudo tee /some/file/owned/by/root

Unix is full of utilities of this nature. They each do one thing and
do it well, so when someone wants to use them in unusual ways, the
tools perform as expected.

On the contrary, Magic: The Gathering Online is designed for one
purpose: human interaction. There are a number of bot accounts that
function as shopkeepers, but their owners have to either use GUI level
monitoring and automation facilities, or hack the existing client
brutally. These people are trying to use an application in a way that
it wasn't designed to do, and no matter how reasonable the goal is,
the program just isn't built with toolchaining in mind.

> Throughout the development process, I've radically changed the API many times 
> when it was discovered that a certain task would be very hard (for instance 
> authentication)

This is, in my opinion, not a good thing. If you have to change your
API radically to support something you just thought of, then something
you still haven't thought of may require another radical API change.
That's not too bad if it's a personal system that you don't share with
anyone (though even then, you have to consider whether you'll be
spending more time fiddling with the framework than actually getting
stuff done), but is potentially disastrous in something you publish -
you can't afford to break everyone else's code, which means that
you'll be unable to support things you didn't think of.

The only way to support *absolutely everything* is to do nothing - to
be a framework so thin you're invisible. (That's not to say you're
useless; there are bridge modules that do exactly this - ctypes can
call on any library function from Python; it must therefore abstract
away nothing. But that's a very specific sort of case.) Anything else
must by nature make some things easier and some things harder.

The easiest way to avoid making things very much harder is to have a
way to ignore the framework - in the same way that most file
compression formats have a way to mark data as having not been
compressed (PKZip uses the term "Stored" rather than, eg, "Deflated").
 This is why I say it's likely not a good thing that your framework
*forces* the separation of model/view/controller. You make it
impossible to temporarily ignore the framework. I haven't tested your
specific case, but what I've seen happen in similar situations is a
ridiculous set of "pass-through" methods or parameters, getting sent
up the line and back down the line, carrying opaque information that
really ought to have been manipulated at a different level in the
chain. I can't show you demo code as I don't own copyright on it, but
the git repository at work has, shall we say, a certain amount of
TheDailyWTF-level code in it...

But please don't take this post as _entirely_ doom and gloom. For a
number of reasons, I do not want to start coding within your
framework; but I would recommend that you DO (continue to) do so.
You'll learn a lot about what you do and don't like, and that's a good
thing. You'll quite possibly end up building something that saves you
a heap of time, and that's also a good thing. And at very worst, it'll
be an exploration. All programmers benefit from writing more code :)
But so long as you keep it personal, you're free to change it around
completely every time you need to. Keep that flexibility and you won't
feel constrained.

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

Re: How to use "while" within the command in -c option of python?

[Chris Angelico]

On Sun, Oct 14, 2012 at 3:38 AM, Joshua Landau
 wrote:
> This here isn't a flaw in Python, though. It's a flaw in the command-line
> interpreter. By putting it all on one line, you are effectively saying:
> "group these". Which is the same as an "if True:" block, and some things
> like Reinteract even supply a grouping block like "build".
>
> That said, because some shells suck it would be nice if:
>>
>> python -c "a=1\nif a:print(a)"
>
> worked (just for -c).

Yes, that'd be nice. But it still leaves the big question of why
Python requires \n to separate one statement from another. It IS a
flaw in Python that it requires one specific statement separator in
this instance, even though it'll accept two in another instance.

Here's a side challenge. In any shell you like, start with this
failing statement, and then fix it without retyping anything:

sikorsky@sikorsky:~$ python -c "a=1; if a: print(a)"
  File "", line 1
a=1; if a: print(a)
  ^
SyntaxError: invalid syntax

In bash, I was unable to insert a newline into the quoted string. My
only option was to backspace everything after the point where I wanted
the newline, then hit enter, then retype the if. I'm curious to know
if that's simply because I didn't think of (some bash feature), or
alternatively, if there's another shell that would have made this
easy.

Back to the main point. In C-like languages, the newline is nothing
special. (ECMAScript allows the omission of semicolons at end of line
in many cases, but many style guides recommend using them anyway.) You
can, if you so desire, put all your code into a single line. It's then
up to the project's style guide to decide how things should be laid
out. For instance, this is multiple statements in PHP, but I see it as
one logical action:

$bar=array(); for ($foo as $k=>$v) $bar[$k]="".$v."";

It's one statement in Python:

bar = [""+x+"" for x in foo]

It's one statement in Pike:

array bar = map(foo,lambda(string x) {return ""+x+"";});

So it should be allowed to be put on one line. And in languages whose
syntax derives from C, you almost certainly can. (I can't think of any
counter-examples, though that certainly doesn't prove they don't
exist.) But the same thing is forced onto two lines in Python, and not
for syntactic reasons - at least, not that I can see. Perhaps someone
can enlighten me.

Is there any fundamental reason that the syntax couldn't be expanded
to permit "statement; statement" for any two given statements?

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

Re: Aggressive language on python-list

[Chris Angelico]

On Sun, Oct 14, 2012 at 2:21 AM, Zero Piraeus  wrote:
> I'm a mostly passive subscriber to this list - my posts here over the
> years could probably be counted without having to take my socks off -
> so perhaps I have no right to comment, but I've noticed a marked
> increase in aggressive language here lately, so I'm putting my head
> above the parapet to say that I don't appreciate it.

Thanks for speaking up, Zero. I agree that the aggressive language
lately has been a bit of a problem; but it's not incurable, and Dwight
Hutto seems to have recovered a more affable stance in his more recent
posts. (Thank you, Dwight/David.)

Etienne, we shall not trouble you for a demonstration of what you
think *real* aggressive behaviour is. Really, you've already given us
far more than the five-minute argument we paid for; though I suppose
you could be arguing on your own time. But I'm sure if you go to the
next room, you'll find "being dropped into the killfille lessons".
Better, better, but "Plonk". Hold your username here...

Wait, is that the wrong Python for this list? Oops. So confusing.

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

Re: How to use "while" within the command in -c option of python?

[Jussi Piitulainen]

Chris Angelico writes:

> Here's a side challenge. In any shell you like, start with this
> failing statement, and then fix it without retyping anything:
> 
> sikorsky@sikorsky:~$ python -c "a=1; if a: print(a)"
>   File "", line 1
> a=1; if a: print(a)
>   ^
> SyntaxError: invalid syntax
> 
> In bash, I was unable to insert a newline into the quoted string. My
> only option was to backspace everything after the point where I
> wanted the newline, then hit enter, then retype the if. I'm curious
> to know if that's simply because I didn't think of (some bash
> feature), or alternatively, if there's another shell that would have
> made this easy.

C-v C-j inserts a newline for me, in bash.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to use "while" within the command in -c option of python?

[Chris Angelico]

On Sun, Oct 14, 2012 at 4:43 AM, Jussi Piitulainen
 wrote:
> Chris Angelico writes:
>
>> Here's a side challenge. In any shell you like, start with this
>> failing statement, and then fix it without retyping anything:
>>
>> sikorsky@sikorsky:~$ python -c "a=1; if a: print(a)"
>
> C-v C-j inserts a newline for me, in bash.

Ah! So it does. Thanks.

*stashes that away in the "handy commands" index in his brain*

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

Re: Where are documentation for Gnome

[Kwpolska]

On Sat, Oct 13, 2012 at 7:50 PM, Santosh Kumar  wrote:
> Where are the documentation for Gnome's EOG? I want to develop a
> plugin in Python.
>
> On 10/13/12, Santosh Kumar  wrote:
>>
>>
> --
> http://mail.python.org/mailman/listinfo/python-list

https://live.gnome.org/EyeOfGnome/Plugins#Python

That is all the documentation in existence for Python plugins.

Examples:
http://git.gnome.org/browse/eog-plugins/tree/plugins/slideshowshuffle
http://git.gnome.org/browse/eog-plugins/tree/plugins/pythonconsole

The C code may be of use:

http://ftp.acc.umu.se/pub/GNOME/sources/eog/3.6/eog-3.6.0.tar.xz

Have fun— oh wait.  You can’t, because PyGTK is an unreadable mess.
And you are working with undocumented stuff.

-- 
Kwpolska 
stop html mail  | always bottom-post
www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
GPG KEY: 5EAAEA16
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feedback on my python framework I'm building.

[nbvfour]

On Saturday, October 13, 2012 12:48:23 PM UTC-4, Chris Angelico wrote:
> No, I don't, because I haven't tried to use it. But allow me to give
> two examples, one on each side of the argument.
> 
> The 'tee' utility is primarily for writing a pipe to disk AND to
> further pipelining, for instance:

Could you please spent 10 minutes to read through the tutorial? The 'tee' unix 
utility and ctypes describes the way giotto goes about it business very well. 
Traditional web frameworks (such as django and rails) are too much of a 'magic 
the gathering' for my taste, which is why I'm writing giotto.

I'm really not looking for general "why I hate frameworks" criticism. I'm 
looking for specific criticism of the framework that I am writing.

> This is, in my opinion, not a good thing. If you have to change your
> API radically to support something you just thought of, then something
> you still haven't thought of may require another radical API change.

Not all api's get it right on the first shot. I'm more interested in getting it 
right, rather than patching together a bunch of random 'fixes' ala PHP.

> The only way to support *absolutely everything* is to do nothing - to
> be a framework so thin you're invisible. (That's not to say you're

You just described what Giotto is trying to do, since Giotto doesn't touch the 
model at all.

>  This is why I say it's likely not a good thing that your framework
> *forces* the separation of model/view/controller. You make it
> impossible to temporarily ignore the framework.

Exactly. When you 'break out of the framework' you pile on technical debt. I 
want to force developers to not do that.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to use "while" within the command in -c option of python?

[Joshua Landau]

On 13 October 2012 18:23, Chris Angelico  wrote:

> On Sun, Oct 14, 2012 at 3:38 AM, Joshua Landau
>  wrote:
> > This here isn't a flaw in Python, though. It's a flaw in the command-line
> > interpreter. By putting it all on one line, you are effectively saying:
> > "group these". Which is the same as an "if True:" block, and some things
> > like Reinteract even supply a grouping block like "build".
> >
> > That said, because some shells suck it would be nice if:
> >>
> >> python -c "a=1\nif a:print(a)"
> >
> > worked (just for -c).
>
> Yes, that'd be nice. But it still leaves the big question of why
> Python requires \n to separate one statement from another. It IS a
> flaw in Python that it requires one specific statement separator in
> this instance, even though it'll accept two in another instance.
>

Not really. The two things are fundamentally different. Yes, it's hard to
think of another example, but they aren't the same. ";" means "implicit
newline to the *same indentation*", whereas a newline does not.


> Here's a side challenge. In any shell you like, start with this
> failing statement, and then fix it without retyping anything:
>
> sikorsky@sikorsky:~$ python -c "a=1; if a: print(a)"
>   File "", line 1
> a=1; if a: print(a)
>   ^
> SyntaxError: invalid syntax
>
> In bash, I was unable to insert a newline into the quoted string. My
> only option was to backspace everything after the point where I wanted
> the newline, then hit enter, then retype the if. I'm curious to know
> if that's simply because I didn't think of (some bash feature), or
> alternatively, if there's another shell that would have made this
> easy.
>

I have to thank Jussi Piitulainen for the command here, I'm likely gonna'
use that quite a bit.


> Back to the main point. In C-like languages, the newline is nothing
> special. (ECMAScript allows the omission of semicolons at end of line
> in many cases, but many style guides recommend using them anyway.) You
> can, if you so desire, put all your code into a single line. It's then
> up to the project's style guide to decide how things should be laid
> out. For instance, this is multiple statements in PHP, but I see it as
> one logical action:
>
> $bar=array(); for ($foo as $k=>$v) $bar[$k]="".$v."";
>
> It's one statement in Python:
>
> bar = [""+x+"" for x in foo]
>
> It's one statement in Pike:
>
> array bar = map(foo,lambda(string x) {return ""+x+"";});
>
> So it should be allowed to be put on one line


Your argument goes:
FACT 1: You can do this in one statement, in one line.
FACT 2: In other languages you can do this in two statements, in one line
CONCULSION: You should be able to do this in two statements, in one line

Which I don't agree with. I understand that it is one *logical action*, but
so is multiplying a matrix. We have functions to *wrap* logical actions
that are composed of multiple logical actions.

The problem is that Python uses indentation. That's fundamentally the
problem.


> And in languages whose
> syntax derives from C, you almost certainly can. (I can't think of any
> counter-examples, though that certainly doesn't prove they don't
> exist.) But the same thing is forced onto two lines in Python, and not
> for syntactic reasons - at least, not that I can see. Perhaps someone
> can enlighten me.
>
> Is there any fundamental reason that the syntax couldn't be expanded
> to permit "statement; statement" for any two given statements?
>

Because Python uses indentation, what would "if A: print(1); if B:
print(2)" even do? It *has* to fail, because we have to assume consistent
indentation for ";"s*. With "\n" as I proposed, you still have to indent:
it is just a method to bypass lame shells [it would become "if A:
print(1)\nif B: print(2)"].

Blocks that avoid this have been done to death with multi-line lambdas, and
the majority of people don't like them. I'm sway-able, but it's not going
to happen because Guido and most of the peeps with power aren't. Anything
that challenges the standard now is dead from the start.

* You *could* have some rules that govern ambiguities well, but none that I
can think of would be *both* backward-compatible *and* complete. If it's
incomplete we've just moved the goalpost.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feedback on my python framework I'm building.

[Chris Angelico]

On Sun, Oct 14, 2012 at 5:18 AM,   wrote:
> On Saturday, October 13, 2012 12:48:23 PM UTC-4, Chris Angelico wrote:
>> No, I don't, because I haven't tried to use it. But allow me to give
>> two examples, one on each side of the argument.
>>
>> The 'tee' utility is primarily for writing a pipe to disk AND to
>> further pipelining, for instance:
>
> Could you please spent 10 minutes to read through the tutorial?

A fair criticism, and I am duly chastised. Okay. Now reading through
your web site... alright, I'm back.

>>  This is why I say it's likely not a good thing that your framework
>> *forces* the separation of model/view/controller. You make it
>> impossible to temporarily ignore the framework.
>
> Exactly. When you 'break out of the framework' you pile on technical debt. I 
> want to force developers to not do that.

Philosophy point 2: Giotto does force users to do things the “Giotto
way”. In other words, convention over configuration

Nice theory, but this is the bit that I fundamentally disagree with.
Forcing programmers to work in one particular style is usually not the
job of the language/framework/library. That should be up to the
programmer, or at least the local style guide. I do like your plan of
having identical interfaces to the same functionality (your example of
web-based and command-line is particularly appealing to my personal
tastes), but the same can usually be achieved with a well-built
library. In fact, all you need to do is have your model as a simple
Python module, and then the view and controller call on its functions.

What does your framework offer over a basic system like that?

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

Re: How to use "while" within the command in -c option of python?

[Chris Angelico]

On Sun, Oct 14, 2012 at 5:21 AM, Joshua Landau
 wrote:
> Because Python uses indentation, what would "if A: print(1); if B: print(2)"
> even do? It has to fail, because we have to assume consistent indentation
> for ";"s*. With "\n" as I proposed, you still have to indent: it is just a
> method to bypass lame shells [it would become "if A: print(1)\nif B:
> print(2)"].

sikorsky@sikorsky:~/cpython$ python -c "if False: print(1); print(2)"
sikorsky@sikorsky:~/cpython$ python -c "if True: print(1); print(2)"
1
2
sikorsky@sikorsky:~/cpython$

The semicolon separates statements, but doesn't change nesting levels.
The if statement increases the nesting level, which demands a
corresponding indentation increase if you go onto a new line; the
statement you describe is illegal because the 'if' isn't allowed to
not be at the beginning of the line, but it's unambiguous.

Of course, since Python lacks a non-whitespace way of indicating the
end of an if block, there's no way to put your "if A" and "if B" onto
the same line as peers. But that's a consequence of a design decision,
and one that can't easily be changed. Every language has warts like
that; eschewing variable declarations prevents infinite nesting of
scopes, but demanding variable declarations makes interactive work
harder. To paraphrase the Pirate King: Always follow the dictates of
your conscience, and accept the consequences.

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

Understanding http proxies

[Olive]

I am trying to understand how to build an http proxy server in python,
and I have found the following example:

http://www.oki-osk.jp/esc/python/proxy/

But I do not have found an exact description of what exactly a proxy
server is suppose to do (all references gice only the basic principe of
proxy that I know). In the following model

Client <-> Proxy <-> Server

it seems when I read the code above that the proxy acts mostly as an
orinary server with respect to the client except that it is supposed to
receive the full URL instead of just the path. Am I right? Is there any
documentation on what an http proxy is supposed to implement.

Olive
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Understanding http proxies

[Chris Angelico]

On Sun, Oct 14, 2012 at 5:43 AM, Olive  wrote:
> it seems when I read the code above that the proxy acts mostly as an
> orinary server with respect to the client except that it is supposed to
> receive the full URL instead of just the path. Am I right? Is there any
> documentation on what an http proxy is supposed to implement.

The easiest way to test this is to knock together a quick little
server, set your browser to use localhost as a proxy, and see what
requests you get.

You're correct as regards most requests, but HTTPS is more
complicated. All your proxy will see is a CONNECT request; you have to
accept or deny on the basis of address alone, you don't get the whole
URL (for obvious reasons). But that aside, yes, you'll normally get a
request that looks pretty similar to what the origin server would get.

ahh, happy memories of MUDding through a local proxy that permitted
CONNECT on more ports than 443... and even happier memories of getting
port 23 opened to direct access, hehe...

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

Re: How to use "while" within the command in -c option of python?

[Joshua Landau]

On 13 October 2012 19:41, Chris Angelico  wrote:

> On Sun, Oct 14, 2012 at 5:21 AM, Joshua Landau
>  wrote:
> > Because Python uses indentation, what would "if A: print(1); if B:
> print(2)"
> > even do? It has to fail, because we have to assume consistent indentation
> > for ";"s*. With "\n" as I proposed, you still have to indent: it is just
> a
> > method to bypass lame shells [it would become "if A: print(1)\nif B:
> > print(2)"].
>
> sikorsky@sikorsky:~/cpython$ python -c "if False: print(1); print(2)"
> sikorsky@sikorsky:~/cpython$ python -c "if True: print(1); print(2)"
> 1
> 2
> sikorsky@sikorsky:~/cpython$
>
> The semicolon separates statements, but doesn't change nesting levels.
> The if statement increases the nesting level, which demands a
> corresponding indentation increase if you go onto a new line; the
> statement you describe is illegal because the 'if' isn't allowed to
> not be at the beginning of the line, but it's unambiguous.
>
> Of course, since Python lacks a non-whitespace way of indicating the
> end of an if block, there's no way to put your "if A" and "if B" onto
> the same line as peers. But that's a consequence of a design decision,
> and one that can't easily be changed. Every language has warts like
> that; eschewing variable declarations prevents infinite nesting of
> scopes, but demanding variable declarations makes interactive work
> harder. To paraphrase the Pirate King: Always follow the dictates of
> your conscience, and accept the consequences.
>

I get what you're saying, but I think my point is largely unchanged.

When I said  "*You could have some rules that govern ambiguities well, but
none that I can think of would be both backward-compatible and complete. If
it's incomplete we've just moved the goalpost*." I was referring to exactly
this (and a couple of other options). By allowing these we're just adding a
confusing way of introducing layers - we've still got a whole lot of syntax
we can't write in a single line.

The fact that your proposal can't allow "a=[]\nfor x in range(10):
a.append(x**a[-2])\nprint(a)" makes it somewhat an incomplete suggestion,
and code like:

while True: while True: break; break


is just confusing.

I don't want to sound closed, but the options I'm really open to are:

a) It does a limited set of things that make a those things nicer, á la "@"
b) It does *almost* everything, minus some carefully-chosen things deemed
to quirky, á la current newlines (which don't allow "if a: if b: pass")
c) It does everything that would be possible

Your example falls nicely between *a* and *b*, which I do not find
particularly helpful. Mine attempts *a* by only applying to "python -c",
but would be *c* if it didn't. I find the syntax to horrible for general
code, which is why I didn't suggest that.

Hopefully you see what I have against this suggestion, but also that I
agree there is a problem and that there may well be a good way to fix it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is `wsample` a proper name for a function like this?

[Joshua Landau]

On 12 October 2012 03:22, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:

> On Wed, 10 Oct 2012 23:44:42 -0700, suzaku wrote:
>
> > I think if a programmer has used the built-in `random` module before, he
> > would expect a function with "sample" in its name to return a population
> > sequence.
>
> I have used the random module for about fifteen years, and I still write
> random.sample when I need to use random.choice.
>
> In statistics, probability, and plain English, a sample can be a single
> item: that's why we can say "a sample" or "two samples".


Because I have no soul, I'm going to have to correct you here. We can write
"a multitude" or "several multitudes", but that doesn't mean a multitude
can contain but one item. It's singular because we have *one collection*,
not *one item*. That said, we can still have a sample *of one*. And *samples
* of one.

*teehee*


> > If a function is to return scalar value instead of sequence, I would
> > expect it to be named "choice".
>
> And I wouldn't. But what do I care? I'm never going to use the code
> you're talking about, so call it "sasquatch" if you like, it's no skin
> off my nose.
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: readline trick needed

[Roel Schroeven]

Etienne Robillard schreef:

On Sun, 14 Oct 2012 00:47:52 +1100
Chris Angelico  wrote:


Excuse me?

I'm not overly familiar with readline, so perhaps there is a really
obvious way to do what Steven's trying to do, but this post does not
appear to be the result of a lack of thinking.

If it really IS that obvious to you, post a link to appropriate
documentation without the rudeness... that way it'll be useful to
everyone, not just cathartic to you.

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


whatever. i don't feel much like replying to idiots today


Then simply don't. Much better then replying in such a rude way.

I leave the question of who is being an idiot here as an exercise to the 
reader.


--
"Too often we hold fast to the cliches of our forebears. We subject all
facts to a prefabricated set of interpretations. Too often we enjoy the
comfort of opinion without the discomfort of thought."
-- John F Kennedy

r...@roelschroeven.net

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

Re: Aggressive language on python-list

[Roel Schroeven]

Zero Piraeus schreef:

:

Not sure exactly how to put this ...

I'm a mostly passive subscriber to this list - my posts here over the
years could probably be counted without having to take my socks off -
so perhaps I have no right to comment, but I've noticed a marked
increase in aggressive language here lately, so I'm putting my head
above the parapet to say that I don't appreciate it.


Same here. I've been lurking here for a number of years, and I've always 
regarded this list as an example of friendly civilized behavior, quite 
exceptional on the Internet. I also have the impression that situation 
is changing for the worse, and it worries me too.


--
"Too often we hold fast to the cliches of our forebears. We subject all
facts to a prefabricated set of interpretations. Too often we enjoy the
comfort of opinion without the discomfort of thought."
-- John F Kennedy

r...@roelschroeven.net

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

Re: readline trick needed

[Joshua Landau]

On 13 October 2012 22:14, Roel Schroeven  wrote:

> Etienne Robillard schreef:
>
>  On Sun, 14 Oct 2012 00:47:52 +1100
>> Chris Angelico  wrote:
>>
>>  Excuse me?
>>>
>>> I'm not overly familiar with readline, so perhaps there is a really
>>> obvious way to do what Steven's trying to do, but this post does not
>>> appear to be the result of a lack of thinking.
>>>
>>> If it really IS that obvious to you, post a link to appropriate
>>> documentation without the rudeness... that way it'll be useful to
>>> everyone, not just cathartic to you.
>>>
>>> ChrisA
>>> --
>>> http://mail.python.org/**mailman/listinfo/python-list
>>>
>>
>> whatever. i don't feel much like replying to idiots today
>>
>
> Then simply don't. Much better then replying in such a rude way.
>
> I leave the question of who is being an idiot here as an exercise to the
> reader.


I've not seen Etienne Robillard much before, so I think he's relatively
new. He appeared first, I think, two months ago with one post about how
"english" a word was, and then last month and this he'd done nothing but
try and weasel money from people and offend them.

*We just need to ignore him and warn newcomers*, similarly to how we deal
with 8 Dihedral (a bot, btw).

So, yes, that's a purposeful troll.

Note, Etienne Robillard, that if you reply to me I will not respond. That
applies to more than this thread. I hope others do the same, and that
newcomers *are* warned.

With two irritants (including 8), is it not advisable that python-list
gets an admin to block these accounts? Even if it does nothing more than
slow them, that's something.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Aggressive language on python-list

[Tim Delaney]

On 14 October 2012 08:22, Roel Schroeven  wrote:

> Zero Piraeus schreef:
>
>  :
>>
>> Not sure exactly how to put this ...
>>
>> I'm a mostly passive subscriber to this list - my posts here over the
>> years could probably be counted without having to take my socks off -
>> so perhaps I have no right to comment, but I've noticed a marked
>> increase in aggressive language here lately, so I'm putting my head
>> above the parapet to say that I don't appreciate it.
>>
>
> Same here. I've been lurking here for a number of years, and I've always
> regarded this list as an example of friendly civilized behavior, quite
> exceptional on the Internet. I also have the impression that situation is
> changing for the worse, and it worries me too.


If everyone *plonks* the jerks/trolls/bots/etc and no one responds to them,
they won't have an audience and will either go away; act out more (but no
one will see it); or reform and become a useful member of the group
(probably needing to change email addresses to be un-*plonked*).

The problem is mainly when people respond to them. That's what they want -
it gives them an audience. No matter how much you want to *just this once*
respond to one, resist the urge. And if you can't prevent yourself from
replying to someone who has quoted one in order to tell them that the
person is a known troll/bot, tell them privately, not on the list.

Cheers,

Tim Delaney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to use "while" within the command in -c option of python?

[Chris Angelico]

On Sun, Oct 14, 2012 at 6:06 AM, Joshua Landau
 wrote:
> The fact that your proposal can't allow "a=[]\nfor x in range(10):
> a.append(x**a[-2])\nprint(a)" makes it somewhat an incomplete suggestion,
> and code like:
>
>> while True: while True: break; break
>
> is just confusing.

Agreed. However, I don't think there's going to be _any_ perfect
solution for delimiting blocks, short of "from __future__ import
braces".

> I don't want to sound closed, but the options I'm really open to are:
>
> a) It does a limited set of things that make a those things nicer, á la "@"
> b) It does almost everything, minus some carefully-chosen things deemed to
> quirky, á la current newlines (which don't allow "if a: if b: pass")
> c) It does everything that would be possible
>
> Your example falls nicely between a and b, which I do not find particularly
> helpful. Mine attempts a by only applying to "python -c", but would be c if
> it didn't. I find the syntax to horrible for general code, which is why I
> didn't suggest that.
>

Your idea is an extension to the -c parameter that would technically
work, but be fairly hard to manage in anything other than the trivial
case. My idea is an extension to general syntax that would work in all
cases where you aren't trying to put a statement after the end of what
would be an indented block. Both have their limitations, but both
would be - as far as I can see - backward compatible.

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

Re: readline trick needed

[Chris Angelico]

On Sun, Oct 14, 2012 at 8:31 AM, Joshua Landau
 wrote:
> With two irritants (including 8), is it not advisable that python-list
> gets an admin to block these accounts? Even if it does nothing more than
> slow them, that's something.

That's what killfiles are for. You have two options:

http://en.wikipedia.org/wiki/Kill_file
http://bofh.ch/bofh/bsmh2.html

The first option is not perfect, as you'll still see replies that
quote such people's posts. The second has a few issues with local law
enforcement, but other than that, is a very effective means of
avoiding seeing their posts.

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

Re: How to use "while" within the command in -c option of python?

[Joshua Landau]

On 13 October 2012 22:39, Chris Angelico  wrote:

> On Sun, Oct 14, 2012 at 6:06 AM, Joshua Landau
>  wrote:
> > The fact that your proposal can't allow "a=[]\nfor x in range(10):
> > a.append(x**a[-2])\nprint(a)" makes it somewhat an incomplete suggestion,
> > and code like:
> >
> >> while True: while True: break; break
> >
> > is just confusing.
>
> Agreed. However, I don't think there's going to be _any_ perfect
> solution for delimiting blocks, short of "from __future__ import
> braces".


I don't know. I don't personally think of it as much of a problem, as the
only time this will ever really cause trouble is:
a) You can't enter newlines easily
b) It's a hassle to keep track of indentation

These only really apply to a few things.


>  > I don't want to sound closed, but the options I'm really open to are:
> >
> > a) It does a limited set of things that make a those things nicer, á la
> "@"
> > b) It does almost everything, minus some carefully-chosen things deemed
> to
> > quirky, á la current newlines (which don't allow "if a: if b: pass")
> > c) It does everything that would be possible
> >
> > Your example falls nicely between a and b, which I do not find
> particularly
> > helpful. Mine attempts a by only applying to "python -c", but would be c
> if
> > it didn't. I find the syntax to horrible for general code, which is why I
> > didn't suggest that.
> >
>
> Your idea is an extension to the -c parameter that would technically
> work, but be fairly hard to manage in anything other than the trivial
> case. My idea is an extension to general syntax that would work in all
> cases where you aren't trying to put a statement after the end of what
> would be an indented block. Both have their limitations, but both
> would be - as far as I can see - backward compatible.


Since you seem to want to solve the general case (I was under the
assumption that we were still only talking in the context of the OP) I have
an idea.

There could be a Python module that reads a file like this:

> if a: ${ print(1) $ print(2) $ while b: c() $ if g: ${ pass }$ }$ print(d)

and transforms it to the valid Python:
>
> if a:
> print(1)
> print(2)
> while b: c()
> if g:
> pass
> print(d)


That is *also* callable from the command-line like so:

> python -m debrace -c "if a: ${ print(1) $ print(2) $ while b: c() $ if g:
> ${ pass }$ }$ print(d)"


This should solve both *a* and *b* above, and it would make life easier for
scripters. It's also easy to mock up, and from then we only need it in the
stdlib.

~~~
"${" means INDENT
"}$" means DEDENT
"$" means NEWLINE (similar to ";")
*"$" has a lower precedence than "${" or "}$"*
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to use "while" within the command in -c option of python?

[Chris Angelico]

On Sun, Oct 14, 2012 at 9:00 AM, Joshua Landau
 wrote:
> That is also callable from the command-line like so:
>>
>> python -m debrace -c "if a: ${ print(1) $ print(2) $ while b: c() $ if g:
>> ${ pass }$ }$ print(d)"

Wait you're pretty much implementing from __future__ import braces?

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

Re: Aggressive language on python-list

[Joshua Landau]

On 13 October 2012 22:35, Tim Delaney  wrote:

> On 14 October 2012 08:22, Roel Schroeven  wrote:
>
>> Zero Piraeus schreef:
>>
>>  :
>>>
>>> Not sure exactly how to put this ...
>>>
>>> I'm a mostly passive subscriber to this list - my posts here over the
>>> years could probably be counted without having to take my socks off -
>>> so perhaps I have no right to comment, but I've noticed a marked
>>> increase in aggressive language here lately, so I'm putting my head
>>> above the parapet to say that I don't appreciate it.
>>>
>>
>> Same here. I've been lurking here for a number of years, and I've always
>> regarded this list as an example of friendly civilized behavior, quite
>> exceptional on the Internet. I also have the impression that situation is
>> changing for the worse, and it worries me too.
>
>
> If everyone *plonks* the jerks/trolls/bots/etc and no one responds to
> them, they won't have an audience and will either go away; act out more
> (but no one will see it); or reform and become a useful member of the group
> (probably needing to change email addresses to be un-*plonked*).
>
> The problem is mainly when people respond to them. That's what they want -
> it gives them an audience. No matter how much you want to *just this once*
> respond to one, resist the urge.
>

I agree up to here.


> And if you can't prevent yourself from replying to someone who has quoted
> one in order to tell them that the person is a known troll/bot, tell them
> privately, not on the list.
>

I don't know.  If it's not publicly obvious that the person if a trollbot,
then other people may miss it. Many doubted 8's being a bot, and if
it's not open it may take a lot longer for people to spot the obvious.

A response to someone who quotes a trollbot just stating "*Username* is a
trollbot." where *no* further correspondence occurs doesn't seem like
trollbotbait to me, and it makes it easy for people to know who's been
warned.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: readline trick needed

[Mark Lawrence]

On 13/10/2012 22:31, Joshua Landau wrote:


With two irritants (including 8), is it not advisable that python-list
gets an admin to block these accounts? Even if it does nothing more than
slow them, that's something.



Most irritants are mere amateurs compared to Ilias Lazaridis.  I wonder 
if he's *STILL* researching?


--
Cheers.

Mark Lawrence.

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

Re: How to use "while" within the command in -c option of python?

[Joshua Landau]

On 13 October 2012 23:09, Chris Angelico  wrote:

> On Sun, Oct 14, 2012 at 9:00 AM, Joshua Landau
>  wrote:
> > That is also callable from the command-line like so:
> >>
> >> python -m debrace -c "if a: ${ print(1) $ print(2) $ while b: c() $ if
> g:
> >> ${ pass }$ }$ print(d)"
>
> Wait you're pretty much implementing from __future__ import braces?
>

But *without changing Python*. The Python that's run is brace-less. This is
a *pure module* and thus none of this will occur inside code, just in its
generation or on the command line.

Unless you want to use it on all of your files, in which case you're better
off with another language.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feedback on my python framework I'm building.

[nbvfour]

On Saturday, October 13, 2012 2:33:43 PM UTC-4, Chris Angelico wrote:
> 
> Nice theory, but this is the bit that I fundamentally disagree with.
> Forcing programmers to work in one particular style is usually not the
> job of the language/framework/library. That should be up to the
> programmer, or at least the local style guide. 

Have you ever read the zen of python? "Theres only one way to do it" is a core 
motto of the python language. In my opinion, this is the most important aspect 
of python and is what makes python so much better than PHP and perl and all the 
other "do it however you want, the more convoluted and obfuscated the better!" 
languages.

> I do like your plan of
> having identical interfaces to the same functionality (your example of
> web-based and command-line is particularly appealing to my personal
> tastes), but the same can usually be achieved with a well-built
> library. In fact, all you need to do is have your model as a simple
> Python module, and then the view and controller call on its functions.
> 
> What does your framework offer over a basic system like that?

This "well built library" you mention basically describes my framework. You 
write a model method/function that takes data and then returns data. All giotto 
does is extract that data from the controller, pass it on to the model, then 
take the output of the model and pass it in to the view. You write the view, 
you write the model. Giotto provides the API for making al this happen. Giotto 
doesn't care if your model calls Postgres or Mysql or Redis or RabbitMQ, thats 
not of any concern to the framework.

The advantage of this is that the framework can 'mock' out the model layer very 
easily. For instance, your front end designers can work on the HTML without 
needing to run postgres, and the backend developers can work on the backend 
through the command line.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: readline trick needed

[Joshua Landau]

On 13 October 2012 22:44, Chris Angelico  wrote:

> On Sun, Oct 14, 2012 at 8:31 AM, Joshua Landau
>  wrote:
> > With two irritants (including 8), is it not advisable that
> python-list
> > gets an admin to block these accounts? Even if it does nothing more than
> > slow them, that's something.
>
> That's what killfiles are for. You have two options:
>
> http://en.wikipedia.org/wiki/Kill_file
> http://bofh.ch/bofh/bsmh2.html
>
> The first option is not perfect, as you'll still see replies that
> quote such people's posts. The second has a few issues with local law
> enforcement, but other than that, is a very effective means of
> avoiding seeing their posts.


The first's no good for protecting the newbies though. If *troll* flames *
newbie*, then I want to be able to assure *newbie* that he's not done
anything wrong or stupid.

The second is a bit better, definitely, but what I'm wanting is to delegate
these tasks to python-list's admins. I'm lazy, see.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: readline trick needed

[Joshua Landau]

On 13 October 2012 23:13, Mark Lawrence  wrote:

> On 13/10/2012 22:31, Joshua Landau wrote:
>
>>
>> With two irritants (including 8), is it not advisable that python-list
>> gets an admin to block these accounts? Even if it does nothing more than
>> slow them, that's something.
>>
>>
> Most irritants are mere amateurs compared to Ilias Lazaridis.  I wonder if
> he's *STILL* researching?


My god, he even has an encyclopaedia
entry.
Is he some kind of deity?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: readline trick needed

[Chris Angelico]

On Sun, Oct 14, 2012 at 9:25 AM, Joshua Landau
 wrote:
> On 13 October 2012 22:44, Chris Angelico  wrote:
>>
>> On Sun, Oct 14, 2012 at 8:31 AM, Joshua Landau
>>  wrote:
>> > With two irritants (including 8), is it not advisable that
>> > python-list
>> > gets an admin to block these accounts? Even if it does nothing more than
>> > slow them, that's something.
>>
>> That's what killfiles are for. You have two options:
>>
>> http://en.wikipedia.org/wiki/Kill_file
>> http://bofh.ch/bofh/bsmh2.html
>>
>> The first option is not perfect, as you'll still see replies that
>> quote such people's posts. The second has a few issues with local law
>> enforcement, but other than that, is a very effective means of
>> avoiding seeing their posts.
>
>
> The first's no good for protecting the newbies though. If troll flames
> newbie, then I want to be able to assure newbie that he's not done anything
> wrong or stupid.
>
> The second is a bit better, definitely, but what I'm wanting is to delegate
> these tasks to python-list's admins. I'm lazy, see.

Agreed, defending newbies is important. But not everyone gets
frustrated at trolls. Those who don't, don't bother to killfile them,
and can respond in defense of the newbies. Also, if two or three
non-trolls respond to the original post, the angry troll is only one
of several, which helps dilute the problem a bit. Still not a
solution, but it helps.

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

Re: readline trick needed

[Mark Lawrence]

On 13/10/2012 23:26, Joshua Landau wrote:

On 13 October 2012 23:13, Mark Lawrence  wrote:


On 13/10/2012 22:31, Joshua Landau wrote:



With two irritants (including 8), is it not advisable that python-list
gets an admin to block these accounts? Even if it does nothing more than
slow them, that's something.



Most irritants are mere amateurs compared to Ilias Lazaridis.  I wonder if
he's *STILL* researching?



My god, he even has an encyclopaedia
entry.
Is he some kind of deity?



Oh no he's far higher up the food chain than that.  Here's a starter
https://groups.google.com/forum/?fromgroups=#!search/lazaridis$20banned/comp.lang.ruby/plR34TbM3vc/Ev-Hj5F8oKcJ

--
Cheers.

Mark Lawrence.

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

Re: Feedback on my python framework I'm building.

[Chris Angelico]

On Sun, Oct 14, 2012 at 9:24 AM,   wrote:
> On Saturday, October 13, 2012 2:33:43 PM UTC-4, Chris Angelico wrote:
>>
>> Nice theory, but this is the bit that I fundamentally disagree with.
>> Forcing programmers to work in one particular style is usually not the
>> job of the language/framework/library. That should be up to the
>> programmer, or at least the local style guide.
>
> Have you ever read the zen of python? "Theres only one way to do it" is a 
> core motto of the python language. In my opinion, this is the most important 
> aspect of python and is what makes python so much better than PHP and perl 
> and all the other "do it however you want, the more convoluted and obfuscated 
> the better!" languages.

Many times, but 'import this' doesn't translate into a language rule
that all classes have an uppercase first letter and all non-classes
don't; nor does it require that it be impossible to combine two simple
statements onto one line (because it's equally "obvious" to put them
onto two lines). Some things are questions of style, and are and
should be both implemented.

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

Re: Aggressive language on python-list

[Tim Delaney]

>
> A response to someone who quotes a trollbot just stating "*Username* is a
> trollbot." where *no* further correspondence occurs doesn't seem like
> trollbotbait to me, and it makes it easy for people to know who's been
> warned.
>

If properly trimmed, so there is no reference to the troll/bot or any text
from the troll/bot - fine. But any reference to the original will make it
harder for those of us who use bayesian-based spam filtering.

Tim Delaney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: readline trick needed

[Mark Lawrence]

On 13/10/2012 23:52, Mark Lawrence wrote:

On 13/10/2012 23:26, Joshua Landau wrote:

On 13 October 2012 23:13, Mark Lawrence  wrote:


On 13/10/2012 22:31, Joshua Landau wrote:



With two irritants (including 8), is it not advisable that
python-list
gets an admin to block these accounts? Even if it does nothing more
than
slow them, that's something.



Most irritants are mere amateurs compared to Ilias Lazaridis.  I
wonder if
he's *STILL* researching?



My god, he even has an encyclopaedia
entry.
Is he some kind of deity?



Oh no he's far higher up the food chain than that.  Here's a starter
https://groups.google.com/forum/?fromgroups=#!search/lazaridis$20banned/comp.lang.ruby/plR34TbM3vc/Ev-Hj5F8oKcJ




Yes a real pro.  Trolling will never become an Olympic sport as the 
guy's so good nobody can compete with him.  (If he was American they'd 
still have a World Series though :)  Throw his name plus Eclipse, 
Netbeans and banned into your search engine of choice and enjoy, but 
beware that to really endulge yourself please stock up on vast 
quantities of caffeine and sandwiches first cos you'll need them.  For 
example this http://web.archiveorange.com/archive/v/7IfPlywrYZb0gAgMsPa1 
points to this http://www.tfeb.org/lisp/mad-people.html


--
Cheers.

Mark Lawrence.

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

Re: Feedback on my python framework I'm building.

[Oscar Benjamin]

On 13 October 2012 17:48, Chris Angelico  wrote:
>
> The only way to support *absolutely everything* is to do nothing - to
> be a framework so thin you're invisible. (That's not to say you're
> useless; there are bridge modules that do exactly this - ctypes can
> call on any library function from Python; it must therefore abstract
> away nothing. But that's a very specific sort of case.) Anything else
> must by nature make some things easier and some things harder.

Without further ado I announce the release of my new library that
simultaneously does everything and nothing. It can be installed with:

pip install ''

That's right: the library's name is the empty string (as it's source
and documentation). Don't be fooled by the error message from pip: the
library was correctly installed before you ran the command!

Other libraries have failed by imposing restrictions on usage in an
attempt to better serve a mere finite number of use cases. This
library is *equally optimal* for an uncountably infinite number of
purposes and comes with the strong guarantee that it will never
decrease your productivity in any situation whatsoever!


Oscar

P.S. I also have not taken 10 minutes to read the documentation for
giotto as I get the impression that is not relevant to any of my own
use cases.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feedback on my python framework I'm building.

[Steven D'Aprano]

On Sat, 13 Oct 2012 15:24:04 -0700, nbvfour wrote:

> On Saturday, October 13, 2012 2:33:43 PM UTC-4, Chris Angelico wrote:
>> 
>> Nice theory, but this is the bit that I fundamentally disagree with.
>> Forcing programmers to work in one particular style is usually not the
>> job of the language/framework/library. That should be up to the
>> programmer, or at least the local style guide.
> 
> Have you ever read the zen of python? "Theres only one way to do it" is
> a core motto of the python language.

Have *you* ever read the Zen of Python? The line from the Zen is:

"There should be one-- and preferably only one --obvious way to do it."

Paraphrasing for emphasis:

There SHOULD be one (or more, but one is best) OBVIOUS way to do it.

as opposed to languages where there are no obvious ways to things, or 
thirty.

Don't believe me that the emphasis is on *obvious* rather than "only"? 
The very next line of the Zen tells you:

"Although that way may not be OBVIOUS at first unless you're Dutch."

[emphasis added]

Not being Dutch, I don't know whether the obvious way to do command line 
argument handling is the getopt module or argparse. But there certainly 
isn't *only one way* to do command line argument handling.

It is a gross canard, mostly spread by Perl programmers, that Python is 
"limited" to "only one way to do it" and therefore isn't as good as Perl 
which gives you "more freedom" (to write unreadable, unmaintainable code).

It simply isn't true that Python only gives you "only one way". The 
acronym OOWTDI stands for *one obvious way to do it*.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: one obvious parser (was "Feedback on my python framework I'm building.")

[Tim Chase]

On 10/13/12 21:25, Steven D'Aprano wrote:
> Not being Dutch, I don't know whether the obvious way to do command line 
> argument handling is the getopt module or argparse. But there certainly 
> isn't *only one way* to do command line argument handling.

As an aside, I just watched a fascinating video[1] on docopt[2]
which seems like an amazingly simple way to build command-line UIs.
 I haven't toyed with it yet, but I just wanted to share my "wow,
that's slick" experience with the list.

-tkc


[1]
http://www.youtube.com/watch?v=pXhcPJK5cMc

[2]
http://docopt.org/





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

Re: Feedback on my python framework I'm building.

[MRAB]

On 2012-10-14 03:25, Steven D'Aprano wrote:

On Sat, 13 Oct 2012 15:24:04 -0700, nbvfour wrote:


On Saturday, October 13, 2012 2:33:43 PM UTC-4, Chris Angelico wrote:


Nice theory, but this is the bit that I fundamentally disagree with.
Forcing programmers to work in one particular style is usually not the
job of the language/framework/library. That should be up to the
programmer, or at least the local style guide.


Have you ever read the zen of python? "Theres only one way to do it" is
a core motto of the python language.


Have *you* ever read the Zen of Python? The line from the Zen is:

"There should be one-- and preferably only one --obvious way to do it."

Paraphrasing for emphasis:

There SHOULD be one (or more, but one is best) OBVIOUS way to do it.

as opposed to languages where there are no obvious ways to things, or
thirty.

Don't believe me that the emphasis is on *obvious* rather than "only"?
The very next line of the Zen tells you:

"Although that way may not be OBVIOUS at first unless you're Dutch."

[emphasis added]

Not being Dutch, I don't know whether the obvious way to do command line
argument handling is the getopt module or argparse. But there certainly
isn't *only one way* to do command line argument handling.

It is a gross canard, mostly spread by Perl programmers, that Python is
"limited" to "only one way to do it" and therefore isn't as good as Perl
which gives you "more freedom" (to write unreadable, unmaintainable code).

It simply isn't true that Python only gives you "only one way". The
acronym OOWTDI stands for *one obvious way to do it*.


I think it's the "Paradox of Choice".

The more choices there are, the more time you'll spend trying to decide
which one is "best".

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

Re: Feedback on my python framework I'm building.

[Steven D'Aprano]

On Sun, 14 Oct 2012 05:33:40 +1100, Chris Angelico wrote:

> Forcing programmers to work in one particular style is usually not the
> job of the language/framework/library.

Have you actually programmed before? 

*grin*

I've never come across a language/framework/library that DOESN'T force 
programmers to work in a particular style, at least to some degree.

Every language encourages certain styles, discourages others, and makes 
some impossible. Remember using PEEK and POKE commands with BASIC back in 
1978? Pretty much impossible in Python. Perl probably has a way to do it 
*wink* but few others do, and thank goodness we've moved on.

The sort of code you'll write in Fortran77 will be significantly 
different from that you'll write in Lisp or Java or Forth or Ocaml. 
Languages don't just differ in syntax, they differ in what they consider 
good idioms, or even *possible* idioms. Hence:

http://dirtsimple.org/2004/12/python-is-not-java.html
http://dirtsimple.org/2004/12/java-is-not-python-either.html

Can you write "Java in Python"? Well, to some degree you can. Any Turing 
complete language can be written in any other Turing complete language, 
with sufficient layers of indirection, modulo things which are completely 
impossible. You simply cannot do C-style pointer manipulations in Python, 
not without breaking out of Python (e.g. with ctypes).

Libraries and frameworks are in a similar boat. Can you write CherryPy in 
Django? Not easily. Generally the way to ignore a framework or library 
and write in a different style is to, well, ignore the framework or 
library and write in a different style :)

You can always step outside the bounds of the framework or library and 
write something in the programming language level. Just because numpy 
doesn't have some function I want, doesn't mean that I can't write it in 
Python -- and just because numpy wants to work with arrays doesn't mean I 
can't insist in using XML for my data, provided I convert it into an 
array each time I pass it to a numpy function and back to XML when it 
returns.

(For my next trick, watch as I eat three pounds of high-level radioactive 
waste!)

Now clearly some frameworks are lighter than others, some impose their 
style on your code like a big heavy weight on a rubber sheet, distorting 
everything for miles around. Others not so much. But I really don't see 
the problem here: if you don't like the "Twisted style" that it imposes, 
don't use Twisted, use another framework, or no framework at all.

I think it is a *good* thing that different languages/frameworks/
libraries have their own styles. The alternative isn't "many styles" but 
"one style": an unstylish mess.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

trouble with nested closures: one of my variables is missing...

[Cameron Simpson]

I'm having some trouble with closures when defining a decorator.

TL;DR:
  I have a function that makes a decorator, and only some of the names
  from an outer scope appear in the inner closure's locals().
  And I do not understand why at all.

Let me explain...

Environment: python 2.7.3 on MacOSX Mountain Lion from MacPorts.

Background: I have a decorator called "file_property" that watches a
file for changes and reloads the file at need. Otherwise it returns a
cached value. It has a lock and some sanity checks and works quite well.

Example method:

  class myclass(object):
@file_property
def rules(self):
  with open(self._rules_path) as rfp:
R = parse(rfp)
  return R
  C = myclass()

and using C.rules fetches parses the rule file as needed and caches the
value until the file next changes.

I naively wrote file_property with a bunch of default parameters:

  def file_property(func, attr_name=None, unset_object=None, poll_rate=1):

and because I never overrode these failed to realise they're useless. Fine.

So, I'm rewriting file_property like this:

  def file_property(func):
return make_file_property()(func)

i.e. it makes a "vanilla" file_property using the default internals.
Now I have make_file_property with the default parameters:

  def make_file_property(attr_name=None, unset_object=None, poll_rate=1):

which I might use as:

  class myclass(object):
@make_file_property(poll_rate=3)
def rules(self):
  with open(self._rules_path) as rfp:
R = parse(rfp)
  return R

The inner function is the same, but it won't reload the file more often
that once every 3 seconds.

However, I can't make my make_file_property function work. I've stripped
the code down and it does this:

  [hg/css-mailfiler]fleet*1> python foo.py
  make_file_property(attr_name=None, unset_object=None, poll_rate=1): 
locals()={'attr_name': None, 'poll_rate': 1, 'unset_object': None}
  made_file_property(func=): locals()={'func': 
, 'unset_object': None}
  Traceback (most recent call last):
File "foo.py", line 21, in 
  def f(self, foo=1):
File "foo.py", line 4, in file_property
  return make_file_property()(func)
File "foo.py", line 10, in made_file_property
  if attr_name is None:
  UnboundLocalError: local variable 'attr_name' referenced before assignment

Observe above that 'unset_object' is in locals(), but not 'attr_name'.
This surprises me.

The stripped back code (missing the internals of the file property
watcher) looks like this:

  import sys

  def file_property(func):
return make_file_property()(func)

  def make_file_property(attr_name=None, unset_object=None, poll_rate=1):
print >>sys.stderr, "make_file_property(attr_name=%r, unset_object=%r, 
poll_rate=%r): locals()=%r" % (attr_name, unset_object, poll_rate,locals())
def made_file_property(func):
  print >>sys.stderr, "made_file_property(func=%r): locals()=%r" % (func, 
locals())
  if attr_name is None:
attr_name = '_' + func.__name__
  lock_name = attr_name + '_lock'
  def getprop(self):
with getattr(self, lock_name):
  # innards removed here
  pass
return getattr(self, attr_name, unset_object)
  return property(getprop)
return made_file_property

  @file_property
  def f(self, foo=1):
print "foo=%r" % (foo,)

  @make_file_property(attr_name="_blah")
  def f2(self, foo=2):
print "foo=%r" % (foo,)

Can someone explain what I'm doing wrong, or tell me this is a python
bug?
-- 
Cameron Simpson 

Bolts get me through times of no courage better than courage gets me
through times of no bolts!
- Eric Hirst 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feedback on my python framework I'm building.

[Chris Angelico]

On Sun, Oct 14, 2012 at 2:37 PM, Steven D'Aprano
 wrote:
> On Sun, 14 Oct 2012 05:33:40 +1100, Chris Angelico wrote:
>
>> Forcing programmers to work in one particular style is usually not the
>> job of the language/framework/library.
>
> Have you actually programmed before?
>
> *grin*
>
> I've never come across a language/framework/library that DOESN'T force
> programmers to work in a particular style, at least to some degree.

Style and technique aren't quite the same thing, though. Where you
draw the line between aspects the language should enforce and aspects
that should be up to the programmer is a tricky question. A language's
standard library certainly encourages a particular naming style, but
nothing enforces it.

Of course the language has to enforce something. I just don't think
that the MVC model should be part of what's enforced. What next?
Require that one file be one class and have nothing else in it?

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

Understanding and dealing with an exception

[Vincent Davis]

I am working on a script to find bad image files. I am using PIL
and specifically image.verify() I have a set of known to be bad image files
to test. I also what to be able to test any file for example a .txt and
deal with the exception.
Currently my code is basically

try:
im = Image.open(ifile)
try:
print(im.verify())
except:
print('Pil image.verify() failed: ' + afile)
except IOError:
print('PIL cannot identify image file: ' + afile)
except:
print(ifile)
print("Unexpected error doing PIL.Image.open():", sys.exc_info()[0])
raise

I have a lot of file that have an IOError.  I would expect this error for
any non image file.
I have yet to have image.verify() All failures have been IOError.

Then I got this error (below). Which to me to me is a bug in PIL?
The file seems ok when I open it for editing in an external editor.

So my question, I don't what to raise this exception thereby stoping the
script nor record the image as bad or good. This would possibly lead to
false positives or negatives.
Then again I assume it would be possible to get this error because the file
is corrupt.
I am not really sure how to deal with this. Any advise.

fixed-width.psd
('Unexpected error doing PIL.Image.open():', )



OverflowError: Python int too large to convert to C long
File "/Volumes/Hafnium/Google Drive/bad images/untitled-2.py", line 21, in

  im = Image.open(ifile)
File
"/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/PIL/Image.py",
line 1965, in open
  return factory(fp, filename)
File
"/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/PIL/ImageFile.py",
line 91, in __init__
  self._open()
File
"/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/PIL/PsdImagePlugin.py",
line 123, in _open
  self.layers = _layerinfo(self.fp)
File
"/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/PIL/PsdImagePlugin.py",
line 230, in _layerinfo
  t = _maketile(file, m, bbox, 1)
File
"/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/PIL/PsdImagePlugin.py",
line 266, in _maketile
  bytecount = read(channels * ysize * 2)

Vincent
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Understanding and dealing with an exception

[Chris Angelico]

On Sun, Oct 14, 2012 at 3:23 PM, Vincent Davis  wrote:
> OverflowError: Python int too large to convert to C long
> line 266, in _maketile
>   bytecount = read(channels * ysize * 2)

Is the file over 2GB? Might be a limitation, more than a bug, and one
that could possibly be raised by using a 64-bit build.

Alternatively, you could deem them invalid for exceeding your file
size limit (either before passing to PIL, or on catching this
exception).

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

Re: Understanding and dealing with an exception

[Vincent Davis]

Oops, I was going to make note of the file size. 1.2MB

Vincent



On Sat, Oct 13, 2012 at 10:31 PM, Chris Angelico  wrote:

> On Sun, Oct 14, 2012 at 3:23 PM, Vincent Davis 
> wrote:
> > OverflowError: Python int too large to convert to C long
> > line 266, in _maketile
> >   bytecount = read(channels * ysize * 2)
>
> Is the file over 2GB? Might be a limitation, more than a bug, and one
> that could possibly be raised by using a 64-bit build.
>
> Alternatively, you could deem them invalid for exceeding your file
> size limit (either before passing to PIL, or on catching this
> exception).
>
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Understanding and dealing with an exception

[Chris Angelico]

On Sun, Oct 14, 2012 at 3:36 PM, Vincent Davis  wrote:
> Oops, I was going to make note of the file size. 1.2MB

Then I'd definitely declare the file bad; I don't know what the valid
ranges for channels and ysize are, but my reading of that is that your
file's completely corrupt, maybe even malicious. PIL probably ought to
check these things, so there may be a tracker issue coming from this,
but I'd be inclined to declare any thrown exception as meaning it's a
bad file. Call it "failed a security check" perhaps.

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

Re: Understanding and dealing with an exception

[Vincent Davis]

I can open it is and all looks good using Pixelmator (I don't have
Photoshop installed). I don't think there is anything wrong with the image.

Part of my question is a result of being new to actually using exceptions
in my programs and dealing with the exceptions is a primary part of what I
need to do with this program. When I get an exception that seems to be an
issue with PIL (i.e. not my program or a problem with the image) I am not
sure what the "right" or conventional way to deal with it is.

Vincent


On Sat, Oct 13, 2012 at 10:49 PM, Chris Angelico  wrote:

> On Sun, Oct 14, 2012 at 3:36 PM, Vincent Davis 
> wrote:
> > Oops, I was going to make note of the file size. 1.2MB
>
> Then I'd definitely declare the file bad; I don't know what the valid
> ranges for channels and ysize are, but my reading of that is that your
> file's completely corrupt, maybe even malicious. PIL probably ought to
> check these things, so there may be a tracker issue coming from this,
> but I'd be inclined to declare any thrown exception as meaning it's a
> bad file. Call it "failed a security check" perhaps.
>
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: trouble with nested closures: one of my variables is missing...

[Chris Rebert]

On Saturday, October 13, 2012, Cameron Simpson wrote:

> I'm having some trouble with closures when defining a decorator.



> However, I can't make my make_file_property function work. I've stripped
> the code down and it does this:



>   Traceback (most recent call last):
> File "foo.py", line 21, in 
>   def f(self, foo=1):
> File "foo.py", line 4, in file_property
>   return make_file_property()(func)
> File "foo.py", line 10, in made_file_property
>   if attr_name is None:
>   UnboundLocalError: local variable 'attr_name' referenced before
> assignment
>
> Observe above that 'unset_object' is in locals(), but not 'attr_name'.
> This surprises me.
>
> The stripped back code (missing the internals of the file property
> watcher) looks like this:
>
>   import sys
>
>   def file_property(func):
> return make_file_property()(func)
>
>   def make_file_property(attr_name=None, unset_object=None, poll_rate=1):
> print >>sys.stderr, "make_file_property(attr_name=%r, unset_object=%r,
> poll_rate=%r): locals()=%r" % (attr_name, unset_object, poll_rate,locals())
> def made_file_property(func):


You're missing a "nonlocal" declaration here.

  print >>sys.stderr, "made_file_property(func=%r): locals()=%r" %
> (func, locals())
>   if attr_name is None:
> attr_name = '_' + func.__name__


 You assign to it, but there's no nonlocal declaration, so Python thinks
it's a local var, hence your error.

Pardon my brevity and some lack of trimming; I'm on a smartphone and in a
rush.

- Chris

  lock_name = attr_name + '_lock'
>   def getprop(self):
> with getattr(self, lock_name):
>   # innards removed here
>   pass
> return getattr(self, attr_name, unset_object)
>   return property(getprop)
> return made_file_property
>
>   @file_property
>   def f(self, foo=1):
> print "foo=%r" % (foo,)
>
>   @make_file_property(attr_name="_blah")
>   def f2(self, foo=2):
> print "foo=%r" % (foo,)
>
> Can someone explain what I'm doing wrong, or tell me this is a python
> bug?
> --
> Cameron Simpson >
>
> Bolts get me through times of no courage better than courage gets me
> through times of no bolts!
> - Eric Hirst >
> --
> http://mail.python.org/mailman/listinfo/python-list
>


-- 
Cheers,
Chris
--
http://rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Understanding and dealing with an exception

[Chris Angelico]

On Sun, Oct 14, 2012 at 4:01 PM, Vincent Davis  wrote:
> I can open it is and all looks good using Pixelmator (I don't have Photoshop
> installed). I don't think there is anything wrong with the image.
>
> Part of my question is a result of being new to actually using exceptions in
> my programs and dealing with the exceptions is a primary part of what I need
> to do with this program. When I get an exception that seems to be an issue
> with PIL (i.e. not my program or a problem with the image) I am not sure
> what the "right" or conventional way to deal with it is.

Ah, okay. Sorry, I don't know PIL at all, and was just reading the
error message itself. It does seem that you're trying to read more
than 1<<31 bytes from a 1.2MB file, though you could confirm that by
looking at the source code - the file and line as in the traceback.

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

Re: Aggressive language on python-list

[Dwight Hutto]

I'm not a know it all, but when attacked personally I defend myself,
and those can turn into flame wars.

Your plonks are irrelevant in terms of an argument ytou shouldn't
participate in.

These things can get nasty quick.

So if you have virgin eyes, then kill file it, but I like to think
Ioffer logical reasoning to those who respect a good programming
conversation.

If you want it, bring it, but it's mainly just regular computer
science discussion.
-- 
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com
-- 
http://mail.python.org/mailman/listinfo/python-list