Re: Suggestion: make sequence and map interfaces more similar
Op 31-03-16 om 04:40 schreef Steven D'Aprano: > On Thu, 31 Mar 2016 06:07 am, Antoon Pardon wrote: > >>> Because fundamentally, it doesn't matter whether dicts are surjections or >>> not. They're still many-to-one mappings, and those mappings between keys >>> and values should not change due to the insertion or deletion of >>> unrelated keys. >> Repeating your opion without further arguments doesn't lend any support >> to that opinion. If within the problem space you are working on, such a >> change would make sense as a step to generate the next mapping from the >> previous one, i don't see what the problem is if one could make use of >> this. > > Enough of the hypothetical arguments about what one could do or might do. > Let's see a concrete example of actual real world code used in production, > not a mickey-mouse toy program, where it is desirable that adding or > deleting one key will modify the rest of the keys in the mapping. I am not going to humour your petitio principii. If you want to argue against such a adjustment on the ground of some characteristics mappings should have, you have to make your case yourself and not try to shift the burden onto the person who has his doubt about your argument. If you continously stress the adaption will loose the stability of mappings and so suggest this is somehow a problem it is your burden to argue that problem. > Arguing for the sake of arguing about what somebody might want is not > productive. Let's see some actual concrete use cases where you have a > database or mapping between keys and values, say something like this: Arguing by just calling attention to a specific characteristic but not giving any reason why it would be bad if people were allowed to use a mapping in a way that violated this characteristic, is not productive either. If you try to argue a principle problem with the proposal, you have to support that and not try to shift the attention to there being no use case for the moment. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Interpreter not selected
Hello Team, I have installed Python 3.5.1 and now trying to install pycharm, but its not selecting the interpreter and getting the below error all the time. [image: Inline image 1] Quick help will be really appreciated. -- Thanks & Regards Siddiq -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
Op 31-03-16 om 04:44 schreef Steven D'Aprano:
> On Thu, 31 Mar 2016 03:52 am, Random832 wrote:
>
>> Like, these are common patterns:
>>
>> for i, x in enumerate(l):
>># do some stuff, sometimes assign l[i]
>>
>> for k, v in d.items():
>># do some stuff, sometimes assign d[k]
>
> for a, b in zip(spam, eggs):
> # do some stuff, sometimes assign x[a] or b[a] or who knows what?
>
>
> Does this mean that "lists, dicts and zip" should all support the same
> interface?
>
> Not every coincidental and trivial piece of similar code is actually
> related.
But your addition shows that the similarities between lists and dicts
are greater than with zip. In the above two examples the assignment
was specific to elements of the list or dict over which was iterated.
Your x[a] and b[a] have no such relationship with the rest of your
example. This is further illustrated by the fact that your solution
doesn't provide a zip branch.
>> A way to apply that pattern generically to an object which may be either
>> a sequence or a mapping might be nice.
> Nice, and easy.
>
> # Duck-typing version.
> def iterpairs(obj):
> if hasattr(obj, 'items'):
> it = obj.items
> else:
> it = enum(obj)
> yield from it
>
>
> # Type-checking version.
> def iterpairs(obj):
> if isinstance(obj, collections.abc.Mapping):
> it = obj.items
> elif isinstance(obj, collections.abc.Sequence):
> it = enum(obj)
> else:
> raise TypeError('not a sequence or a mapping')
> yield from it
>
>
> Pick which one you prefer, stick it in your own personal toolbox of useful
> utilities functions, and off you go.
>
>
>
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Interpreter not selected
muhammed siddiq writes: > Hello Team, Welcome! We are less a team and more a community of Python enthusiasts. You are welcome to ask about Python here. If you need help specifically with PyCharm you will probably need to find its specific support community. > I have installed Python 3.5.1 and now trying to install pycharm, but > its not selecting the interpreter and getting the below error all the > time. Image (and other attachments) do not travel well in a distributed message forum. Please insert the text of the error, directly in the message. -- \“The fact of your own existence is the most astonishing fact | `\you'll ever have to confront. Don't dare ever see your life as | _o__)boring, monotonous, or joyless.” —Richard Dawkins, 2010-03-10 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Which plugin allows quick creation of secure REST services?
Hello, Which plugin allows quick creation of secure REST services? so that Python scripts can be attached to it. Regards. David -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
On Thu, 31 Mar 2016 06:52 pm, Antoon Pardon wrote: > it is your burden to argue that problem. No it isn't. I don't have to do a thing. All I need to do is sit back and wait as this discussion peters off into nothing. The burden isn't on me to justify the status quo. The burden is on those who want to make this change to justify the change, because if you don't, the status quo stays exactly the same. And if you're brave enough to take to this Python-Ideas, let alone Python-Dev, the first question they'll ask is "What's your use-case?". And since you don't have one, this discussion will go nowhere. Oh, there might be a few hundred posts on the topic, from people bike-shedding it, but unless you convince the core developers, all the chattering in the world won't get you one nanometre closer to changing the behaviour of lists and dicts. So, Antoon, no, I don't have to justify a single thing. If you want this change, you have to justify why it should be done. Good luck with that. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
Op 31-03-16 om 12:36 schreef Steven D'Aprano: > On Thu, 31 Mar 2016 06:52 pm, Antoon Pardon wrote: > >> it is your burden to argue that problem. > No it isn't. I don't have to do a thing. If that is how you think about this, why do you contribute? I completly understand if you are of the opinion that other priorities are more important > All I need to do is sit back and > wait as this discussion peters off into nothing. The burden isn't on me to > justify the status quo. The burden is on those who want to make this change > to justify the change, because if you don't, the status quo stays exactly > the same. > > And if you're brave enough to take to this Python-Ideas, let alone > Python-Dev, the first question they'll ask is "What's your use-case?". And > since you don't have one, this discussion will go nowhere. > > Oh, there might be a few hundred posts on the topic, from people > bike-shedding it, but unless you convince the core developers, all the > chattering in the world won't get you one nanometre closer to changing the > behaviour of lists and dicts. > > So, Antoon, no, I don't have to justify a single thing. If you want this > change, you have to justify why it should be done. > > Good luck with that. > > > > -- https://mail.python.org/mailman/listinfo/python-list
Re: sympy
Den onsdag den 30. marts 2016 kl. 17.59.49 UTC+2 skrev Steven D'Aprano:
> On Thu, 31 Mar 2016 02:23 am, Poul Riis wrote:
>
> > What I intend to do is to let sympy find the derivative of some
> > welldefined function and next define the foundation derivative as a normal
> > function so that I can calculate numerical values or even make a graph.
>
>
> I'm glad you explained what you *actually* wanted, because I was going to
> guess that you wanted to evaluate the derivative at x = 3:
>
>
> py> ftext.evalf(subs={x:3})
> -0.0600
>
>
>
> --
> Steven
... However, the sympy way seems to be about 70 times slower than using the
derivative calculated 'by hand' (try the example below).
Can it be done in a more efficient way?
Poul Riis
from sympy import *
from time import *
x=Symbol('x')
ftext=diff(sin(x),x)
def fmsympy(t):
return ftext.evalf(subs={x:t})
def fm(t):
return cos(t)
nloop=1
tstart=time()
# nloop evaluations with sympy
for i in range(0,nloop):
a=fmsympy(1)
dt1=time()-tstart
# nloop evaluations without sympy
tstart=time()
for i in range(0,nloop):
a=fm(1)
dt2=time()-tstart
print(nloop,' evaluations with sympy : dt1 =',dt1)
print(nloop,' evaluations without sympy: dt2 =',dt2)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
Op 31-03-16 om 12:36 schreef Steven D'Aprano: > On Thu, 31 Mar 2016 06:52 pm, Antoon Pardon wrote: > >> it is your burden to argue that problem. > No it isn't. I don't have to do a thing. All I need to do is sit back and > wait as this discussion peters off into nothing. The burden isn't on me to > justify the status quo. The burden is on those who want to make this change > to justify the change, because if you don't, the status quo stays exactly > the same. Sure that is all very well if you stay out of the discussion, or limit your contribution to mentioning that in your opinion that this is a very low priority. I have no problem with that. But if you begin to argue that the proposal has flaws and you argue against it then it is your intellectual responsibility to support your arguments. There is a difference between, (1) this proposal is flawed and (2)I don't think this is important enough. Starting with the first and then when pressed to support it, retreating to the second is not fair. > And if you're brave enough to take to this Python-Ideas, let alone > Python-Dev, the first question they'll ask is "What's your use-case?". And > since you don't have one, this discussion will go nowhere. So? That doesn't relieve you of your responsibility when you somehow argue that the proposal is flawed, beyond there being no use case. > Oh, there might be a few hundred posts on the topic, from people > bike-shedding it, but unless you convince the core developers, all the > chattering in the world won't get you one nanometre closer to changing the > behaviour of lists and dicts. I have no interest in convincing the core developers. That doesn't mean I can't respond here to arguments against a proposal that are IMO bogus. A bogus argument against a proposal doesn't become a good argument against because there is no use case. > So, Antoon, no, I don't have to justify a single thing. If you want this > change, you have to justify why it should be done. Indeed you don't have to argue against any proposal. You can just sit back and ask for use cases and ask do be convinced this proposal is important enough for the core developers to invest time in. But once you do argue against a proposal, as you did here, you have loaded yourself with the burden to support your argument. Because then your position is that even with an import use case, this is still a bad idea. And if you can't support that position it isn't fair IMO to then retreat to the "no use case" position as if that somehow is a defence of your argued position. -- Antoon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
On Thu, Mar 31, 2016 at 10:22 PM, Antoon Pardon wrote: > Op 31-03-16 om 12:36 schreef Steven D'Aprano: >> On Thu, 31 Mar 2016 06:52 pm, Antoon Pardon wrote: >> >>> it is your burden to argue that problem. >> No it isn't. I don't have to do a thing. All I need to do is sit back and >> wait as this discussion peters off into nothing. The burden isn't on me to >> justify the status quo. The burden is on those who want to make this change >> to justify the change, because if you don't, the status quo stays exactly >> the same. > > Sure that is all very well if you stay out of the discussion, or limit > your contribution to mentioning that in your opinion that this is a > very low priority. I have no problem with that. But if you begin to > argue that the proposal has flaws and you argue against it then it > is your intellectual responsibility to support your arguments. > > There is a difference between, (1) this proposal is flawed and (2)I > don't think this is important enough. Starting with the first and then > when pressed to support it, retreating to the second is not fair. > Okay. I'll put a slightly different position: Prove that your proposal is worth discussing by actually giving us an example that we can discuss. So far, this thread has had nothing but toy examples (and bogoexamples that prove nothing beyond that the author knows how to mess with Python - fun, but not a strong argument on either side). Give us some real meat to work with, instead of these drips of tantalizing blood. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
On 31 March 2016 at 04:40, Steven D'Aprano wrote: > Enough of the hypothetical arguments about what one could do or might do. > Let's see a concrete example of actual real world code used in production, > not a mickey-mouse toy program, where it is desirable that adding or > deleting one key will modify the rest of the keys in the mapping. 1. the example was for confuting your assertion that an implementation of sequences as extended classes of maps violate the map contract. 2. I already linked a real-world example previously. Google it and you can find tons of examples like that. On 31 March 2016 at 04:44, Steven D'Aprano wrote: > for a, b in zip(spam, eggs): > # do some stuff, sometimes assign x[a] or b[a] or who knows what? > > > Does this mean that "lists, dicts and zip" should all support the same > interface? I do not understand what you mean with this example. A zip object is not a sequence nor a map. My definition of sequences as "ordered maps with integer keys that start from zero and have no gaps" is perfectly valid as I demonstrated to you, while zip objects have nothing in common with sequences and maps, apart the fact they are all iterables. -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
On 31/03/2016 12:58, Marco Sulla via Python-list wrote: On 31 March 2016 at 04:40, Steven D'Aprano wrote: Enough of the hypothetical arguments about what one could do or might do. Let's see a concrete example of actual real world code used in production, not a mickey-mouse toy program, where it is desirable that adding or deleting one key will modify the rest of the keys in the mapping. 1. the example was for confuting your assertion that an implementation of sequences as extended classes of maps violate the map contract. 2. I already linked a real-world example previously. Google it and you can find tons of examples like that. On 31 March 2016 at 04:44, Steven D'Aprano wrote: for a, b in zip(spam, eggs): # do some stuff, sometimes assign x[a] or b[a] or who knows what? Does this mean that "lists, dicts and zip" should all support the same interface? I do not understand what you mean with this example. A zip object is not a sequence nor a map. My definition of sequences as "ordered maps with integer keys that start from zero and have no gaps" is perfectly valid as I demonstrated to you, while zip objects have nothing in common with sequences and maps, apart the fact they are all iterables. The definition of sequence is given here https://docs.python.org/3/glossary.html#term-sequence. An iterable which supports efficient element access using integer indices via the __getitem__() special method and defines a __len__() method that returns the length of the sequence. Some built-in sequence types are list, str, tuple, and bytes. Note that dict also supports __getitem__() and __len__(), but is considered a mapping rather than a sequence because the lookups use arbitrary immutable keys rather than integers. The collections.abc.Sequence abstract base class defines a much richer interface that goes beyond just __getitem__() and __len__(), adding count(), index(), __contains__(), and __reversed__(). Types that implement this expanded interface can be registered explicitly using register(). As this is a Python list the above definition clearly takes priority over your definition, so can you please take this discussion offline, thanks. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
Chris Angelico :
> On Thu, Mar 31, 2016 at 10:22 PM, Antoon Pardon
> wrote:
> Okay. I'll put a slightly different position: Prove that your proposal
> is worth discussing by actually giving us an example that we can
> discuss.
Sorry for missing most of the arguments here, but if you are talking
about treating lists as special cases of dicts, I have occasionally
instinctively wanted something like this:
>>> fields = [ "x", "y", "z" ]
>>> selector = (1, 1, 0)
>>> list(map(fields.get, selector))
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'list' object has no attribute 'get'
analogously with:
>>> field_dict = { 0: "x", 1: "y", 2: "z" }
>>> list(map(field_dict.get, selector))
['y', 'y', 'x']
Or course, I could:
>>> list(map(fields.__getitem__, selector))
['y', 'y', 'x']
but that would abuse a dunder method. So I will need to:
>>> list(map(lambda i: fields[i], selector))
['y', 'y', 'x']
or (most likely):
>>> new_fields = []
>>> for i in selector:
... new_fields.append(fields[i])
...
>>> new_fields
['y', 'y', 'x']
This tiny problem of mine could be remedied by adding a get method to
lists.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
On Thu, Mar 31, 2016 at 11:36 PM, Marko Rauhamaa wrote: > Chris Angelico : > >> On Thu, Mar 31, 2016 at 10:22 PM, Antoon Pardon >> wrote: >> Okay. I'll put a slightly different position: Prove that your proposal >> is worth discussing by actually giving us an example that we can >> discuss. > > Sorry for missing most of the arguments here, but if you are talking > about treating lists as special cases of dicts, I have occasionally > instinctively wanted something like this: > > >>> fields = [ "x", "y", "z" ] > >>> selector = (1, 1, 0) > >>> list(map(fields.get, selector)) > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'list' object has no attribute 'get' > > Or course, I could: > > >>> list(map(fields.__getitem__, selector)) > ['y', 'y', 'x'] > > but that would abuse a dunder method. So I will need to: > > >>> list(map(lambda i: fields[i], selector)) > ['y', 'y', 'x'] > > or (most likely): > > >>> new_fields = [] > >>> for i in selector: > ... new_fields.append(fields[i]) > ... > >>> new_fields > ['y', 'y', 'x'] > > > This tiny problem of mine could be remedied by adding a get method to > lists. Or, even more likely and even more Pythonic: >>> [fields[i] for i in selector] ['y', 'y', 'x'] As soon as you get past the easy and obvious case of an existing function, filter and map quickly fall behind comprehensions in utility and readability. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
I want also to add that we are focusing on sequences, but my proposal is also to make map interface more similar, introducing a vdict type that iterates over values, and this will be for me really more practical. PEP 234 ( http://legacy.python.org/dev/peps/pep-0234/ ) never convinced me. Van Rossum said: > The symmetry between "if x in y" and "for x in y" > suggests that it should iterate over keys. This symmetry has been > observed by many independently and has even been used to "explain" > one using the other. This is because for sequences, "if x in y" > iterates over y comparing the iterated values to x. This argument will never convinced me. It's a lot more practical (as Van Rossum admitted further) to iterate over values by default on maps. Furthermore I see much more symmetry between keys of maps and indexes of sequences, so it's much more natural to make map iteration over values by default, as for sequences. This is why I proposed a vdict. On 31 March 2016 at 14:30, Mark Lawrence via Python-list wrote: > Note that dict also supports > __getitem__() and __len__(), but is considered a mapping rather than a > sequence because the lookups use arbitrary immutable keys rather than > integers. Thank you for confirming for what I already wrote and quoted, but I suppose you missed some of my previous messages, my dear friend. -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
Marko Rauhamaa writes:
> Chris Angelico wrote:
>
>> Okay. I'll put a slightly different position: Prove that your
>> proposal is worth discussing by actually giving us an example that we
>> can discuss.
>
> Sorry for missing most of the arguments here, but if you are talking
> about treating lists as special cases of dicts, I have occasionally
> instinctively wanted something like this:
>
> >>> fields = [ "x", "y", "z" ]
> >>> selector = (1, 1, 0)
> >>> list(map(fields.get, selector))
> Traceback (most recent call last):
> File "", line 1, in
> AttributeError: 'list' object has no attribute 'get'
operator.itemgetter(*selector)(fields) # ==> ('y', 'y', 'x')
> analogously with:
>
> >>> field_dict = { 0: "x", 1: "y", 2: "z" }
> >>> list(map(field_dict.get, selector))
> ['y', 'y', 'x']
operator.itemgetter(*selector)(field_dict) # ==> ('y', 'y', 'x')
It's not quite the same but it's close and it works the same for
strings, lists, dicts, ...
--
https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
Op 31-03-16 om 13:57 schreef Chris Angelico: > Okay. I'll put a slightly different position: Prove that your proposal > is worth discussing by actually giving us an example that we can > discuss. So far, this thread has had nothing but toy examples (and > bogoexamples that prove nothing beyond that the author knows how to > mess with Python - fun, but not a strong argument on either side). > Give us some real meat to work with, instead of these drips of > tantalizing blood. What a strange request. Whether or not something is worth discussing is a personal judgement. So there can be no proof of such a thing. I would say: judge for yourself and act accordingly. -- Antoon -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
On Fri, Apr 1, 2016 at 12:08 AM, Antoon Pardon wrote: > Op 31-03-16 om 13:57 schreef Chris Angelico: >> Okay. I'll put a slightly different position: Prove that your proposal >> is worth discussing by actually giving us an example that we can >> discuss. So far, this thread has had nothing but toy examples (and >> bogoexamples that prove nothing beyond that the author knows how to >> mess with Python - fun, but not a strong argument on either side). >> Give us some real meat to work with, instead of these drips of >> tantalizing blood. > > What a strange request. Whether or not something is worth discussing > is a personal judgement. So there can be no proof of such a thing. > I would say: judge for yourself and act accordingly. Plonk. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
On 31/03/2016 13:49, Marco Sulla via Python-list wrote: On 31 March 2016 at 14:30, Mark Lawrence via Python-list wrote: Note that dict also supports __getitem__() and __len__(), but is considered a mapping rather than a sequence because the lookups use arbitrary immutable keys rather than integers. Thank you for confirming for what I already wrote and quoted, but I suppose you missed some of my previous messages, my dear friend. Thanks for misquoting me by deliberately snipping the bit about taking this completely useless discussion offline. Please do not "dear friend" me as I don't take kindly to people who go out of their way to waste time and effort on this list. This just isn't going to happen, so please drop it, or do you not realise when you're fighting a losing battle, and it's time to retreat? There are of course other options, you could join in the effort to produce Python 2.8 or RickedPython. I'm sure that they'd welcome some additional help and your patch for your absolutely awesome suggestion. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
On 31/03/2016 14:08, Antoon Pardon wrote: Op 31-03-16 om 13:57 schreef Chris Angelico: Okay. I'll put a slightly different position: Prove that your proposal is worth discussing by actually giving us an example that we can discuss. So far, this thread has had nothing but toy examples (and bogoexamples that prove nothing beyond that the author knows how to mess with Python - fun, but not a strong argument on either side). Give us some real meat to work with, instead of these drips of tantalizing blood. What a strange request. Whether or not something is worth discussing is a personal judgement. So there can be no proof of such a thing. I would say: judge for yourself and act accordingly. Drivel. This is comp.lang.python, where "Practicality beats purity" every time, not comp.theoretical.claptrap. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
On Thu, Mar 31, 2016, at 09:17, Mark Lawrence via Python-list wrote: > On 31/03/2016 14:08, Antoon Pardon wrote: > > Op 31-03-16 om 13:57 schreef Chris Angelico: > >> Okay. I'll put a slightly different position: Prove that your proposal > >> is worth discussing by actually giving us an example that we can > >> discuss. So far, this thread has had nothing but toy examples (and > >> bogoexamples that prove nothing beyond that the author knows how to > >> mess with Python - fun, but not a strong argument on either side). > >> Give us some real meat to work with, instead of these drips of > >> tantalizing blood. > > > > What a strange request. Whether or not something is worth discussing > > is a personal judgement. So there can be no proof of such a thing. > > I would say: judge for yourself and act accordingly. > > Drivel. This is comp.lang.python, where "Practicality beats purity" > every time, not comp.theoretical.claptrap. So can we discuss how a unified method to get a set of all valid subscripts (and/or subscript-value pairs) on an object would be a useful thing to have without getting bogged down in theoretical claptrap about the meaning of the mapping contract? -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
On Thursday, March 31, 2016 at 6:38:56 PM UTC+5:30, Antoon Pardon wrote: > Op 31-03-16 om 13:57 schreef Chris Angelico: > > Okay. I'll put a slightly different position: Prove that your proposal > > is worth discussing by actually giving us an example that we can > > discuss. So far, this thread has had nothing but toy examples (and > > bogoexamples that prove nothing beyond that the author knows how to > > mess with Python - fun, but not a strong argument on either side). > > Give us some real meat to work with, instead of these drips of > > tantalizing blood. > > What a strange request. Whether or not something is worth discussing > is a personal judgement. So there can be no proof of such a thing. > I would say: judge for yourself and act accordingly. Not been following this thread much And not much interest in the suggestion/request Just thought I'd give a take on what may be the motivation for this There is the allure of One-Fundamental-Data-structure Lisp calls that 'list' [40 years after with more fanfare and less clarity replicated as XML] Math calls that 'function' Even more fundamental in CS than in math That maps are same as functions is standard math. In python one interconverts data→code by going from dict d to d.get code→data by memoization/caching How about a Grand Unified Theory? [Just to be clear -- not my interest or wish] -- https://mail.python.org/mailman/listinfo/python-list
Pyscripter Issues
Hi I have been having issues trying to run python 3.5.1 and pyscripter 2.6. Giving the error message that it cannot initialize python. I have tried to re-install multiple versions of both python and pyscripter to no avail. Any advice? Thanks Simon Sent from Mail for Windows 10 -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
Chris Angelico : > Or, even more likely and even more Pythonic: > [fields[i] for i in selector] > ['y', 'y', 'x'] > > As soon as you get past the easy and obvious case of an existing > function, filter and map quickly fall behind comprehensions in utility > and readability. The general need is contexts where you need fields[?] act as a function. Of course, lambda i: fields[i] does it. However, weirdly, dicts have get but lists don't. Ok, dict.get() provides for a default value, but couldn't that come in handy for lists as well? Again, lambda would do it for both dicts and lists: lambda i: fields[i] if i >= 0 and i < len(fields) else default lambda key: fields[key] if key in fields else default Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
On 31/03/2016 14:27, Random832 wrote: On Thu, Mar 31, 2016, at 09:17, Mark Lawrence via Python-list wrote: On 31/03/2016 14:08, Antoon Pardon wrote: Op 31-03-16 om 13:57 schreef Chris Angelico: Okay. I'll put a slightly different position: Prove that your proposal is worth discussing by actually giving us an example that we can discuss. So far, this thread has had nothing but toy examples (and bogoexamples that prove nothing beyond that the author knows how to mess with Python - fun, but not a strong argument on either side). Give us some real meat to work with, instead of these drips of tantalizing blood. What a strange request. Whether or not something is worth discussing is a personal judgement. So there can be no proof of such a thing. I would say: judge for yourself and act accordingly. Drivel. This is comp.lang.python, where "Practicality beats purity" every time, not comp.theoretical.claptrap. So can we discuss how a unified method to get a set of all valid subscripts (and/or subscript-value pairs) on an object would be a useful thing to have without getting bogged down in theoretical claptrap about the meaning of the mapping contract? We can discuss anything here until the cows come home, but it's a complete waste of time if the powers that be over on python-ideas and/or python-dev don't agree. This was suggested a day or two back but seems to have gone completely over people's heads. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
Random832 : > So can we discuss how a unified method to get a set of all valid > subscripts (and/or subscript-value pairs) on an object would be a > useful thing to have without getting bogged down in theoretical > claptrap about the meaning of the mapping contract? One could compose a table of correspondences: --- list (L)dict (D) --- L[key] = value D[key] = value del L[key] (*) del L[key] key >= 0 and key < len(L) key in D range(len(L)) iter(D) L.clear D.clear L.copy D.copy lambda key: L[key] D.get lambda: enumerate(L)D.items lambda: range(len(L)) D.keys ...... --- (*) reassigns all keys Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
Jussi Piitulainen :
> operator.itemgetter(*selector)(fields) # ==> ('y', 'y', 'x')
>
> [...]
>
> operator.itemgetter(*selector)(field_dict) # ==> ('y', 'y', 'x')
>
> It's not quite the same but it's close and it works the same for
> strings, lists, dicts, ...
Not quite the same, but nicely found anyway.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: sympy
Poul Riis wrote:
> Den onsdag den 30. marts 2016 kl. 17.59.49 UTC+2 skrev Steven D'Aprano:
>> On Thu, 31 Mar 2016 02:23 am, Poul Riis wrote:
>>
>> > What I intend to do is to let sympy find the derivative of some
>> > welldefined function and next define the foundation derivative as a
>> > normal function so that I can calculate numerical values or even make a
>> > graph.
>>
>>
>> I'm glad you explained what you *actually* wanted, because I was going to
>> guess that you wanted to evaluate the derivative at x = 3:
>>
>>
>> py> ftext.evalf(subs={x:3})
>> -0.0600
>>
>>
>>
>> --
>> Steven
>
> ... However, the sympy way seems to be about 70 times slower than using
> the derivative calculated 'by hand' (try the example below). Can it be
> done in a more efficient way?
Hm, the two functions fmsympy() and fm() do not return the same value:
$ python -i sympy_diff.py
1 evaluations with sympy : dt1 = 0.7178411483764648
1 evaluations without sympy: dt2 = 0.10177111625671387
>>> fm(42)
cos(42)
>>> fmsympy(42)
-0.399985314988351
What's the point of that benchmark?
> Poul Riis
>
>
>
> from sympy import *
> from time import *
> x=Symbol('x')
> ftext=diff(sin(x),x)
>
> def fmsympy(t):
>return ftext.evalf(subs={x:t})
>
> def fm(t):
> return cos(t)
>
> nloop=1
> tstart=time()
> # nloop evaluations with sympy
> for i in range(0,nloop):
> a=fmsympy(1)
> dt1=time()-tstart
>
> # nloop evaluations without sympy
> tstart=time()
> for i in range(0,nloop):
> a=fm(1)
> dt2=time()-tstart
>
> print(nloop,' evaluations with sympy : dt1 =',dt1)
> print(nloop,' evaluations without sympy: dt2 =',dt2)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Pyscripter Issues
On Fri, 1 Apr 2016 12:45 am, Simon Martin wrote: > Hi > > I have been having issues trying to run python 3.5.1 and pyscripter 2.6. > Giving the error message that it cannot initialize python. > > I have tried to re-install multiple versions of both python and pyscripter > to no avail. Any advice? Yes: start by copying and pasting the full error message here, so we can read it, rather than summarising it. Generally speaking, re-installing Python should be your last resort. At the very least, there's no point in re-installing until you can be sure that Python itself is broken. What happens if you run "python3" from the command prompt? I've barely touched Windows for probably eight years, and I have no idea how to get a command prompt in Windows 10, but if you can get command.com or cmd.exe (whichever it is) and try running Python from that, you'll soon find out whether Python itself is working. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Slice equivalent to dict.get
Sometimes people look for a method which is equivalent to dict.get, where
they can set a default value for when the key isn't found:
py> d = {1: 'a', 2: 'b'}
py> d.get(999, '?')
'?'
The equivalent for sequences such as lists and tuples is a slice. If the
slice is out of range, Python returns a empty sequence:
py> L = [2, 4, 8, 16]
py> L[5] # out of range, raises IndexError
Traceback (most recent call last):
File "", line 1, in
IndexError: list index out of range
py> L[5:6] # out of range slice return empty list
[]
To get a default:
py> L[5:6] or -1
-1
This is short and simple enough to use in place, but we can also wrap this
into a convenient helper function:
def get(seq, index, default=None):
return (seq[index:index+1] or [default])[0]
py> get(L, 2, -1)
8
py> get(L, 200, -1)
-1
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Slice equivalent to dict.get
Steven D'Aprano wrote:
> Sometimes people look for a method which is equivalent to dict.get, where
> they can set a default value for when the key isn't found:
>
>
> py> d = {1: 'a', 2: 'b'}
> py> d.get(999, '?')
> '?'
>
>
> The equivalent for sequences such as lists and tuples is a slice. If the
> slice is out of range, Python returns a empty sequence:
>
> py> L = [2, 4, 8, 16]
> py> L[5] # out of range, raises IndexError
> Traceback (most recent call last):
> File "", line 1, in
> IndexError: list index out of range
> py> L[5:6] # out of range slice return empty list
> []
>
> To get a default:
>
> py> L[5:6] or -1
> -1
>
>
> This is short and simple enough to use in place, but we can also wrap this
> into a convenient helper function:
>
> def get(seq, index, default=None):
> return (seq[index:index+1] or [default])[0]
>
>
>
> py> get(L, 2, -1)
> 8
> py> get(L, 200, -1)
> -1
But note:
>>> def get(seq, index, default=None):
... return (seq[index:index+1] or [default])[0]
...
>>> get("abc", -1, "default")
'default'
God old try...except to the rescue:
>>> def get(seq, index, default=None):
... try: return seq[index]
... except IndexError: return default
...
>>> get("abc", -1, "default")
'c'
--
https://mail.python.org/mailman/listinfo/python-list
Re: Pyscripter Issues
On Thursday, March 31, 2016, Simon Martin wrote: > > Hi > > I have been having issues trying to run python 3.5.1 and pyscripter 2.6. > Giving the error message that it cannot initialize python. > > I have tried to re-install multiple versions of both python and pyscripter to > no avail. Any advice? Use PyCharm. Less bluntly, I used to be a heavy PyScripter user, but after it took forever for PyScripter to support Python 3.4 (I wasn't even sure if it did yet, but it apparently does as of a year ago, added one year after 3.4 was released), I moved on. PyScripter also has the big disadvantage of being strictly single-platform, unlike Python itself, so if you were to try to develop on another platform you would have to learn a new IDE/editor anyway. I have found PyCharm to be very nice, and very consistent cross-platform--I use it regularly on OSX and Windows, and have also used it on Linux. I'm also becoming rather partial to vim, which is also nicely cross-platform: if you have Git on Windows, you have vim available already. Vim does have a somewhat steeper learning curve, though. Looking a bit deeper into what your problem might actually be, PyScripter does not support Python 3.5. Support for each new Python version has to be added explicitly, and it has not been done for 3.5. If you still want to use PyScripter, you should use the latest release of Python 3.4. Keep in mind that you must match use 32-bit Python with 32-bit PyScripter, and 64-bit Python with 64-bit PyScripter, you cannot mix and match. But seriously, you'll be much happier with PyCharm. -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyscripter Issues
In Simon Martin writes: > I have been having issues trying to run python 3.5.1 and pyscripter 2.6. > Giving the error message that it cannot initialize python. Which version of Python did you get: 32-bit or 64-bit? I vaguely recall that PyScripter won't work with the 64-bit version. -- John Gordon A is for Amy, who fell down the stairs gor...@panix.com B is for Basil, assaulted by bears -- Edward Gorey, "The Gashlycrumb Tinies" -- https://mail.python.org/mailman/listinfo/python-list
Re: Slice equivalent to dict.get
On Thu, Mar 31, 2016 at 9:24 AM, Peter Otten <__pete...@web.de> wrote:
> But note:
>
def get(seq, index, default=None):
> ... return (seq[index:index+1] or [default])[0]
> ...
get("abc", -1, "default")
> 'default'
The discontinuity between -1 and 0 in indexing is a pain in the rear.
Negative indexes are one of those things that may seem like a good
idea at first, but I think in the end it causes more trouble than it's
worth. There's nothing you can do with L[-x] that you can't do more
explicitly with L[len(L) - x].
--
https://mail.python.org/mailman/listinfo/python-list
Re: Slice equivalent to dict.get
On 31.03.2016 17:07, Steven D'Aprano wrote:
Sometimes people look for a method which is equivalent to dict.get, where
they can set a default value for when the key isn't found:
py> d = {1: 'a', 2: 'b'}
py> d.get(999, '?')
'?'
The equivalent for sequences such as lists and tuples is a slice. If the
slice is out of range, Python returns a empty sequence:
I see what you are trying to achieve here. What do you think about this?
[1, 2, 3].get(999, '?')
Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Learning Python (or Haskell) makes you a worse programmer
> On Mar 30, 2016, at 2:36 PM, Gregory Ewing > wrote: > > Tim Golden wrote: > >> (I don't know how other English-speaking groups say the word, but in >> England the first syllable is stressed and the second is the >> conventional short "uh" sound). > > I can attest that New Zealand follows the UK on this. I was > surprised when I first heard an American pronounce it too. > > The curious can hear the difference on these pages: > > British: http://www.oxforddictionaries.com/definition/english/python > American: http://www.dictionary.com/browse/python?s=t That does it. If I ever make some sort of open source module for pythun/pythawn I’ll be sure to call it either tuhmayto/tomawto. Or maybe I’ll call it puhtayto/potawto. -- https://mail.python.org/mailman/listinfo/python-list
Re: Learning Python (or Haskell) makes you a worse programmer
On Thu, Mar 31, 2016 at 10:30 AM, Travis Griggs wrote: > >> On Mar 30, 2016, at 2:36 PM, Gregory Ewing >> wrote: >> >> Tim Golden wrote: >> >>> (I don't know how other English-speaking groups say the word, but in >>> England the first syllable is stressed and the second is the >>> conventional short "uh" sound). >> >> I can attest that New Zealand follows the UK on this. I was >> surprised when I first heard an American pronounce it too. >> >> The curious can hear the difference on these pages: >> >> British: http://www.oxforddictionaries.com/definition/english/python >> American: http://www.dictionary.com/browse/python?s=t > > That does it. If I ever make some sort of open source module for > pythun/pythawn I’ll be sure to call it either tuhmayto/tomawto. Or maybe I’ll > call it puhtayto/potawto. Pytato? -- https://mail.python.org/mailman/listinfo/python-list
Re: Learning Python (or Haskell) makes you a worse programmer
On 31.03.2016 18:30, Travis Griggs wrote: British: http://www.oxforddictionaries.com/definition/english/python American: http://www.dictionary.com/browse/python?s=t That does it. If I ever make some sort of open source module for pythun/pythawn I’ll be sure to call it either tuhmayto/tomawto. Or maybe I’ll call it puhtayto/potawto. Isn't it more like "Pythn"? -- https://mail.python.org/mailman/listinfo/python-list
Re: sympy
On Fri, Apr 1, 2016 at 1:55 AM, Peter Otten <__pete...@web.de> wrote: > Hm, the two functions fmsympy() and fm() do not return the same value: > > $ python -i sympy_diff.py > 1 evaluations with sympy : dt1 = 0.7178411483764648 > 1 evaluations without sympy: dt2 = 0.10177111625671387 fm(42) > cos(42) fmsympy(42) > -0.399985314988351 > Maybe not, but that's simply because one of them is completely evaluated. The cosine of 42 radians is indeed -0.4ish. >>> math.cos(42) -0.39998531498835127 ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion: make sequence and map interfaces more similar
On 3/31/2016 10:13 AM, Marko Rauhamaa wrote: One could compose a table of correspondences: with some corrections --- list (L)dict (D) --- L[key] = value D[key] = value del L[key] (*) del L[key] (*) reassigns all keys key >= 0 and key < len(L) key in D '-len(L) <= key < len(L)' or 'key in range(-len(L), len(L)' Lists, tuples, and ranges have 2 keys for each value, though that is not guaranteed for sequences in general. key in D == key in D.keys() range(len(L)) iter(D) iter(range(Len(L)) == iter(D.keys()) L.clear D.clear L.copy D.copy lambda key: L[key] D.get The purpose of D.get() is to supply a default instead of raising KeyError when key not in D. The lambda function above does not do that. Turning subscripting into a function is a side-effect of D.get. A generic get function: def get(subscriptable, key, default=None): try: return subscriptable[key] except (IndexError, KeyError): return default lambda: enumerate(L)D.items As I pointed out a couple days ago, an enumerate iterator is quite different from a set-like dynamic view. An actual correspondence: enumerate(L) iter(D.items()) Writing a set-like dynamic view of lists corresponding to D.values() or D.items() would be an interesting project. lambda: range(len(L)) D.keys iter(range(len(L)) iter(D.keys()) Already given above. Iterating indexes is now much rarer than iterating dict keys. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Slice equivalent to dict.get
On 3/31/2016 11:24 AM, Peter Otten wrote:
Steven D'Aprano wrote:
Sometimes people look for a method which is equivalent to dict.get, where
they can set a default value for when the key isn't found:
py> d = {1: 'a', 2: 'b'}
py> d.get(999, '?')
'?'
The equivalent for sequences such as lists and tuples is a slice. If the
slice is out of range, Python returns a empty sequence:
py> L = [2, 4, 8, 16]
py> L[5] # out of range, raises IndexError
Traceback (most recent call last):
File "", line 1, in
IndexError: list index out of range
py> L[5:6] # out of range slice return empty list
[]
To get a default:
py> L[5:6] or -1
-1
This is short and simple enough to use in place, but we can also wrap this
into a convenient helper function:
def get(seq, index, default=None):
return (seq[index:index+1] or [default])[0]
py> get(L, 2, -1)
8
py> get(L, 200, -1)
-1
But note:
def get(seq, index, default=None):
... return (seq[index:index+1] or [default])[0]
...
get("abc", -1, "default")
'default'
God old try...except to the rescue:
def get(seq, index, default=None):
... try: return seq[index]
... except IndexError: return default
Replace IndexError with (IndexError, KeyError) and the functions works
with any subscriptable that raises either exception.
...
get("abc", -1, "default")
'c'
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: sympy
Chris Angelico wrote: > On Fri, Apr 1, 2016 at 1:55 AM, Peter Otten <__pete...@web.de> wrote: >> Hm, the two functions fmsympy() and fm() do not return the same value: >> >> $ python -i sympy_diff.py >> 1 evaluations with sympy : dt1 = 0.7178411483764648 >> 1 evaluations without sympy: dt2 = 0.10177111625671387 > fm(42) >> cos(42) > fmsympy(42) >> -0.399985314988351 >> > > Maybe not, but that's simply because one of them is completely > evaluated. The cosine of 42 radians is indeed -0.4ish. > math.cos(42) > -0.39998531498835127 My guess was that the OP fell into the trap that he himself carefully set up with the star import, and accidentally used sympy.cos() where he wanted to invoke math.cos(). The fix would actually increase the speed difference -- but first make it right, then, maybe, fast. Adding another storey to the tower of guesses, Robert Kern has probably already provided the answer ;) -- https://mail.python.org/mailman/listinfo/python-list
Re: sympy
On 31 March 2016 at 11:57, Poul Riis wrote:
>
> ... However, the sympy way seems to be about 70 times slower than using the
> derivative calculated 'by hand' (try the example below).
> Can it be done in a more efficient way?
>
> Poul Riis
>
>
>
> from sympy import *
> from time import *
> x=Symbol('x')
> ftext=diff(sin(x),x)
>
> def fmsympy(t):
>return ftext.evalf(subs={x:t})
>
> def fm(t):
> return cos(t)
I think you have misunderstood what is going on here. Let's actually
try those two methods out:
$ isympy
IPython console for SymPy 0.7.5 (Python 2.7.9-64-bit) (ground types: gmpy)
These commands were executed:
>>> from __future__ import division
>>> from sympy import *
>>> x, y, z, t = symbols('x y z t')
>>> k, m, n = symbols('k m n', integer=True)
>>> f, g, h = symbols('f g h', cls=Function)
Documentation can be found at http://www.sympy.org
In [1]: ftext = diff(sin(x), x)
In [2]: ftext
Out[2]: cos(x)
In [3]: ftext.evalf(subs={x:1})
Out[3]: 0.540302305868140
In [4]: cos(1)
Out[4]: cos(1)
So the first version (your fmsympy) takes the symbolic expression
cos(x) represented as a sympy expression tree and substitutes 1 for x
(which requires walking the tree to look fo all occurrences of x).
Then it evaluates the result to 15 decimal digits of precision using
the pure Python mpmath multiprecision math library. To prove that it's
not really a float calculation let's increase the precision:
In [5]: ftext.evalf(subs={x:1}, n=100)
Out[5]:
0.540302305868139717400936607442976603732310420617976700972553811003947744717645179518560871830893
Your second version (fm) makes a sympy expression using the cos
function from sympy and the argument 1. This creates a symbolic sympy
expression cos(1) and returns that. It doesn't do any evaluation of
the expression to get the digits of the actual numeric answer.
So I'm not surprised that the two operations take different amounts of
time. One doesn't evaluate the expression and the other does using a
slow multiprecision library. Also note though that sympy uses a cache
to accelerate repeated calculations so if you time it doing the exact
same thing repeatedly in a loop then you may just be measuring
cache-hit performance for two different inputs rather than actual
evaluation time.
If you want to see one that's a lot faster use the cos function from
the math module:
In [9]: from math import cos
In [10]: cos(1)
Out[10]: 0.540302305868
This calculates cos(1) using IEEE 64-bit binary floating point
(Python's float type) with hardware acceleration from your processor's
FPU instructions. This should be a lot faster then either substituting
into symbolic expressions in sympy or evaluating trignometric
functions with mpmath.
Generally I would use sympy in order to derive the mathematical
expressions that I want to compute. However if I then want to evaluate
the expressions many times in a loop with different input numbers for
example then I would rewrite the expression without using sympy. Sympy
has code generation capabilities to automate this but you seemed to be
confused about basic sympy usage right now so I wouldn't recommend
them without knowing more about what you're trying to do.
--
Oscar
--
https://mail.python.org/mailman/listinfo/python-list
Re: Slice equivalent to dict.get
On Thu, Mar 31, 2016 at 12:51 PM, Terry Reedy wrote: > On 3/31/2016 11:24 AM, Peter Otten wrote: >> try...except to the rescue: >> > def get(seq, index, default=None): >> >> ... try: return seq[index] >> ... except IndexError: return default > > > Replace IndexError with (IndexError, KeyError) and the functions works with > any subscriptable that raises either exception. Or use the superclass of both of those, LookupError, and also catch anything that uses that more generic name as well. -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyscripter Issues
On 3/31/2016 11:29 AM, Zachary Ware wrote: On Thursday, March 31, 2016, Simon Martin wrote: Hi I have been having issues trying to run python 3.5.1 and pyscripter 2.6. Giving the error message that it cannot initialize python. I have tried to re-install multiple versions of both python and pyscripter to no avail. Any advice? Use PyCharm. Less bluntly, I used to be a heavy PyScripter user, but after it took forever for PyScripter to support Python 3.4 (I wasn't even sure if it did yet, but it apparently does as of a year ago, added one year after 3.4 was released), I moved on. PyScripter also has the big disadvantage of being strictly single-platform, unlike Python itself, so if you were to try to develop on another platform you would have to learn a new IDE/editor anyway. I have found PyCharm to be very nice, and very consistent cross-platform--I use it regularly on OSX and Windows, and have also used it on Linux. I'm also becoming rather partial to vim, which is also nicely cross-platform: if you have Git on Windows, you have vim available already. Vim does have a somewhat steeper learning curve, though. My situation is similar. I used to use PyScripter and liked it a lot, but when Python 3.4 support wasn't being added and I wanted a cross-platform IDE, I switched to PyDev. Looking a bit deeper into what your problem might actually be, PyScripter does not support Python 3.5. Support for each new Python version has to be added explicitly, and it has not been done for 3.5.] For the record, it doesn't work with Python 2.7.11 either. PyScripter only supports Python <= 2.7.10 and <= 3.4.x. But seriously, you'll be much happier with PyCharm. Or PyDev, whichever you prefer. I think PyCharm is easier to use than PyDev, but it seems too resource heavy for some computers. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyscripter Issues
On 3/31/2016 11:29 AM, Zachary Ware wrote: On Thursday, March 31, 2016, Simon Martin wrote: Hi I have been having issues trying to run python 3.5.1 and pyscripter 2.6. Giving the error message that it cannot initialize python. I have tried to re-install multiple versions of both python and pyscripter to no avail. Any advice? Use PyCharm. Less bluntly, I used to be a heavy PyScripter user, but after it took forever for PyScripter to support Python 3.4 (I wasn't even sure if it did yet, but it apparently does as of a year ago, added one year after 3.4 was released), I moved on. PyScripter also has the big disadvantage of being strictly single-platform, unlike Python itself, so if you were to try to develop on another platform you would have to learn a new IDE/editor anyway. I have found PyCharm to be very nice, and very consistent cross-platform--I use it regularly on OSX and Windows, and have also used it on Linux. I'm also becoming rather partial to vim, which is also nicely cross-platform: if you have Git on Windows, you have vim available already. Vim does have a somewhat steeper learning curve, though. My situation is similar. I used to use PyScripter and liked it a lot, but when Python 3.4 support wasn't being added and I wanted a cross-platform IDE, I switched to PyDev. Looking a bit deeper into what your problem might actually be, PyScripter does not support Python 3.5. Support for each new Python version has to be added explicitly, and it has not been done for 3.5.] For the record, it doesn't work with Python 2.7.11 either. PyScripter only supports Python <= 2.7.10 and <= 3.4.x. But seriously, you'll be much happier with PyCharm. Or PyDev, whichever you prefer. I think PyCharm is easier to use than PyDev, but it seems too resource heavy for some computers. -- https://mail.python.org/mailman/listinfo/python-list
Re: sympy
Den onsdag den 30. marts 2016 kl. 13.17.33 UTC+2 skrev Poul Riis:
> Is it possible to transfer results from sympy to 'normal' python.
>
> In the case below I think my intention is clear enough but it does not work
> as intended. How can it be done?
>
> Poul Riis
>
>
>
>
> from sympy import *
> x=Symbol('x')
> ftext=diff(1/(x**2+1),x)
>
> def f(t):
> return ftext.subs(x,'t')
>
> print(f(3))
Well, cos(1) should have been cos(1.0) (which forces numerical evaluation, try
example below).
I am just trying to implement one little thing that all CAS tools can do in a
few lines, namely finding the derivative of a given function followed by
evalution of numerical values, something like:
define(fm(x),diff(f(x),x))
fm(1.0)
Sympy can find the derivative, and once that has been completed I would expect
that there is some way to find numerical values just as fast as if the
derivative had been given 'by hand'. But how exactly?
Poul Riis
from sympy import *
from time import *
x=Symbol('x')
ftext=diff(sin(x),x)
def fmsympy(t):
return ftext.evalf(subs={x:t})
def fm(t):
return cos(t)
nloop=1
tstart=time()
for i in range(0,nloop):
a=fmsympy(1)
dt1=time()-tstart
print(a)
tstart=time()
for i in range(0,nloop):
a=fm(1.0)
dt2=time()-tstart
print(a)
print(nloop,' evaluations with sympy : dt1 =',dt1)
print(nloop,' evaluations without sympy: dt2 =',dt2)
--
https://mail.python.org/mailman/listinfo/python-list
The next major Python version will be Python 8
Hi, Python 3 becomes more and more popular and is close to a dangerous point where it can become popular that Python 2. The PSF decided that it's time to elaborate a new secret plan to ensure that Python users suffer again with a new major release breaking all their legacy code. The PSF is happy to announce that the new Python release will be Python 8! Why the version 8? It's just to be greater than Perl 6 and PHP 7, but it's also a mnemonic for PEP 8. By the way, each minor release will now multiply the version by 2. With Python 8 released in 2016 and one release every two years, we will beat Firefox 44 in 2022 (Python 64) and Windows 2003 in 2032 (Python 2048). A major release requires a major change to justify a version bump: the new killer feature is that it's no longer possible to import a module which does not respect the PEP 8. It ensures that all your code is pure. Example: $ python8 -c 'import keyword' Lib/keyword.py:16:1: E122 continuation line missing indentation or outdented Lib/keyword.py:16:1: E265 block comment should start with '# ' Lib/keyword.py:50:1: E122 continuation line missing indentation or outdented (...) ImportError: no pep8, no glory Good news: since *no* module of the current standard library of Python 3 respect the PEP 8, the standard library will be simplified to one unique module, which is new in Python 8: pep8. The standard library will move to the Python Cheeseshop (PyPI), to reply to an old and popular request. DON'T PANIC! You are still able to import your legacy code into Python 8, you just have to rename all your modules to add a "_noqa" suffix to the filename. For example, rename utils.py to utils_noqa.py. A side effect is that you have to update all imports. For example, replace "import django" with "import django_noqa". After a study of the PSF, it's a best option to split again the Python community and make sure that all users are angry. The plan is that in 10 years, at least 50% of the 77,000 packages on the Python cheeseshop will be updated to get the "_noqa" tag. After 2020, the PSF will start to sponsor trolls to harass users of the legacy Python 3 to force them to migrate to Python 8. Python 8 is a work-in-progress (it's still an alpha version), the standard library was not removed yet. Hopefully, trying to import any module of the standard library fails. Don't hesitate to propose more ideas to make Python 8 more incompatible with Python 3! Note: The change is already effective in the default branch of Python: https://hg.python.org/cpython/rev/9aedec2dbc01 Have fun, Victor -- https://mail.python.org/mailman/listinfo/python-list
Re: sympy
On 31 March 2016 at 22:33, Poul Riis wrote:
> Den onsdag den 30. marts 2016 kl. 13.17.33 UTC+2 skrev Poul Riis:
>> Is it possible to transfer results from sympy to 'normal' python.
>>
>> In the case below I think my intention is clear enough but it does not work
>> as intended. How can it be done?
>>
>> Poul Riis
>>
>> from sympy import *
>> x=Symbol('x')
>> ftext=diff(1/(x**2+1),x)
>>
>> def f(t):
>> return ftext.subs(x,'t')
>>
>> print(f(3))
>
> Well, cos(1) should have been cos(1.0) (which forces numerical evaluation,
> try example below).
> I am just trying to implement one little thing that all CAS tools can do in a
> few lines, namely finding the derivative of a given function followed by
> evalution of numerical values, something like:
> define(fm(x),diff(f(x),x))
> fm(1.0)
>
> Sympy can find the derivative, and once that has been completed I would
> expect that there is some way to find numerical values just as fast as if the
> derivative had been given 'by hand'. But how exactly?
I assume that you're responding to me (even though your post is a
reply to yourself).
Robert Kern already answered this question earlier in the thread:
$ isympy
IPython console for SymPy 0.7.5 (Python 2.7.9-64-bit) (ground types: gmpy)
These commands were executed:
>>> from __future__ import division
>>> from sympy import *
>>> x, y, z, t = symbols('x y z t')
>>> k, m, n = symbols('k m n', integer=True)
>>> f, g, h = symbols('f g h', cls=Function)
Documentation can be found at http://www.sympy.org
In [1]: f = lambdify(x, sin(x).diff(x))
In [2]: f
Out[2]: >
In [3]: f(1)
Out[3]: 0.540302305868
We can pull apart this function f returned here:
In [4]: import dis
In [5]: dis.dis(f)
1 0 LOAD_GLOBAL 0 (cos)
3 LOAD_FAST0 (x)
6 CALL_FUNCTION1
9 RETURN_VALUE
In [6]: f.func_globals['cos']
Out[6]:
So the function f returned by lambdify uses math.cos which is the
64-bit float function I mentioned earlier (i.e. the faster one). You
can pass an int in and it will be coerced to float. You should find
that the performance of f is as good as lambda x: math.cos(x).
So lambdify takes an expression and a sequence of symbols and
generates a function whose arguments are substituted for the sequence
of symbols. The return value of the function is the result of
substituting the arguments for the symbols in the expression. I think
this is what you asked for.
--
Oscar
--
https://mail.python.org/mailman/listinfo/python-list
pip.exe issue with 3.5.1
So i just downloaded python 3.5.1 on my laptop and my pip.exe was not working. It would almost immediately close on me after I clicked on it. So i deleted the scripts folder as all of them did the same thing and then tried the modify feature and the repair feature of your installer to try and get pip back but it has not worked. Would you just recommend that I install 3.4.4 and just use that instead? -- https://mail.python.org/mailman/listinfo/python-list
Convert set to list
I feel like I've converted sets to lists before. But maybe not. Or maybe I am losing it from having worked 70 hours this week. Shouldn't this work? (Pdb) print block['relative_chart1']['vessel_names'] set([u'Common Carotid', u'External Carotid', u'Internal Carotid']) (Pdb) type(block['relative_chart1']['vessel_names']) (Pdb) list(block['relative_chart1']['vessel_names']) *** Error in argument: "(block['relative_chart1']['vessel_names'])" -- https://mail.python.org/mailman/listinfo/python-list
Re: Convert set to list
On Fri, Apr 1, 2016 at 10:56 AM, Larry Martell wrote: > I feel like I've converted sets to lists before. But maybe not. Or > maybe I am losing it from having worked 70 hours this week. > > Shouldn't this work? > > (Pdb) print block['relative_chart1']['vessel_names'] > set([u'Common Carotid', u'External Carotid', u'Internal Carotid']) > (Pdb) type(block['relative_chart1']['vessel_names']) > > (Pdb) list(block['relative_chart1']['vessel_names']) > *** Error in argument: "(block['relative_chart1']['vessel_names'])" What exactly does "Error in argument" mean? Normally I would agree, yes, you should be able to iterate over a set exactly like that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The next major Python version will be Python 8
Victor Stinner schreef op 2016-03-31 23:40: Python 3 becomes more and more popular and is close to a dangerous point where it can become popular that Python 2. The PSF decided that it's time to elaborate a new secret plan to ensure that Python users suffer again with a new major release breaking all their legacy code. "2016-03-31 23:40" You're 20 minutes early :) -- The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom. -- Isaac Asimov Roel Schroeven -- https://mail.python.org/mailman/listinfo/python-list
Re: Convert set to list
Larry Martell writes: > I feel like I've converted sets to lists before. But maybe not. Or > maybe I am losing it from having worked 70 hours this week. > > Shouldn't this work? In a Python interactive shell? Yes. In the PDB shell? No, because some different names are defined as commands. Such as ‘list’. -- \ “The trouble with Communism is the Communists, just as the | `\ trouble with Christianity is the Christians.” —Henry L. Mencken | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: The next major Python version will be Python 8
On 03/31/2016 05:02 PM, Roel Schroeven wrote: Victor Stinner schreef op 2016-03-31 23:40: Python 3 becomes more and more popular and is close to a dangerous point where it can become popular that Python 2. The PSF decided that it's time to elaborate a new secret plan to ensure that Python users suffer again with a new major release breaking all their legacy code. "2016-03-31 23:40" You're 20 minutes early :) No, that's a naive datetime. You need to travel to Victor's location to figure out what that is there. I sure hope Python 8 doesn't have that problem! -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Convert set to list
On Thursday, March 31, 2016, Ben Finney wrote: > Larry Martell > writes: > > > I feel like I've converted sets to lists before. But maybe not. Or > > maybe I am losing it from having worked 70 hours this week. > > > > Shouldn't this work? > > In a Python interactive shell? Yes. > > In the PDB shell? No, because some different names are defined as > commands. Such as ‘list’. > Ahhh. Thanks. Time for a break. -- https://mail.python.org/mailman/listinfo/python-list
Re: The next major Python version will be Python 8
On Fri, 01 Apr 2016 02:02:34 +0200 Roel Schroeven wrote: > Victor Stinner schreef op 2016-03-31 23:40: > > Python 3 becomes more and more popular and is close to a dangerous > > point where it can become popular that Python 2. The PSF decided > > that it's time to elaborate a new secret plan to ensure that Python > > users suffer again with a new major release breaking all their > > legacy code. > > "2016-03-31 23:40" > You're 20 minutes early :) And too obvious. -- D'Arcy J.M. Cain System Administrator, Vex.Net http://www.Vex.Net/ IM:da...@vex.net VoIP: sip:da...@vex.net -- https://mail.python.org/mailman/listinfo/python-list
Re: Convert set to list
Larry Martell wrote: > I feel like I've converted sets to lists before. But maybe not. Or > maybe I am losing it from having worked 70 hours this week. > > Shouldn't this work? > > (Pdb) print block['relative_chart1']['vessel_names'] > set([u'Common Carotid', u'External Carotid', u'Internal Carotid']) > (Pdb) type(block['relative_chart1']['vessel_names']) > > (Pdb) list(block['relative_chart1']['vessel_names']) > *** Error in argument: "(block['relative_chart1']['vessel_names'])" Pdb takes the "list" command as a request to list source code. print list(block['relative_chart1']['vessel_names']) should work. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: The next major Python version will be Python 8
On Fri, Apr 1, 2016 at 11:09 AM, Ethan Furman wrote: > On 03/31/2016 05:02 PM, Roel Schroeven wrote: >> >> Victor Stinner schreef op 2016-03-31 23:40: > > >>> Python 3 becomes more and more popular and is close to a dangerous point >>> where it can become popular that Python 2. The PSF decided that it's >>> time to elaborate a new secret plan to ensure that Python users suffer >>> again with a new major release breaking all their legacy code. >> >> >> "2016-03-31 23:40" >> You're 20 minutes early :) > > > No, that's a naive datetime. You need to travel to Victor's location to > figure out what that is there. > > I sure hope Python 8 doesn't have that problem! Now's the time to get in with the ideas. My proposal is that Python 8, in keeping with its new opinionated style, will require everyone to follow a single timezone: Europe/Amsterdam. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: pip.exe issue with 3.5.1
On 1-4-2016 0:27, hellofootball1 . wrote: > So i just downloaded python 3.5.1 on my laptop and my pip.exe was not > working. It would almost immediately close on me after I clicked on it. So > i deleted the scripts folder as all of them did the same thing and then > tried the modify feature and the repair feature of your installer to try > and get pip back but it has not worked. Would you just recommend that I > install 3.4.4 and just use that instead? > No. Pip works fine with python 3.5.1. What did you expect to happen? Pip is not a program that you *click* on, you operate it from the command line instead. Try typing 'pip.exe' on a cmd prompt and go from there. Irmen -- https://mail.python.org/mailman/listinfo/python-list
Re: The next major Python version will be Python 8
Ethan Furman schreef op 2016-04-01 02:09: On 03/31/2016 05:02 PM, Roel Schroeven wrote: Victor Stinner schreef op 2016-03-31 23:40: Python 3 becomes more and more popular and is close to a dangerous point where it can become popular that Python 2. The PSF decided that it's time to elaborate a new secret plan to ensure that Python users suffer again with a new major release breaking all their legacy code. "2016-03-31 23:40" You're 20 minutes early :) No, that's a naive datetime. You need to travel to Victor's location to figure out what that is there. I'm not sure exactly how this stuff works, but I was under the impression that that was a local datetime in Victor's timezone. I might very well be wrong about that. -- The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom. -- Isaac Asimov Roel Schroeven -- https://mail.python.org/mailman/listinfo/python-list
Use pyodbc to count and list tables, columns, indexes, etc
import pyodbc
dbName = "D:\test_data.mdb"
conn = pyodbc.connect('DRIVER={Microsoft Access Driver
(*.mdb)};DBQ='+dbName)
cursor = conn.cursor()
#COUNT TABLES, LIST COLUMNS
tblCount = 0
for rows in cursor.tables():
if rows.table_type == "TABLE": #LOCAL TABLES ONLY
tblCount += 1
print rows.table_name
for fld in cursor.columns(rows.table_name):
print(fld.table_name, fld.column_name)
print tblCount,"tables"
Problem is, the 'for rows' loop executes only once if the 'for fld' loop
is in place. So even if I have 50 tables, the output is like:
DATA_TYPES
(u'DATA_TYPES', u'FLD_TEXT', -9, u'VARCHAR')
(u'DATA_TYPES', u'FLD_MEMO', -10, u'LONGCHAR')
(u'DATA_TYPES', u'FLD_NBR_BYTE', -6, u'BYTE')
1 tables
And no errors are thrown.
If I comment out the 2 'for fld' lines, it counts and lists all 50
tables correctly.
Any ideas?
Thanks!
--
https://mail.python.org/mailman/listinfo/python-list
Re: The next major Python version will be Python 8
On Fri, 1 Apr 2016 11:13 am, Chris Angelico wrote: > Now's the time to get in with the ideas. My proposal is that Python 8, > in keeping with its new opinionated style, will require everyone to > follow a single timezone: Europe/Amsterdam. Swatch Internet time: https://en.wikipedia.org/wiki/Swatch_Internet_Time -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Use pyodbc to count and list tables, columns, indexes, etc
On 3/31/2016 11:44 PM, DFS wrote:
import pyodbc
dbName = "D:\test_data.mdb"
conn = pyodbc.connect('DRIVER={Microsoft Access Driver
(*.mdb)};DBQ='+dbName)
cursor = conn.cursor()
#COUNT TABLES, LIST COLUMNS
tblCount = 0
for rows in cursor.tables():
if rows.table_type == "TABLE": #LOCAL TABLES ONLY
tblCount += 1
print rows.table_name
for fld in cursor.columns(rows.table_name):
print(fld.table_name, fld.column_name)
print tblCount,"tables"
Problem is, the 'for rows' loop executes only once if the 'for fld' loop
is in place. So even if I have 50 tables, the output is like:
DATA_TYPES
(u'DATA_TYPES', u'FLD_TEXT', -9, u'VARCHAR')
(u'DATA_TYPES', u'FLD_MEMO', -10, u'LONGCHAR')
(u'DATA_TYPES', u'FLD_NBR_BYTE', -6, u'BYTE')
1 tables
And no errors are thrown.
If I comment out the 2 'for fld' lines, it counts and lists all 50
tables correctly.
Any ideas?
Thanks!
Never mind! I discovered I just needed a 2nd cursor object for the columns.
---
cursor1 = conn.cursor()
cursor2 = conn.cursor()
tblCount = 0
for rows in cursor1.tables():
if rows.table_type == "TABLE":
tblCount += 1
print rows.table_name
for fld in cursor2.columns(rows.table_name):
print(fld.table_name, fld.column_name)
---
Works splendiferously.
--
https://mail.python.org/mailman/listinfo/python-list
Issue with opening a python file
Hello, I'm relatively new to python. Recently I have been receiving errors every time I attempt to open python files. When try open them, it sends me directly to the 'Modify Setup' window. Clicking on repair or modify does not fix the problem, it simply goes through the repair or modify process and then closes, whilst the problem still persists. Is there any possible fix for this? Thank you -- https://mail.python.org/mailman/listinfo/python-list
Re: Threading is foobared?
Random832 wrote:
> Any chance that it could fix reference headers to match?
>
> Actually, merely prepending the original Message-ID itself to the
> references header might be enough to change the reply's situation from
> "nephew" ("reply to [missing] sibling") to "grandchild" ("reply to
> [missing] reply"), which might be good enough to make threading work
> right on most clients, and would be *easy* (whereas maintaining an
> ongoing reversible mapping may not be).
>
> And if it's not too much additional work, maybe throw in an
> X-Mailman-Original-Message-ID (and -References if anything is done with
> that) field, so that the original state can be recovered.
I think these are good ideas. I'm going to try to do something along
these lines.
> Rather than exclusively rewriting for usenet, maybe the rewritten
> headers could also be included in outgoing emails and the archive?
>
> Putting it in outgoing emails would solve the problem entirely, though
> it would mean people get duplicates if they're subscribed to multiple
> lists to which something is posted or get CC'd. The archive wouldn't
> have this issue.
This is more difficult since archiving, gatewaying to Usenet and
delivery to list members are asynchronous processes that have no way to
communicate with each other.
It could be accomplished by doing a Usenet check in the incoming
pipeline and putting the Mailman Message-ID in the message metadata or
doing the mods at that point, but I don't think I want to expand the
scope of something that is non RFC compliant in the first place.
I need to think about these things some more.
--
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
https://mail.python.org/mailman/listinfo/python-list
Re: Threading is foobared?
Random832 wrote: > One additional thing that would be nice and would solve most of the > duplicate problem with hypothetically including the rewritten > Message-IDs in outgoing emails, would be to detect crossposts to > multiple lists in the same Mailman instance, and to send them to Usenet > (and to subscribers) as a single message, with appropriate headers for a > crosspost. This is difficult to do for various reasons. The main issue is gating to news is asynchronously done by a separate process. Even if the process could reliably determine that another gatewayed list in the installation was a recipient of this post which it could only do by examining explicit addressees and the other list might be a Bcc:, we'd still have to arbitrate somehow which post gets gatewayed to the multiple news groups and which ones get dropped. Although I suppose we could send each one for all the news groups and let the news server figure it out. Anyway, I don't plan to try this. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- https://mail.python.org/mailman/listinfo/python-list
Set type for datetime intervals
Hello,
I need to compare sets of datetime intervals, and make set operations on
them: intersect, union, difference etc. One element of a set would be an
interval like this:
element ::= (start_point_in_time, end_point_in_time)
intervalset ::= { element1, element2, }
Operations on elements:
element1.intersect(element2)
element1.union(element2)
element1.minus(element2)
Operations on sets:
intervalset1.intersect(intervalset2)
intervalset1.union(intervalset2)
intervalset1.minus(intervalset2)
Does anyone know a library that already implements these functions?
Thanks,
Laszlo
--
https://mail.python.org/mailman/listinfo/python-list
Re: Issue with opening a python file
On Fri, 1 Apr 2016 02:56 pm, Daniel Ding wrote: > Hello, I'm relatively new to python. > Recently I have been receiving errors every time I attempt to open python > files. When try open them, it sends me directly to the 'Modify Setup' > window. Clicking on repair or modify does not fix the problem, it simply > goes through the repair or modify process and then closes, whilst the > problem still persists. Is there any possible fix for this? Depends. What has changed? Have you upgrade the OS? (Windows 8 apparently tends to auto-update to Windows 10 without warning.) Installed a new version of Python which doesn't work? What happens if you try to launch the Python application directly, without a file? Open a shell (command.exe or cmd.com or whatever Windows calls it) and try entering "python" or "python3". What happens? If you get an error message, try to copy and paste the complete error message into your reply. Otherwise try to type out the actual error message. Don't bother taking a screen-shot unless the message is extremely large: firstly, this mailing list and newsgroup will delete attachments, so you would have to post it to imgur or similar, and secondly, a screen-shot is of no use to anyone using a screen reader. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
