Re: Expression can be simplified on list
On Thu, Sep 29, 2016 at 4:47 PM, Rustom Mody wrote:
>> Because True is the default, object need not and at least in CPython
>> does not have a __bool__ (or __len__) method. Classes with no falsey
>> objects, such as functions, generators, and codes, need not do anything
>> either. In the absence of an override function, the internal bool code
>> returns True.
>>
> Not sure what you are trying to say Terry...
> Your English suggests you disagree with me
> Your example is exactly what I am saying; if a type has a behavior in which
> all values are always True (true-ish) its a rather strange kind of
> bool-nature.
>
> Shall we say it has Buddha-nature? ;-)
There are a LOT of objects that are always true. Take this example:
class Employee:
def __init__(self, name):
self.name = name
self.boss = None
def report(self):
if self.boss:
self.boss.emit_report("I have done nothing.")
else:
company_board.proclaim("I have done everything.")
Every Employee object counts as true, and None counts as false. This
is the most normal way to write something. Unless an object represents
a collection, number, etc, that can meaningfully be "empty", it should
be assumed that it is true, and *the absence of an object* is what's
false.
Not every object has a sane representation of nothingness.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Expression can be simplified on list
On Thursday 29 September 2016 16:47, Rustom Mody wrote:
> On Thursday, September 15, 2016 at 1:43:05 AM UTC+5:30, Terry Reedy wrote:
[...]
>> Python make no such nonsense claim. By default, Python objects are truthy.
>>
>> >>> bool(object())
>> True
>>
>> Because True is the default, object need not and at least in CPython
>> does not have a __bool__ (or __len__) method. Classes with no falsey
>> objects, such as functions, generators, and codes, need not do anything
>> either. In the absence of an override function, the internal bool code
>> returns True.
>>
> Not sure what you are trying to say Terry...
> Your English suggests you disagree with me
> Your example is exactly what I am saying; if a type has a behavior in which
> all values are always True (true-ish) its a rather strange kind of
> bool-nature.
In what way do you think it is "rather strange"?
This suggests that you believe that all types must have distinct truthy values
and falsey values, or else that type's values shouldn't be usable in a truth
context at all. Is that what you mean?
My view is somewhat different. I see truthiness as an abstraction. Like all
abstractions, it may leak -- I make no apologies for the fact that Python
doesn't have syntactic support for Keene three-value logic or other multi-
valued logics, nor do I make any apologies for the (hypothetical, rare) object
which doesn't fit well into this truthy abstraction. All abstractions leak
somewhere, and this abstraction is proven to work well in practice, not
withstanding the rare glitch.
What is this truthiness abstraction? It is the difference between "something"
and "nothing".
Values which represent nothing, e.g.:
- None
- numeric zero: 0, 0.0, 0j, Decimal(0) etc
- empty strings u'', ''
- empty containers [], (), {} etc.
are treated as falsey. And values that represent something, e.g.:
- numbers other than zero
- strings other than the empty string
- non-empty containers
are treated as truthy. On this basis, by default objects should be considered
truthy: objects represent something rather than nothing:
- a module object is something;
- a function object is something;
- a HTTPServer object is something;
and so all of these things -- modules, functions, HTTPServers -- should default
to always truthy unless the programmer specifically programs them otherwise.
A few pre-emptive responses to possible objections:
Objection: There's only one sort of nothing.
Response: There are different kinds of nothing. "I have no shoes" is not the
same as "I have no feet". The hole in a donut is not the same as a hole in the
ground or an electron hole in a crystal lattice. The set of ideas held by
somebody who has no idea is not the same kind of nothingness as the nothingness
in a vacuum.
Objection: But nothing isn't nothing, it's something!
Response: You are committing the fallacy of reification. Just because you can
give a name to a concept doesn't make the concept a thing. "Cold" is not a
thing, it is just the absence of heat, "death" is the absence of life,
"stillness" is the absence of motion, and "nothing" is the absence of things,
not a thing itself. That's why there are different kinds of nothing -- it
depends which things get counted.
Objection: Even the vacuum is not empty! It is filled with a sea of virtual
particles and anti-particles and zero-point energy.
Response: I've studied quantum mechanics and particle physics too. You're very
clever. Do I really have to answer this one?
Objection: Yes.
Response: Okay.
The existence of zero-point energy is very interesting, but it has no relevance
to the topic we're discussing. In practical terms, most "zeroes" are relative
measures, not absolute. For an electrical analogy, think of electrical
potential: what matters is the potential difference, not the actual potential.
There's no current flowing between two points both at the same potential
energy. Similarly, we don't usually care about the *absolute* presence or
absence of things, but relative to some quantity or substance. A hole in the
ground is filled with air, or sometimes water, but we care only about the lack
of soil in the hole.
Objections: Empty containers aren't nothing, they are themselves a thing. An
empty egg carton is still an empty carton, even if there are no eggs in it.
Response: Indeed.
Nevertheless, the language designer gets to choose the specific model of
truthiness the language uses. In the opinion of the Python designer GvR, it is
more useful to care about the *content* of the container than the container
itself in a truth context. Some languages make other choices. If you don't like
Python's choice, you are free to:
- suck it up and live with it;
- fork Python and give the fork your preferred semantics;
- use another language which is a closer fit to your preferences;
- use your own container types with your preferred semantics;
- complain bitterly about it on your blog, Facebook wall, mailing li
Re: Using the Windows "embedded" distribution of Python
On Wednesday, 28 September 2016 21:50:54 UTC+1, eryk sun wrote: > On Wed, Sep 28, 2016 at 2:35 PM, Paul Moore wrote: > > So I thought I'd try SetDllDirectory. That works for python36.dll, but if I > > load > > python3.dll, it can't find Py_Main - the export shows as "(forwarded to > > python36.Py_Main)", maybe the forwarding doesn't handle SetDllDirectory? > > It works for me. Are you calling SetDllDirectory with the > fully-qualified path? If not it's relative to the working directory, > which isn't necessarily (generally is not) the application directory, > in which case delay-loading python36.dll will fail. You can create the > fully-qualified path from the application path, i.e. > GetModuleFileNameW(NULL, ...). That might be the issue. I was using a relative directory (I was being lazy for a quick test) but I was at the time in the right directory for the relative directory name to work. But I'll do a proper test today. > That said, I prefer using LoadLibraryExW(absolute_path_to_python3, > NULL, LOAD_WITH_ALTERED_SEARCH_PATH). The alternate search substitutes > the DLL's directory for the application directory when loading > dependent DLLs, which allows loading python36.dll and vcruntime140.dll > without having to modify the DLL search path of the entire process. That does indeed sound like a better idea. I had read the docs for LoadLibraryEx, but I must admit I got very muddled from the various options, and ended up going back to LoadLibrary because it seemed simpler :-( Thanks for the suggestions, Paul PS It's a shame there's no way to put the embedded distribution in a subdirectory *without* needing to use dynamic loading, but I guess that's basically an OS limitation. -- https://mail.python.org/mailman/listinfo/python-list
Re: Expression can be simplified on list
Steven D'Aprano writes:
[- -]
> What is this truthiness abstraction? It is the difference between
> "something" and "nothing".
>
> Values which represent nothing, e.g.:
>
> - None
> - numeric zero: 0, 0.0, 0j, Decimal(0) etc
> - empty strings u'', ''
> - empty containers [], (), {} etc.
>
> are treated as falsey. And values that represent something, e.g.:
[- -]
What do you say about things like iterators and generators? I'd say they
are containers, but they count as true even when they are empty.
bool(x for x in [3,1] if x in [2,7]) # True
list(x for x in [3,1] if x in [2,7]) # []
I think the abstraction really leaks on these things.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Expression can be simplified on list
On Thu, Sep 29, 2016 at 6:45 PM, Jussi Piitulainen wrote: > What do you say about things like iterators and generators? I'd say they > are containers, but they count as true even when they are empty. > > bool(x for x in [3,1] if x in [2,7]) # True > list(x for x in [3,1] if x in [2,7]) # [] > > I think the abstraction really leaks on these things. The problem is that there is no safe way to probe an iterator for emptiness other than to attempt to consume a value from it. How do you know if you're at the EOF of stdin? You ask the user to enter something, and see if s/he presses Ctrl-D (or Ctrl-Z). Until you wait on the user, EOF hasn't necessarily even happened yet. An iterator is not a container, but in many contexts, it can be treated as one. Truthiness is simply not one of those contexts, for reasons of extreme impracticality. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a way to change the closure of a python function?
On Thursday, September 29, 2016 at 7:13:15 PM UTC+13, Gregory Ewing wrote: > Philosophical question: Is a function that never > returns actually a function? Denotational semantics calls that value “bottom”. -- https://mail.python.org/mailman/listinfo/python-list
Re: Expression can be simplified on list
On Thursday, September 29, 2016 at 7:48:41 PM UTC+13, Rustom Mody wrote: > - And then uses a value of that type in a non-trivial bool-consuming position > such as the condition of an if/while etc > > There's a very good chance that bool-usage is buggy 👍 -- https://mail.python.org/mailman/listinfo/python-list
Re: Using the Windows "embedded" distribution of Python
On Thu, Sep 29, 2016 at 8:35 AM, Paul Moore wrote: > PS It's a shame there's no way to put the embedded distribution in a > subdirectory > *without* needing to use dynamic loading, but I guess that's basically an OS > limitation. There are ways to do this. The simplest way is to use a subdirectory with same name as the executable plus ".local". For example, for "app.exe" create a directory named "app.exe.local". -- https://mail.python.org/mailman/listinfo/python-list
Re: Expression can be simplified on list
On Thursday 29 September 2016 18:45, Jussi Piitulainen wrote:
> Steven D'Aprano writes:
>
> [- -]
>
>> What is this truthiness abstraction? It is the difference between
>> "something" and "nothing".
>>
>> Values which represent nothing, e.g.:
>>
>> - None
>> - numeric zero: 0, 0.0, 0j, Decimal(0) etc
>> - empty strings u'', ''
>> - empty containers [], (), {} etc.
>>
>> are treated as falsey. And values that represent something, e.g.:
>
> [- -]
>
> What do you say about things like iterators and generators? I'd say they
> are containers, but they count as true even when they are empty.
No, they aren't containers, because they don't support membership testing or
len(), as containers must.
But I agree the abstraction leaks. We would like empty iterables (iterators and
sequences) to be falsey, but the problem is, how do you know if an iterator is
empty without consuming a value from it? Sequences and containers can be probed
without consuming values, but iterators cannot be.
So although you can use them in many of the same places that you might use a
sequence or container, they aren't actually sequences or containers, and are
better treated as something like a function. (Except instead of calling them,
you pass them to next() to get the next value.)
And what are functions? Why, they're *things*, of course, and hence *something*
rather than nothing, even if they return None, or never return at all, or
crash. And so even though it is inconvenient, nevertheless it is logical for
iterators to always be truthy.
However, if you had a peekable iterator where you can peek ahead to see if they
are empty or not, then it might make sense to treat them as more like a
sequence than a function. But arbitrary iterators do not support a peek()
operation.
Either way, the abstraction leaks a bit. Never mind -- welcome to life as a
programmer.
--
Steven
git gets easier once you get the basic idea that branches are homeomorphic
endofunctors mapping submanifolds of a Hilbert space.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Using the Windows "embedded" distribution of Python
On Thursday, 29 September 2016 10:39:10 UTC+1, eryk sun wrote: > On Thu, Sep 29, 2016 at 8:35 AM, Paul Moore wrote: > > PS It's a shame there's no way to put the embedded distribution in a > > subdirectory > > *without* needing to use dynamic loading, but I guess that's basically an > > OS limitation. > > There are ways to do this. The simplest way is to use a subdirectory > with same name as the executable plus ".local". For example, for > "app.exe" create a directory named "app.exe.local". Oh, wow. Now you mention it, I recall that convention (from somewhere). I'll investigate that option (although it may not suit my use case, as I want multiple exes in the one "main" directory sharing a single "local" Python runtime). Many thanks, Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: how to automate java application in window using python
On Wednesday, September 28, 2016 at 8:00:09 PM UTC-4, Lawrence D’Oliveiro wrote: > On Thursday, September 29, 2016 at 11:54:46 AM UTC+13, Emile van Sebille > wrote: > > Which worked for me! You should try it. Sloppy programming has always > > been unreliable. > > So it is clear you don’t have an answer to the OP’s question after all. Just > some vague, meaningless generalities. This is just getting rude. Let's please drop it. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Expression can be simplified on list
On 2016-09-29 10:49, Steven D'Aprano wrote: On Thursday 29 September 2016 18:45, Jussi Piitulainen wrote: [snip] What do you say about things like iterators and generators? I'd say they are containers, but they count as true even when they are empty. No, they aren't containers, because they don't support membership testing or len(), as containers must. But I agree the abstraction leaks. We would like empty iterables (iterators and sequences) to be falsey, but the problem is, how do you know if an iterator is empty without consuming a value from it? Sequences and containers can be probed without consuming values, but iterators cannot be. So although you can use them in many of the same places that you might use a sequence or container, they aren't actually sequences or containers, and are better treated as something like a function. (Except instead of calling them, you pass them to next() to get the next value.) And what are functions? Why, they're *things*, of course, and hence *something* rather than nothing, even if they return None, or never return at all, or crash. And so even though it is inconvenient, nevertheless it is logical for iterators to always be truthy. However, if you had a peekable iterator where you can peek ahead to see if they are empty or not, then it might make sense to treat them as more like a sequence than a function. But arbitrary iterators do not support a peek() operation. Either way, the abstraction leaks a bit. Never mind -- welcome to life as a programmer. What if an _exhausted_ iterator was falsey? -- https://mail.python.org/mailman/listinfo/python-list
Re: Using the Windows "embedded" distribution of Python
On Thu, Sep 29, 2016 at 10:41 AM, Paul Moore wrote: > On Thursday, 29 September 2016 10:39:10 UTC+1, eryk sun wrote: >> On Thu, Sep 29, 2016 at 8:35 AM, Paul Moore wrote: >> > PS It's a shame there's no way to put the embedded distribution in a >> > subdirectory >> > *without* needing to use dynamic loading, but I guess that's basically an >> > OS limitation. >> >> There are ways to do this. The simplest way is to use a subdirectory >> with same name as the executable plus ".local". For example, for >> "app.exe" create a directory named "app.exe.local". > > Oh, wow. Now you mention it, I recall that convention (from somewhere). I'll > investigate that option (although it may not suit my use case, as I want > multiple exes > in the one "main" directory sharing a single "local" Python runtime). In that case you can use an application manifest with a dependent assembly. Say embedded Python 3.6 is in the "py3embed" subdirectory. Add the following manifest file to that directory: py3embed.manifest: Add this assembly as a dependency in the application manifest, either embedded in the executable (resource #1) or as a separate file named the same as the executable plus ".manifest", e.g. "app.exe.manifest". You can start with the manifest that's used by python.exe, from PC\python.manifest. -- https://mail.python.org/mailman/listinfo/python-list
Re: Expression can be simplified on list
MRAB wrote:
> What if an _exhausted_ iterator was falsey?
Many would expect
it = iter("abc")
while it:
print(next(it))
to work (i. e. no StopIteration) -- if it doesn't, what's the actual
usecase?
If it does work there must be some lookahead which not all iterators can
provide in a meaningful way:
it = iter(time.time, None)
while it:
time.sleep(...)
print("Now", next(it))
--
https://mail.python.org/mailman/listinfo/python-list
problemes
bonjour je n'arrive plus a me connecter au script doA-Tools alors que celui si fonctionnait bien. la fenêtre reste noir et rien ne se passe merci de votre aide -- https://mail.python.org/mailman/listinfo/python-list
Re: Using the Windows "embedded" distribution of Python
On Thursday, 29 September 2016 12:56:28 UTC+1, eryk sun wrote: >> Oh, wow. Now you mention it, I recall that convention (from somewhere). >> >> I'll investigate that option (although it may not suit my use case, as >> I want multiple exes in the one "main" directory sharing a single >> "local" Python runtime). > > In that case you can use an application manifest with a dependent > assembly. Say embedded Python 3.6 is in the "py3embed" subdirectory. > Add the following manifest file to that directory: > > py3embed.manifest: > > > >version="3.6.111.1013" > type="win32" > processorArchitecture="amd64" /> > > > > Cool. So this is all the SxS stuff that I never really understood, right? :-) I guess I can assume from this: 1. The filename py3embed.manifest isn't relevant (you explain file naming below). 2. assemblyIdentity name="py3embed" is what says to look in a subdirectory "py3embed" that's located next to the executable. 3. The "version" in the manifest doesn't really matter much. 4. I only need to name python3.dll, python36.dll and vcruntime140.dll as these are the only DLLs loaded statically? > Add this assembly as a dependency in the application manifest, either > embedded in the executable (resource #1) or as a separate file named > the same as the executable plus ".manifest", e.g. "app.exe.manifest". Using a separate file seems easiest (and certainly the way to go for testing) but I'm not sure how I'd embed the manifest using command line tools. I'm leveraging distutils to build my exe at the moment: from distutils.ccompiler import new_compiler import distutils.sysconfig import sys import os cc = new_compiler() exe = 'myapp' cc.add_include_dir(distutils.sysconfig.get_python_inc()) cc.add_library_dir(os.path.join(sys.base_exec_prefix, 'libs')) objs = cc.compile(['myapp.c']) cc.link_executable(objs, exe) But the ccompiler interface doesn't have anything to add in a resource or manifest, so I think I'm going to need to switch to using the command line directly for this. > You can start with the manifest that's used by python.exe, from > PC\python.manifest. > > > >version="3.6.111.1013" > type="win32" > processorArchitecture="amd64" /> > > Thanks for your help on this. My C skills are *very* rusty (going much beyond "cl /c foo.c" sends me to the manuals these days) so I appreciate all the help. I'm off now to do a whole load of experimenting - you've given me a lot to work with :-) Paul. PS Is there any readable documentation on the SxS stuff anywhere, written for C programmers? Microsoft's docs have always seemed to me to assume I know a bunch of .NET concepts that I really don't know much about... -- https://mail.python.org/mailman/listinfo/python-list
ANN: dedent 0.5 released
Dedent 0.5 == What is it? --- Dedent is a very simple tool for those people who like to indent their inline code nicely. For those who got already what it is, stop reading. :-) All the others: What is it, really? --- Ok, think of some inline Python code, something like $ python -c """some code""" For very simple scripts, there is nothing wrong with it. But for inline code over several lines, things become ugly: $ python -c """ "The problem is that you have to start your" "script very much on the left, although you" "would probably like to indent it somehow." One very ugly solution are constructs like """if True: "now I may indent the code" """ This becomes even more ugly if you have to use the __future__ statement, which always must come first! Now, here is what dedent does for you, simply that, not less and not more: $ python -m dedent """ from __future__ import print_function "now I can really indent my code, because" "the dedent module takes care of the indent," "and that was my intent. :-)" """ Installation $ pip install dedent That's all, folks! Have fun. p.s.: Why is that not build in by default? -- Christian Tismer :^) tis...@stackless.com Software Consulting : http://www.stackless.com/ Karl-Liebknecht-Str. 121 : https://github.com/PySide 14482 Potsdam: GPG key -> 0xFB7BEE0E phone +49 173 24 18 776 fax +49 (30) 700143-0023 -- https://mail.python.org/mailman/listinfo/python-list
SOAP XML webserver in Python/Django
Hi All, I currently have a need to setup a webserver on one of our internal servers that is going to send and receive XML SOAP responses to an external company through a VPN. It seems like something that I could use python (maybe even Django) for. However, even though I have been using Python and Django for a while now, I am unsure of whether this is a good idea to implement, since there seems to be some question about whether there are good maintained libraries to use and I am unfamiliar with if there are added complexities with SOAP that I have to deal with. It looks like pretty standard XML to me wrapped in an extra layer of meta data. http://stackoverflow.com/questions/206154/what-soap-client-libraries-exist-for-python-and-where-is-the-documentation-for?rq=1 Any thoughts would be appreciated. Also, any good Python based job boards in the Toronto area would be greatly appreciated too. Regards Ivan -- https://mail.python.org/mailman/listinfo/python-list
Abusive Italian Spam
You may have noticed one or two more of the abusive spam messages slip through onto the list. We do have traps for these but, as with most such things, they need tuning. (We've discarded many more than you've seen). As ever, kudos to Mark Sapiro of the Mailman team for tweaking our custom filters and sorting out the archives in a timely fashion. TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: Expression can be simplified on list
On Thu, 29 Sep 2016 09:53 pm, MRAB wrote: > What if an _exhausted_ iterator was falsey? The problem is that in general you can't tell if an iterator is exhausted until you attempt to advance it. So even if bool(iterator) returns True, the call to next() may raise StopIteration: def gen(): yield 1 it = gen() bool(it) # returns True next(it) # returns a value, as expected, exhausting the iterator bool(it) # still returns True even though its exhausted next(it) # raises StopIteration bool(it) # finally we know the iterator is exhausted Again, the problem is the lack of a way for the iterator to peek ahead and see whether or not there is anything remaining. *We* can see that it is exhausted by reading the source code and predicting what will happen on the subsequent call to next(), but the interpreter cannot do that. And sometimes not even we can predict the state of the iterator: def gen(): if random.random() < 0.5: yield 1 it = gen() Is it exhausted or not? -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Expression can be simplified on list
On 2016-09-29 16:56, Steve D'Aprano wrote: On Thu, 29 Sep 2016 09:53 pm, MRAB wrote: What if an _exhausted_ iterator was falsey? The problem is that in general you can't tell if an iterator is exhausted until you attempt to advance it. So even if bool(iterator) returns True, the call to next() may raise StopIteration: [snip] By "exhausted" I meant "has previously raised StopIteration". -- https://mail.python.org/mailman/listinfo/python-list
Re: Expression can be simplified on list
On Fri, Sep 30, 2016 at 2:36 AM, MRAB wrote: > On 2016-09-29 16:56, Steve D'Aprano wrote: >> >> On Thu, 29 Sep 2016 09:53 pm, MRAB wrote: >> >>> What if an _exhausted_ iterator was falsey? >> >> >> >> The problem is that in general you can't tell if an iterator is exhausted >> until you attempt to advance it. So even if bool(iterator) returns True, >> the call to next() may raise StopIteration: >> > [snip] > > By "exhausted" I meant "has previously raised StopIteration". I'm not sure how useful that'd be, especially given that some iterators actually violate the normal rule of "once you raise, you raise thereafter". But it's not hard to wrap. class Iterator: def __init__(self, it): self.iter = iter(it) self.exhausted = False def __iter__(self): return self def __next__(self): try: return next(self.iter) except StopIteration: # or just 'except:'? self.exhausted = True raise def __bool__(self): return self.exhausted Then you have the edge cases. If next() raises something other than StopIteration, does that mark the iterator as exhausted? Should the exhausted flag be cleared if a naughty iterator yields a value after having StoppedIteration? (Also, you'd probably want to have some code in here to detect if it's working with a generator, and if so, pass send/throw down the line too. Omitted for simplicity.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Expression can be simplified on list
On 2016-09-29 09:14, Steven D'Aprano wrote: On Thursday 29 September 2016 16:47, Rustom Mody wrote: On Thursday, September 15, 2016 at 1:43:05 AM UTC+5:30, Terry Reedy wrote: [...] Python make no such nonsense claim. By default, Python objects are truthy. >>> bool(object()) True Because True is the default, object need not and at least in CPython does not have a __bool__ (or __len__) method. Classes with no falsey objects, such as functions, generators, and codes, need not do anything either. In the absence of an override function, the internal bool code returns True. Not sure what you are trying to say Terry... Your English suggests you disagree with me Your example is exactly what I am saying; if a type has a behavior in which all values are always True (true-ish) its a rather strange kind of bool-nature. In what way do you think it is "rather strange"? This suggests that you believe that all types must have distinct truthy values and falsey values, or else that type's values shouldn't be usable in a truth context at all. Is that what you mean? My view is somewhat different. I see truthiness as an abstraction. Like all abstractions, it may leak -- I make no apologies for the fact that Python doesn't have syntactic support for Keene three-value logic or other multi- valued logics, nor do I make any apologies for the (hypothetical, rare) object which doesn't fit well into this truthy abstraction. All abstractions leak somewhere, and this abstraction is proven to work well in practice, not withstanding the rare glitch. [snip] When re.search or re.match succeed, they return a match object, which is truey; when they fail, then return None, which is falsey. That's convenient. -- https://mail.python.org/mailman/listinfo/python-list
Re: Expression can be simplified on list
On 9/29/2016 12:36 PM, MRAB wrote: On 2016-09-29 16:56, Steve D'Aprano wrote: On Thu, 29 Sep 2016 09:53 pm, MRAB wrote: What if an _exhausted_ iterator was falsey? Logic is about binary distinctions, rather than about 'truth'. For non-buggy iterator it, the useful binary distinction is whether next(it) returns an object, the truthy action, or raises StopIteration, the falsey action. The for loop machinery converts this binary action distinction into another binary action distinction: execute the suite and call next again versus proceed to the else clause if there is one or do nothing. In other words, for loops indeed treat an exhausted iterator as falsey. The problem is that in general you can't tell if an iterator is exhausted until you attempt to advance it. So even if bool(iterator) returns True, the call to next() may raise StopIteration: [snip] By "exhausted" I meant "has previously raised StopIteration". The iterator protocol could have required that iterators have 'self._bval = True' in .__init__, method 'def __bool__(self): return self._bval, and 'self._bval = False' in .__next__ just prior to 'raise StopIteration'. However, the iterator protocol is intentionally as simple as possible and the extra baggage would nearly always be useless. If you use a non-iterator iterable in a for statement, the temporary iterator is discarded as soon as it raises StopIteration. If you pass an iterator to a function that iterates, you likely created it on the fly as an expression, and it will be discarded when the function returns. If you do have a reference, you can (and perhaps should) delete it after the function returns. Still, if one has a specialized use-case for iterables with the extra baggage, one can create them as instances of the following wrapper. class BoolIter: def __init__(self, iterable): self._it = iter(iterable) self._bval = True def __iter__(self): return self def __bool__(self): return self._bval def __next__(self): try: return next(self._it) except StopIteration: self._bval = False raise -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: how to automate java application in window using python
On Thursday, September 29, 2016 at 11:46:59 PM UTC+13, Ned Batchelder wrote: > This is just getting rude. Let's please drop it. Do you have anything substantive to contribute? (... crickets ...) -- https://mail.python.org/mailman/listinfo/python-list
unintuitive for-loop behavior
hello pythonistas i've had a nodding acquaintance with python for some time, and all along i assumed that for-loops got a namespace of their own; now i'm reading up on the language and i find out that's not the case: the loop variable gets put into the enclosing namespace, overwriting any former value that was already there; of course i realize there are situations where one is interested in the value that a loop variable has after the loop has been exited, but this behavior seems grossly unintuitive to me: has there ever been any discussion of giving for-loops the option of running in namespaces of their own? and it gets even worse; consider the following means of raising an exception: #)-- begin code def powerfunction(exponent): return lambda base: (base ** exponent) p1 = [powerfunction(exponent) for exponent in range(9)] p2 = [lambda base: (base ** exponent) for exponent in range(9)] assert p1[3](4) == p2[3](4) #) end code apparently the problem is that "exponent" gets evaluated when the relevant lambda function is run, not when it's defined, but no binding for "exponent" gets put into the enclosing namespace: it seems that python remembers this ghostly "exponent" for me on the theory that i don't WANT "p1" and "p2" to be the same; can anyone help to reconcile me to this semantics? thanks if you can help stm -- https://mail.python.org/mailman/listinfo/python-list
Re: Expression can be simplified on list
On 9/29/2016 2:47 AM, Rustom Mody wrote: On Thursday, September 15, 2016 at 1:43:05 AM UTC+5:30, Terry Reedy wrote: On 9/14/2016 3:16 AM, Rustom Mody wrote: In THOSE TYPES that element can justifiably serve as a falsey (empty) type However to extrapolate from here and believe that ALL TYPES can have a falsey value meaningfully, especially in some obvious fashion, is mathematically nonsense. There is no end to possible nonsensical extrapolations. I presume you had a reason to point out this one. Python make no such nonsense claim. By default, Python objects are truthy. >>> bool(object()) True Because True is the default, object need not and at least in CPython does not have a __bool__ (or __len__) method. Classes with no falsey objects, such as functions, generators, and codes, need not do anything either. In the absence of an override function, the internal bool code returns True. Not sure what you are trying to say Terry... I reported how CPython's bool works, after doing some experiments. Your English suggests you disagree with me I disagree with a possible implication of your statement, that Python bools are based on a nonsensical belief. It does not matter much to what I said whether you intended that implication or not. Your example is exactly what I am saying; if a type has a behavior in which all values are always True (true-ish) its a rather strange kind of bool-nature. Your conclusion from the examples is slightly different from mine. It is up to particular classes to override that default and say that it has one or more Falsey objects. They do so by defining a __bool__ method that returns False for the falsey objects (and True otherwise) or by defining a __len__ method that returns int 0 for falsey objects (and non-0 ints otherwise). If a class defines both, __bool__ wins. More reporting on how CPython works, based on experiments. For the last statement, I tried giving a class contradictory methods. Sure one can always (ok usually) avoid a bug in a system by not using the feature that calls up the bug. Are you suggesting that that makes the bug non-exist? By 'bug', you here mean 'design bug', as opposed to 'implementation bug'. Design bugs are in the eyes of beholders. Here, we behold differently. Logic is about binary predicates/partitions/decisions. Bool allows a class to define a default partition for use in conditional expressions by defining a __bool__ method. In more detail: - If user/programmer defines a new type - Which has no dunder bool - Which has no dunder len A subclass of such a class might add either of those methods. Indeed, 'object' is such a class and *some* subclasse* do add one or the other. Or, with duck-typing, the class might part of a function domain that does include partitioned classes. - And then uses a value of that type in a non-trivial bool-consuming position such as the condition of an if/while etc There's a very good chance that bool-usage is buggy I agree that 'if self' when self is essentially guaranteed to be truthy is bad coding. Redundant or dead code may be a bad idea, but is not buggy in itself in the usual sense. Why not default it in the way that AttributeError/NameError/TypeError etc are raised? Try - except and exceptions are an alternate flow system that partition the behavior of functions + arguments. It would be annoying to mix the two and require (most) every if and while statement to be embedded in try - except. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: unintuitive for-loop behavior
Yes, loops don't have their own scope. Indeed, very few flow elements in python -- if, with, try/except -- create a new scope. In that sense, it's fairly consistent, but can be unexpected for people that have used languages with many nested scopes. The lambda behavior is a common gotcha - there are hundreds of questions on StackOverflow that are caused by that misunderstanding http://stackoverflow.com/questions/7368522/weird-behavior-lambda-inside-list-comprehension The most common solution is to just provide the variable as a default argument to the lambda function, which will bind it how you'd expect [lambda base, exponent=exponent: (base ** exponent) for exponent in range(9)] On Thu, Sep 29, 2016 at 12:29 PM, wrote: > hello pythonistas > > i've had a nodding acquaintance with python for some time, and all along i > assumed that for-loops got a namespace of their own; now i'm reading up on > the language and i find out that's not the case: the loop variable gets put > into the enclosing namespace, overwriting any former value that was already > there; of course i realize there are situations where one is interested in > the value that a loop variable has after the loop has been exited, but this > behavior seems grossly unintuitive to me: has there ever been any > discussion of giving for-loops the option of running in namespaces of their > own? > > and it gets even worse; consider the following means of raising an > exception: > > #)-- begin code > > def powerfunction(exponent): > return lambda base: (base ** exponent) > > p1 = [powerfunction(exponent) for exponent in range(9)] > p2 = [lambda base: (base ** exponent) for exponent in range(9)] > > assert p1[3](4) == p2[3](4) > > #) end code > > apparently the problem is that "exponent" gets evaluated when the relevant > lambda function is run, not when it's defined, but no binding for > "exponent" gets put into the enclosing namespace: it seems that python > remembers this ghostly "exponent" for me on the theory that i don't WANT > "p1" and "p2" to be the same; can anyone help to reconcile me to this > semantics? > > thanks if you can help > stm > > > > > > > > > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Expression can be simplified on list
On Thu, Sep 29, 2016, at 02:47, Rustom Mody wrote: > Your example is exactly what I am saying; if a type has a behavior in > which all values are always True (true-ish) its a rather strange kind > of bool-nature. For a given type T, if all objects of type T are true (true-ish, truthy, whatever), it does make using an expression of type T in an if-statement an incoherent thing to do, but it makes using an expression of type Union[T, NoneType] reasonable. -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: dedent 0.5 released
Christian Tismer writes: > Dedent 0.5 > == > > What is it? > --- > > Dedent is a very simple tool for those people who like to > indent their inline code nicely. > > p.s.: Why is that not build in by default? Isn't it roughly the same as https://docs.python.org/3.6/library/textwrap.html#textwrap.dedent ? ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. l...@metapensiero.it | -- Fortunato Depero, 1929. -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: dedent 0.5 released
On 29/09/16 22:14, Lele Gaifax wrote: Christian Tismer writes: Dedent 0.5 == What is it? --- Dedent is a very simple tool for those people who like to indent their inline code nicely. p.s.: Why is that not build in by default? Isn't it roughly the same as https://docs.python.org/3.6/library/textwrap.html#textwrap.dedent ? Yes, it actually uses the dedent function. They just failed to expose it. Cheers - Chris -- Christian Tismer :^) tis...@stackless.com Software Consulting : http://www.stackless.com/ Karl-Liebknecht-Str. 121 : https://github.com/PySide 14482 Potsdam: GPG key -> 0xFB7BEE0E phone +49 173 24 18 776 fax +49 (30) 700143-0023 -- https://mail.python.org/mailman/listinfo/python-list
Re: Expression can be simplified on list
On Fri, Sep 30, 2016 at 5:58 AM, Random832 wrote: > On Thu, Sep 29, 2016, at 02:47, Rustom Mody wrote: >> Your example is exactly what I am saying; if a type has a behavior in >> which all values are always True (true-ish) its a rather strange kind >> of bool-nature. > > For a given type T, if all objects of type T are true (true-ish, truthy, > whatever), it does make using an expression of type T in an if-statement > an incoherent thing to do, but it makes using an expression of type > Union[T, NoneType] reasonable. Or, as it would more commonly be spelled, Optional[T]. Very common situation; re.match was mentioned, and lots of data types can be clearly demonstrated by implementing them in Python using some kind of "optional node" structure - eg a linked list, where the last one has "self.next = None", or a binary tree where leaf nodes have None for both children, or a hash table where empty buckets have None. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Getting IDLE to use correct Tcl/Tk on MacOSX 10.6?
On 2016-09-27 18:47, Gregory Ewing wrote: > I don't normally use IDLE, but I had occasion to use it > on MacOSX 10.6 to answer someone's question, and of course > it didn't work properly due to Apple's broken Tcl/Tk. > > I followed the advice to install ActiveState Tcl 8.5.18.0, > but my Python still wants to use Apple's Tcl. > > How do I persuade Python to use the new one I've installed? > It's a framework install of Python 3.5 that I compiled > myself. Do I need to rebuild it to get it to pick up the > right Tcl? Or is there an environment variable I can set? As you probably know, on OS X the dynamic load library paths linked into executables and the like are normally absolute paths. This applies to _tkinter.so. You can check the path with otool -L. $ python3.5 -c "import _tkinter; print(_tkinter.__file__)" /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/_tkinter.cpython-35m-darwin.so $ otool -L $(python3.5 -c "import _tkinter; print(_tkinter.__file__)") /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/_tkinter.cpython-35m-darwin.so: /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl (compatibility version 8.5.0, current version 8.5.18) /Library/Frameworks/Tk.framework/Versions/8.5/Tk (compatibility version 8.5.0, current version 8.5.18) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0) The ActiveState Tcl/Tk frameworks are installed in /Library/Frameworks; your _tkinter was linked with the Apple-supplied versions in /System/Library/Frameworks. If you rebuild _tkinter after the new versions are in /Library/Frameworks, everything should be just fine, since, by default, /Library/Frameworks is searched at link time before /System/Library/Frameworks. You could also override the search order at run time for all frameworks with: DYLD_FRAMEWORK_PATH=/Library/Frameworks See man dyld for more info. Or you might be able to use install_name_tool to modify the path to the framework. -- https://mail.python.org/mailman/listinfo/python-list
Re: unintuitive for-loop behavior
On Fri, Sep 30, 2016 at 5:29 AM, wrote:
> i've had a nodding acquaintance with python for some time, and all along i
> assumed that for-loops got a namespace of their own; now i'm reading up on
> the language and i find out that's not the case: the loop variable gets put
> into the enclosing namespace, overwriting any former value that was already
> there; of course i realize there are situations where one is interested in
> the value that a loop variable has after the loop has been exited, but this
> behavior seems grossly unintuitive to me: has there ever been any discussion
> of giving for-loops the option of running in namespaces of their own?
>
No, there hasn't. In Python, there are no sub-function scopes - even
the couple of cases that look like subscopes (list comps and genexps)
are actually implemented as nested functions (fairly obvious in the
case of a genexp, more subtle with the list comp). C-like languages
can have infinitely nested scopes because they have variable
declarations:
int some_func() {
int foo;
for (...) {
if (whatever) {
foo = 1234;
} else {
foo = 2345;
}
use(foo);
}
}
The placement of 'int foo;' determines the scope of that name. Python
doesn't have that, so your options are:
1) The first assignment to a name determines its scope. That would
mean that the two assignments are in different scopes, and use(foo) is
not included. To solve this, you'd need a dummy assignment further up
(eg where "int foo" is) - not impossible but probably annoying.
2) Have a single and simple scoping rule, like "anything that's
assigned to is function-local".
Python chose the second option. Anything you assign to is local to the
function, but nothing narrower. There is no way [1] to have a local
name in a function AND use a global with the same name, even in
different parts of the function. Since a 'for' loop is assignment
("for X in Y" assigns to X), that name has to be function-scoped. You
could, in theory, have the name be unbound after the loop, but it's
usually not beneficial to do so, and can be detrimental.
ChrisA
[1] Well, you can use globals(), but that's not quite the same thing
as variable scope.
--
https://mail.python.org/mailman/listinfo/python-list
Re: how to automate java application in window using python
On Fri, Sep 30, 2016 at 5:18 AM, Lawrence D’Oliveiro wrote: > On Thursday, September 29, 2016 at 11:46:59 PM UTC+13, Ned Batchelder wrote: >> This is just getting rude. Let's please drop it. > > Do you have anything substantive to contribute? Yes. He contributed the guiding hand of "please keep it polite". If you don't think that's substantive, go have a look at a completely unmoderated discussion group, then at a well-led community, and see how much more pleasant it is in one than the other. Please don't be unnecessarily rude to people. Arguing back and forth "Windows is terrible", "But I have tools that work just fine on Windows", "GUIs suck", "No they don't", "You can't automate stuff on Windows", "Yes you can", etc, etc, is not going to get anyone anywhere, and it just makes everything unpleasant. Thanks. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: how to automate java application in window using python
On Fri, 30 Sep 2016 05:18 am, Lawrence D’Oliveiro wrote: > On Thursday, September 29, 2016 at 11:46:59 PM UTC+13, Ned Batchelder > wrote: >> This is just getting rude. Let's please drop it. > > Do you have anything substantive to contribute? Infinitely more than you. *plonk* -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Expression can be simplified on list
On Fri, 30 Sep 2016 05:58 am, Random832 wrote: > On Thu, Sep 29, 2016, at 02:47, Rustom Mody wrote: >> Your example is exactly what I am saying; if a type has a behavior in >> which all values are always True (true-ish) its a rather strange kind >> of bool-nature. > > For a given type T, if all objects of type T are true (true-ish, truthy, > whatever), it does make using an expression of type T in an if-statement > an incoherent thing to do, but it makes using an expression of type > Union[T, NoneType] reasonable. Or Union[T, S] where S is some other type (including a union of multiple types) which has at least one falsey value. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: how to automate java application in window using python
On 09/29/2016 01:18 PM, Lawrence D’Oliveiro wrote: > On Thursday, September 29, 2016 at 11:46:59 PM UTC+13, Ned Batchelder wrote: >> This is just getting rude. Let's please drop it. > > Do you have anything substantive to contribute? He's already contributed far more to this list, and to Python, than you have, and he has for years. You apparently have nothing constructive to contribute to this topic yet you can't resist posting and criticizing when people who might have some small contribution try to post. As much as I hate to say it, plonk. -- https://mail.python.org/mailman/listinfo/python-list
Python grammar extension via encoding (pyxl style) questions
Hi everybody! We’re building an experimental extension to Python, we’re extending Python’s comprehensions into a full-scale query language. And we’d love to use the trick that was done in pyxl, where a special encoding of the file will trigger the preprocessor to run and compile our extended language into Python and execute it. The actual encoding business is a bit tricky, but we also really really would like the whole thing to be installable via pip, otherwise only a tiny percentage of our potential users (we're targeting data scientists) would go through the pain of installing the extension. So I have some question, would really appreciate any help: - Are there any resources to get up the speed on custom encodings? The pyxl code looks fine, just not clear what some of the steps are. - We’d love to have a pip install for our module, but even pyxl didn't do it (i.e. you clone the repository, then do a local pip install, and then run a script). Is it impossible to just do it all with pip? Would it be a terrible/horrible hack? Any hints on how to do this? - Last question - we’d love to enable support for our extension in interactive python and especially in Jupyter notebooks. Would you have any advise on how to approach these? Thanks in advance! Pavel Velikhov P.S. Here's the demo site for our project,if you're interested: www.pythonql.org -- https://mail.python.org/mailman/listinfo/python-list
Re: unintuitive for-loop behavior
namenobodywa...@gmail.com wrote: > can anyone help to reconcile me to this semantics? Not really. Most people agree that it's not desirable behaviour, but we've ended up here due to a convoluted history, and there doesn't seem to be a good way to fix it without breaking a lot of existing code. Chris Angelico wrote: You could, in theory, have the name be unbound after the loop, but it's usually not beneficial to do so, and can be detrimental. It also wouldn't help at all with this problem. There *is* something that could be done, at least in CPython: if the loop variable is referenced by a nested function, then create a new cell for it each time round the loop, instead of updating the contents of the existing cell. This would be backwards-compatible in almost all cases. The last value would still be accessible after the loop finishes, and other assignments to the loop variable in the same function would work the same way as always. Guido doesn't like this idea, though, because it depends on CPython implementation details, and other Python implementations could have trouble matching these semantics. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: unintuitive for-loop behavior
On Friday, September 30, 2016 at 10:23:31 AM UTC+5:30, Gregory Ewing wrote: > namenobodywants wrote: > > can anyone help to reconcile me to this semantics? > > Not really. Most people agree that it's not desirable > behaviour, but we've ended up here due to a convoluted > history, and there doesn't seem to be a good way to > fix it without breaking a lot of existing code. Thanks for an unusually helpful answer. In my experience telling a beginner: «This» is a misfeature/gotcha And «this» is its workaround greatly shortens the learning curve as compared to long-winded justificatory explanations -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: dedent 0.5 released
Christian Tismer wrote: > $ python -c """some code""" totally offtopic but... since when bash support python-style triple quote?? Is it another shell?? -- By ZeD -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: dedent 0.5 released
Vito De Tullio writes: > Christian Tismer wrote: > >> $ python -c """some code""" > > totally offtopic but... since when bash support python-style triple > quote?? Is it another shell?? Bash allows any odd number of quotes on each side. -- https://mail.python.org/mailman/listinfo/python-list
filesystem encoding 'strict' on Windows
the doc of os.fsencode(filename) says Encode filename to the filesystem encoding 'strict' on Windows, what does 'strict' mean ? -- https://mail.python.org/mailman/listinfo/python-list
Re: SOAP XML webserver in Python/Django
ivan77 writes: > I currently have a need to setup a webserver on one of our internal servers > that is going to send and receive XML SOAP responses to an external company > through a VPN. > > It seems like something that I could use python (maybe even Django) for. > However, even though I have been using Python and Django for a while now, I > am unsure of whether this is a good idea to implement, since there seems to > be some question about whether there are good maintained libraries to use and > I am unfamiliar with if there are added complexities with SOAP that I have to > deal with. It looks like pretty standard XML to me wrapped in an extra layer > of meta data. > > http://stackoverflow.com/questions/206154/what-soap-client-libraries-exist-for-python-and-where-is-the-documentation-for?rq=1 > You may have a look at "spyne". It can generate WSDL 1.1 interface descriptions and supports SOAP 1.1 (among others). Its maintainer (burak.arslan) is very active and reacts quickly to problems and questions (in the "s...@python.org" or "peo...@spyne.io" mailing lists). A look at "PyPI" seems to indicate, that there are solutions which facilitate using "django" as a SOAP server (e.g. "https://pypi.python.org/pypi/django-soap-server/0.0.0";). -- https://mail.python.org/mailman/listinfo/python-list
Re: [py 2.7] JSON and UTF-8
Gilmeh Serda writes:
> Is there something that can be done when writing JSON using its dump/
> dumps feature so, e.g. Cyrillic text will show up correctly in a text
> editor afterwards?
> ...
> The 'template.json' contains this:
>
> {
> "test": "øæßþåнайтеĦŒŒ®®®"
> }
>
> What the json module outputs to the 'output.json' file is:
>
> {"test": "\u00f8\u00e6\u00df\u00fe\u00e5\u043d\u0430\u0439\u0442\u0435
> \u0126\u0152\u0152\u00ae\u00ae\u00ae"}
>
> But I would really like to be able to read that.
The "dumps" function has a parameter which allows the use
of unicode (instead of ascii encoded) strings.
Likely, using this parameter will solve your problem.
I have found out that some browsers have problems with some
unicode characters. Maybe, this is one reason to have
ascii encoded strings the default for "dumps".
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to make a copy of chained dicts effectively and nicely?
On Wed, Sep 28, 2016 at 12:54 AM, Jussi Piitulainen > wrote: >> I wasn't sure if it makes a copy or just returns the dict. But it's >> true: help(dict) says dict(mapping) is a "new dictionary initialized >> from a mapping object's (key, value) pairs". > Yep. With mutable objects, Python's docs are usually pretty clear that > you get a brand-new object every time: In that case, this seems to be the cleanest and most effective. (Sorry for the late answer) -- https://mail.python.org/mailman/listinfo/python-list
