On Tuesday, 11 November 2014 18:07:27 UTC, Ian wrote:
> The example that I posted is one that I recall being brought up on
> this list in the past, but I don't have a link for you.
THanks Ian for your help in this.
--
https://mail.python.org/mailman/listinfo/python-list
On 11/11/2014 5:52 PM, Ben Finney wrote:
Terry Reedy writes:
We love 'assert' so much that we have 20-30 'assertXYZ' variations in
unittest.
A function will not be disabled by a run-time option to the Python
interpreter.
The statement 'assert expression' is almost equivalent to
if not exp
On Tue, Nov 11, 2014 at 11:53 AM, Mary-Frances McNamee <
maryfrances.mcna...@epas-ltd.com> wrote:
> To whom it may concern,
>
>
>
> I am currently working on a bit of coding for a raspberry pi, I was
> wondering maybe I could get some advice? I want my program to run for a
> certain time, for exa
>-Original Message-
>From: Python-list [mailto:python-list-
>bounces+crk=godblessthe...@python.org] On Behalf Of Chris Angelico
>Sent: Tuesday, November 11, 2014 12:36 AM
>Cc: python-list@python.org
>Subject: Re: I don't read docs and don't know how to use Google. What
>does the print fun
On Tue, 11 Nov 2014 17:35:11 -0800, Ethan Furman wrote:
> On 11/11/2014 05:08 PM, Ben Finney wrote:
>> Ethan Furman writes:
>>
>>> My wife (using a Win7 machine) will be on a web page that has a link
>>> to mail somebody. She clicks on it, and it opens the currently
>>> installed but unused Thun
On Wed, 12 Nov 2014 08:56:07 +, alister wrote:
> On Tue, 11 Nov 2014 17:35:11 -0800, Ethan Furman wrote:
>
>> On 11/11/2014 05:08 PM, Ben Finney wrote:
>>> Ethan Furman writes:
>>>
My wife (using a Win7 machine) will be on a web page that has a link
to mail somebody. She clicks on
On Wed, Nov 12, 2014 at 4:39 PM, Clayton Kirkwood wrote:
> Chris, you're kidding, right? People get programming jobs without the
> knowledge? How do they keep them? Don't hiring people look at code examples,
> or previous employment? Ask relevant questions?
Oh, I didn't say they *keep* the jobs,
On 10 November 2014 22:51, Ned Deily wrote:
> In article
> ,
> Paul Wiseman wrote:
>> I've been using the latest mac ppc/i386 binaries from python.org
>> (https://www.python.org/ftp/python/2.7.8/python-2.7.8-macosx10.5.dmg).
>> From what I can tell this version is linked against a pretty old
>>
On Wed, Nov 12, 2014 at 3:58 AM, alister
wrote:
> On Wed, 12 Nov 2014 08:56:07 +, alister wrote:
>
>> On Tue, 11 Nov 2014 17:35:11 -0800, Ethan Furman wrote:
>>
>>> On 11/11/2014 05:08 PM, Ben Finney wrote:
Ethan Furman writes:
> My wife (using a Win7 machine) will be on a web p
Hello
I saw in a code from a previous message in this forum
a curious function argument.
def test(x=[0]):
print(x[0]) ## Poor man's object
x[0] += 1
test()
0
test()
1
test()
2
I understand that the author wants to implement a global
variable x . It would be better to write 'glob
On Wed, 12 Nov 2014 14:07:14 +0100, ast wrote:
[function def with mutable default parameter]
> I understand that the author wants to implement a global variable x . It
> would be better to write 'global x' inside the function.
It may not be the case that the purpose was to implement a global
va
On 2014-11-12, Ben Finney wrote:
> Chris Angelico writes:
>
>> On Wed, Nov 12, 2014 at 7:03 AM, Ben Finney
>> wrote:
>> > An ‘assert’ statement in the code will sometimes be active, and
>> > sometimes be a no-op, for *exactly* the same code under different
>> > circumstances. That's a trap for
On Mon, Nov 10, 2014 at 10:31 AM, Chris Angelico wrote:
> So the semantics should be: If NameError would be raised (not
> including UnboundLocalError, which still represents an error), attempt
> to import the absent name. If successful, continue as if it had
> already been done. If ImportError is
On 11/12/2014 06:37 AM, Chris Angelico wrote:
On Mon, Nov 10, 2014 at 10:31 AM, Chris Angelico wrote:
So the semantics should be: If NameError would be raised (not
including UnboundLocalError, which still represents an error), attempt
to import the absent name. If successful, continue as if it
> No bites? I'd have thought there'd be a few crazy ideas thrown out in
> answer to this.
I was on vacation for a few days, so haven't been all that attentive
to my mail. I have an autoload module which does something similar
(note the Python 2.x syntax):
import sys, inspect, traceback, re
def a
Chris Angelico Wrote in message:
> On Mon, Nov 10, 2014 at 10:31 AM, Chris Angelico wrote:
>> So the semantics should be: If NameError would be raised (not
>> including UnboundLocalError, which still represents an error), attempt
>> to import the absent name. If successful, continue as if it had
On Tue, Nov 11, 2014 at 5:43 AM, Ian Kelly wrote:
> On Sat, Nov 8, 2014 at 3:31 PM, Gregory Ewing
> wrote:
> > (BTW, I'm actually surprised that this technique makes c callable.
> > There must be more going on that just "look up __call__ in the class
> > object", because evaluating C.__call__ ju
On Tue, Nov 11, 2014 at 8:04 PM, Ethan Furman wrote:
> My wife (using a Win7 machine) will be on a web page that has a link to mail
> somebody. She clicks on it, and it opens the currently installed but unused
> Thunderbird.
As others have mentioned, this is more a question of configuring your
b
On Tue, Nov 11, 2014 at 10:48 AM, Larry Martell wrote:
> I have a PHP app that I want to convert to django. But I want to do it
> stages. All the heavy lifting is in the PHP code, so first, I want to
> just use templates and views to generate the HTML, but still call the
> PHP code. Then later con
On 11/11/2014 10:30 AM, Larry Martell wrote:
> They are technically savvy. They are a 100% PHP shop. They have a big,
> complicated app that they've been working on for 10 years. No one
> there knows python or django. They want to put some new frontends on
> their app. I was bought in for another p
On Thu, Nov 13, 2014 at 1:56 AM, Skip Montanaro
wrote:
> sys.excepthook = autoload_exc
>
> I can't see a lot of people wanting this (I normally have its import
> commented out in my PYTHONSTARTUP file), and I think it would probably
> be bad practice for new users of the language.
Interesting dat
On Thu, Nov 13, 2014 at 2:16 AM, Dave Angel wrote:
> I gave it a short whirl, just trying to make __missing__ work.
>
> The type of globals () is a dict. I was able to add a
> __missing__:myfunct to the instance but in order to work, the
> __missing__ must be added as a class attribute, a metho
Michael Torrie writes:
> If the shop is entire a PHP shop, and no one knows python, then
> rewriting things in Python and Django is a really bad idea.
It can be done well; see “Transitioning from PHP to Django on the sly”
http://pyvideo.org/video/2233/transitioning-from-php-to-django-on-the-sly>
On Wed, Nov 12, 2014 at 12:49 PM, Chris Angelico wrote:
> Interesting data point there - that you actually have it handy and
> choose not to use it.
And, I believe I wrote it. Can't have a worse recommendation than
that. A cook who doesn't eat his own cooking. :-) I think I disabled
its import so
On Thu, Nov 13, 2014 at 5:09 AM, Skip Montanaro
wrote:
> On Wed, Nov 12, 2014 at 12:49 PM, Chris Angelico wrote:
>> Interesting data point there - that you actually have it handy and
>> choose not to use it.
>
> And, I believe I wrote it. Can't have a worse recommendation than
> that. A cook who
Michael Torrie :
> I've worked in shops before where one person comes in with a new
> language, writes some code, then leaves, leaving us stranded as it
> were.
Programming languages come and go. If you can handle a Philips
screwdriver, you should be able to learn the use of a Torq screwdriver
wi
On Wed, Nov 12, 2014 at 8:33 AM, Fabio Zadrozny wrote:
> As a reference, I recently found a blog post related to that:
> http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/ (the Slots
> part comments on that).
>
> It does seem a bit counter-intuitive that this happens the way it does
On Wed, Nov 12, 2014 at 12:54 PM, Ben Finney wrote:
> Michael Torrie writes:
>
>> If the shop is entire a PHP shop, and no one knows python, then
>> rewriting things in Python and Django is a really bad idea.
>
> It can be done well; see “Transitioning from PHP to Django on the sly”
> http://pyvi
In article
,
Paul Wiseman wrote:
> I'm currently using the installer with py2app to make a distributable
> app that targets 10.5+ (including ppc). To save having more than one
> build I use this for all downloads. Although I'm starting to consider
> making a second 32/64 distributable. Are there
On 11/8/2014 3:31 PM, Akira Li wrote:
Terry Reedy writes:
On my Win7 machine, your complicated code is much worse as it causes
the window to jump about every half second
After cutting and pasting again, I do not see the jumps. I do not have
the code I ran before to compare. I do remember
On Thursday, October 30, 2014 4:10:23 AM UTC-7, Steven D'Aprano wrote:
> I don't particularly like either version. I prefer this:
>
> def load_int(obj):
> if isinstance(obj, int):
> # Case 1), an int, e.g. 7
> return obj
> elif isinstance(obj, str):
> # Case 2) and
On Tuesday, November 11, 2014 11:41:06 AM UTC-8, Peter Cacioppi wrote:
> I get the impression that most Pythonistas aren't as habituated with assert
> statements as I am. Is that just a misimpression on my part? If not, is there
> a good reason to assert less with Python than other languages?
>
I have taught Python to several students over the past few years. As I have
worked with my students, I find myself bothered by the programming idiom that
we use to determine whether a module is being executed or merely imported:
"if __name__ == '__main__':"
The use of two dunder tokens -- on
On Wed, Nov 12, 2014 at 4:02 PM, John Ladasky
wrote:
> I have taught Python to several students over the past few years. As I have
> worked with my students, I find myself bothered by the programming idiom that
> we use to determine whether a module is being executed or merely imported:
>
> "
It appears that I'm not the first person to have thoughts along these lines.
Here's a relevant article:
http://aliles.tumblr.com/post/7455032885/sugar-for-pythons-main
--
https://mail.python.org/mailman/listinfo/python-list
On 11/12/2014 01:02 PM, John Ladasky wrote:
I would like to start a discussion about whether Python should include
a function which executes this evaluation, and hides all of the unfriendly
dunderish details. And if that's a good idea, I would invite a discussion
of how, exactly, it should b
On 11/12/2014 11:37 AM, Marko Rauhamaa wrote:
> Michael Torrie :
>
>> I've worked in shops before where one person comes in with a new
>> language, writes some code, then leaves, leaving us stranded as it
>> were.
>
> Programming languages come and go. If you can handle a Philips
> screwdriver, y
On Wed, Nov 12, 2014 at 1:07 PM, Joel Goldstick
wrote:
> On Wed, Nov 12, 2014 at 4:02 PM, John Ladasky
> wrote:
> > I have taught Python to several students over the past few years. As I
> have worked with my students, I find myself bothered by the programming
> idiom that we use to determine w
Anton :
> I am not sure how and when you use assert, but something that stops me
> from using assert is that in many cases I would use them to
> 1) Check type of an incoming argument/returned value
> 2) Check value of an incoming argument/returned value
You use asserts to boldly state that the as
On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor wrote:
> A decorator is an interesting idea, and should be easy to implement (only
> lightly tested):
>
> def main(func):
> if func.__module__ == "__main__":
> func()
> return func # The return could be omitted to block the function
On 11/12/2014 01:41 PM, Marko Rauhamaa wrote:
Or I might indicate the exhaustion of possibilities:
if status == OK:
...
elif status == ERROR:
...
else:
assert status == WARNING
...
And here's a nice example of what one should NOT do.
John Ladasky :
> I find myself bothered by the programming idiom that we use to
> determine whether a module is being executed or merely imported:
>
> "if __name__ == '__main__':"
I find the idiom cute and loveably silly. A typing tongue twister of
sorts. That boilerplate is far less cumbersome
> def main(func):
> if func.__module__ == "__main__":
> func()
> return func # The return could be omitted to block the function from
> being manually called after import.
>
> Just decorate the "main" function of the script with that, and it will be
> automatically called when r
Ethan Furman :
> On 11/12/2014 01:41 PM, Marko Rauhamaa wrote:
>>
>> Or I might indicate the exhaustion of possibilities:
>>
>> if status == OK:
>> ...
>> elif status == ERROR:
>> ...
>> else:
>> assert status == WARNING
>> ...
>
> And here
On Wednesday, November 12, 2014 2:00:35 PM UTC-8, Anton wrote:
> On Wednesday, November 12, 2014 1:41:20 PM UTC-8, Marko Rauhamaa wrote:
> > Asserts help the reader of the code understand why some possibilities
> > are not considered by the code. They are not considered because the
> > writer of th
On Wednesday, November 12, 2014 1:41:20 PM UTC-8, Marko Rauhamaa wrote:
> Asserts help the reader of the code understand why some possibilities
> are not considered by the code. They are not considered because the
> writer of the code asserts they are not really possible.
I can see how assert state
On Wed, Nov 12, 2014 at 2:56 PM, Marko Rauhamaa wrote:
> Ethan Furman :
>
>> On 11/12/2014 01:41 PM, Marko Rauhamaa wrote:
>>>
>>> Or I might indicate the exhaustion of possibilities:
>>>
>>> if status == OK:
>>> ...
>>> elif status == ERROR:
>>> ...
>>> else:
On Wed, Nov 12, 2014 at 1:51 PM, Ian Kelly wrote:
> On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor
> wrote:
> > A decorator is an interesting idea, and should be easy to implement (only
> > lightly tested):
> >
> > def main(func):
> > if func.__module__ == "__main__":
> > func()
>
On Wed, Nov 12, 2014 at 3:04 PM, Ian Kelly wrote:
> On Wed, Nov 12, 2014 at 2:56 PM, Marko Rauhamaa wrote:
>> How would it be better if you removed the assert then?
>
> You don't need to remove it. Just reorganize it to make sure it
> indicates actual exhaustion of possibilities. E.g. using the "
On Wednesday, November 12, 2014 2:05:17 PM UTC-8, Ian wrote:
> On Wed, Nov 12, 2014 at 2:56 PM, Marko Rauhamaa wrote:
> > Ethan Furman:
> >
> >> On 11/12/2014 01:41 PM, Marko Rauhamaa wrote:
> >>>
> >>> Or I might indicate the exhaustion of possibilities:
> >>>
> >>> if status == OK:
> >>>
On Wed, Nov 12, 2014 at 3:09 PM, Chris Kaynor wrote:
> I was thinking along the lines of replacing:
>
> if __name__ == "__main__":
> <<>>
>
> with
>
> @main
> def myFunction()
> <<<>
>
> Both blocks of code will be called at the same time.
99% of the time the content of <<>> is just "main
Anton :
> I can see how assert statement can point out what should not happen,
> can you give an example when a single assert statement would explain
> why it should never happen?
Asserts don't communicate justifications. They simply assert something
to be the case, period. Any other elaborations
On Wed, Nov 12, 2014 at 3:13 PM, Anton wrote:
> On Wednesday, November 12, 2014 2:05:17 PM UTC-8, Ian wrote:
>> You don't need to remove it. Just reorganize it to make sure it
>> indicates actual exhaustion of possibilities. E.g. using the "assert
>> False" pattern from your post:
>>
>> if status
On Thu, Nov 13, 2014 at 7:53 AM, Anton wrote:
> I am not sure how and when you use assert, but something that stops me from
> using assert is that in many cases I would use them to
> 1) Check type of an incoming argument/returned value
> 2) Check value of an incoming argument/returned value
> But
On 11/12/2014 02:41 PM, Ian Kelly wrote:
On Wed, Nov 12, 2014 at 3:13 PM, Anton wrote:
On Wednesday, November 12, 2014 2:05:17 PM UTC-8, Ian wrote:
You don't need to remove it. Just reorganize it to make sure it
indicates actual exhaustion of possibilities. E.g. using the "assert
False" patter
Ian Kelly :
> Although to be honest I'd rather use something like "raise
> RuntimeError('Unreachable code reached')" than "assert False" here. If
> the expectation is that the code will never be executed, then there's
> no reason to ever optimize it out.
Asserts have nothing to do with them being
On Wednesday, November 12, 2014 2:42:19 PM UTC-8, Ian wrote:
> On Wed, Nov 12, 2014 at 3:13 PM, Anton wrote:
> > If the code is run optimized and asserts are ignore CONFUSED statement
> > would still not be handled and you will not know about it.
> > I would do something like:
>
> There's no way
On 11/12/2014 02:47 PM, Marko Rauhamaa wrote:
Ian Kelly :
Although to be honest I'd rather use something like "raise
RuntimeError('Unreachable code reached')" than "assert False" here. If
the expectation is that the code will never be executed, then there's
no reason to ever optimize it out.
On Thu, Nov 13, 2014 at 9:47 AM, Marko Rauhamaa wrote:
> Apart from idiomatic style, there is no difference between
>
> # never reached
>
> assert False
>
> raise RuntimeError('Unreachable code reached')
>
> 1 / 0
>
> print("Hello world")
>
> since, after all, that line is neve
On Wed, Nov 12, 2014 at 3:48 PM, Anton wrote:
> On Wednesday, November 12, 2014 2:42:19 PM UTC-8, Ian wrote:
>> On Wed, Nov 12, 2014 at 3:13 PM, Anton wrote:
>> > If the code is run optimized and asserts are ignore CONFUSED statement
>> > would still not be handled and you will not know about it
Anton :
> Right, but the goal is not to make the CONFUSED status be handled
> without coding, but to be notified about an unknown status code and
> act accordingly.
Asserts are not about notification, checking or optimization. They are
about communicating what's going on in the programmer's mind.
On Wed, Nov 12, 2014 at 3:47 PM, Marko Rauhamaa wrote:
> Ian Kelly :
>
>> Although to be honest I'd rather use something like "raise
>> RuntimeError('Unreachable code reached')" than "assert False" here. If
>> the expectation is that the code will never be executed, then there's
>> no reason to ev
On Thu, Nov 13, 2014 at 10:02 AM, Ian Kelly wrote:
> On Wed, Nov 12, 2014 at 3:48 PM, Anton wrote:
>> On Wednesday, November 12, 2014 2:42:19 PM UTC-8, Ian wrote:
>>> On Wed, Nov 12, 2014 at 3:13 PM, Anton wrote:
>>> > If the code is run optimized and asserts are ignore CONFUSED statement
>>> >
Ian Kelly :
> On Wed, Nov 12, 2014 at 3:47 PM, Marko Rauhamaa wrote:
>> Asserts have nothing to do with them being optimized out. Asserts are
>> communication.
>>
>> Apart from idiomatic style, there is no difference between
>>
>> # never reached
>>
>> assert False
>>
>> raise Runtime
On 11/12/2014 4:02 PM, John Ladasky wrote:
I have taught Python to several students over the past few years. As
I have worked with my students, I find myself bothered by the
programming idiom that we use to determine whether a module is being
executed or merely imported:
"if __name__ == '__main
Chris Angelico :
> Or, in as many cases as possible, raise an implicit KeyError and save
> yourself a lot of typing. Any time these kinds of elif trees can be
> turned into dict lookups, you get non-assert error checking for free.
I agree that you shouldn't sprinkle asserts around the code. But
c
On Thu, Nov 13, 2014 at 10:19 AM, Terry Reedy wrote:
> Functions have an implicit 'return None' at the end (which, in CPython,
> become an explicit pair of bytecodes, even when the function already ends
> with return something'. The simplest proposal is that modules have an
> implicit "if __name_
On Thu, Nov 13, 2014 at 10:23 AM, Marko Rauhamaa wrote:
> However, the programmer could have played this frustration out already
> in his head and written:
>
> assert len(choices) > 0
> count = next_size / len(choices)
assert choices
count = next_size / len(choices)
Or even just:
coun
Chris Angelico :
> On Thu, Nov 13, 2014 at 10:23 AM, Marko Rauhamaa wrote:
>> However, the programmer could have played this frustration out already
>> in his head and written:
>>
>> assert len(choices) > 0
>> count = next_size / len(choices)
>
> assert choices
> count = next_size / len
On Wednesday, November 12, 2014 3:03:18 PM UTC-8, Ian wrote:
> On Wed, Nov 12, 2014 at 3:48 PM, Anton wrote:
> Sure, which is why you and I have both suggested raising a RuntimeError
> instead.
Yeah, I actually read it after sending my response :)
--
https://mail.python.org/mailman/listinfo/pyth
On 11/12/2014 6:26 PM, Chris Angelico wrote:
On Thu, Nov 13, 2014 at 10:19 AM, Terry Reedy wrote:
Functions have an implicit 'return None' at the end (which, in CPython,
become an explicit pair of bytecodes, even when the function already ends
with return something'. The simplest proposal is t
On Thu, Nov 13, 2014 at 11:35 AM, Terry Reedy wrote:
>> Safer - and more in line with the way
>> other such functions are written - would be a dunder function:
>>
>> if __name__ == '__main__': __main__()
>
>
> I presume you mean that calling __main__ implicitly would be both consistent
> and safer
Fabio Zadrozny wrote:
can someone from python-dev give some background of why
that's the way it is?
It's because, with new-style classes, a class is also an
instance (of class "type" or a subclass thereof). So
without that rule, it would be ambiguous whether a dunder
method applied to instances
In each revision of "getpeercert", a few more fields are returned.
Python 3.2 added "issuer" and "notBefore". Python 3.4 added
"crlDistributionPoints", "caIssuers", and OCSP URLS. But some fields
still aren't returned. I happen to need CertificatePolicies, which
is how you distinguish DV, OV, a
On 11/12/2014 08:39 PM, John Nagle wrote:
In each revision of "getpeercert", a few more fields are returned.
Python 3.2 added "issuer" and "notBefore". Python 3.4 added
"crlDistributionPoints", "caIssuers", and OCSP URLS. But some fields
still aren't returned. I happen to need CertificatePol
On 12Nov2014 14:51, Ian Kelly wrote:
On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor wrote:
A decorator is an interesting idea, and should be easy to implement (only
lightly tested): [...]
Just decorate the "main" function of the script with that, and it will be
automatically called when ran as
76 matches
Mail list logo
