Any good explanations on pd.merge(df,df2, on=['Code', 'Region'])
I am trying to gain a clear understanding on pd.merge(df,df2, on=['Code', 'Region']). Can anyone assist? Regards, David -- https://mail.python.org/mailman/listinfo/python-list
Re: Any good explanations on pd.merge(df,df2, on=['Code', 'Region'])
On Wed, Nov 08, 2017 at 09:26:04AM +, David Shi via Python-list wrote: > I am trying to gain a clear understanding on pd.merge(df,df2, on=['Code', > 'Region']). > Can anyone assist? ncq@hermes:~$ python Python 2.7.14 (default, Sep 17 2017, 18:50:44) [GCC 7.2.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> pd.merge(df,df2, on=['Code', 'Region']) Traceback (most recent call last): File "", line 1, in NameError: name 'pd' is not defined >>> You will need to provide more context to get help. Regards, Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave
Ned Batchelder writes: > All of this could have been avoided. Steve called an idea arrogant. > Jon felt that Steve was calling him arrogant. If Steve had simply > said, "I'm sorry, I didn't mean that to apply to you," we wouldn't be > here now. Why is it so hard to treat people as if they mattered? I both agree – people are of primary importance, this could have been avoided – and disagree. I see that Steve *did* treat Jon as though he mattered: he gave quite a lot of detailed discourse in getting to the nub of disagreement, and in exploring in various ways what he saw as flaws in some of the ideas expressed. To treat our community members with respect entails, among other things that you rightly champion, the respect of obliging each other to engage with turning an idea around and examining it critically, and to allow one's mind to be changed and discard a bad idea if it is shown to be bad. I think Steve's actions were respectful and civil in that regard. I also think Jon had cause to bristle somewhat at the characterisation. I don't think Jon was attacked by Steve's remark, but I do sympathise with the instinct to feel a criticism as an attack. The criticism of ideas is a respectful, civil action. Can it be done brusquely, even incivilly? Yes, certainly. Is it necessarily an incivil action to criticise an idea harshly? No, I don't think it is. We can be respectful and civil with each other, and simultaneously harsh and disrespectful to ideas held by each other. Done well, it is a respectful thing to criticise ideas harshly: it shows the respect that the person trusts you to recognise and discard a bad idea, when it is convincingly demonstrated. Criticism can of course be done less well, and frequently is. Nothing about this principle, of respectfully holding ideas up to harsh criticism, protects us from instead behaving incivilly and disrespectfully when we botch the attempt. I am in accord with Ian Kelly about that, to be sure. > People are so caught up in proving others wrong and themselves right, > that just saying, "Sorry, I wasn't clear" feels like giving ground. > > We need more civil discussion, and less sniping. We're better than this. Amen to that. -- \ “Timid men prefer the calm of despotism to the boisterous sea | `\of liberty.” —Thomas Jefferson | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Any good explanations on pd.merge(df,df2, on=['Code', 'Region'])
On 8 November 2017 at 11:15, Karsten Hilbert wrote:
> On Wed, Nov 08, 2017 at 09:26:04AM +, David Shi via Python-list wrote:
>
>> I am trying to gain a clear understanding on pd.merge(df,df2, on=['Code',
>> 'Region']).
>> Can anyone assist?
>
> ncq@hermes:~$ python
> Python 2.7.14 (default, Sep 17 2017, 18:50:44)
> [GCC 7.2.0] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> pd.merge(df,df2, on=['Code', 'Region'])
> Traceback (most recent call last):
> File "", line 1, in
> NameError: name 'pd' is not defined
> >>>
>
> You will need to provide more context to get help.
... but given that I happen to know (mostly by chance) that pd is a
commonly used short form when importing Pandas ("import pandas as pd")
you should probably start with the documentation on merge:
https://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.merge.html
If that isn't sufficient for you, please provide a better explanation
of what you don't understand, what you have tried and how it didn't
match your expectations, and maybe someone on the list who is familiar
with Pandas will be able to assist you.
Paul
--
https://mail.python.org/mailman/listinfo/python-list
dictionary comparing int keys and joins their values if two key are within a certain distance
I have a nested dictionary of defaultdict(dict) whose sub dict have int keys
and lists (list of ints) as values,
'A' = {2092: [1573], 2093: [1576, 1575], 2094: [1577], 2095:
[1574]}'B' = {2098: [1], 2099: [2, 3], 2101: [4], 2102: [5]}'C' =
{2001: [6], 2003: [7, 8], 2004: [9], 2005: [10]}
I union two list values if the difference of their sub keys equals to 1 under
the same outer key e.g. A, and put the joined lists into another list. So
this list will look like,
[1573, 1576, 1575, 1577, 1574][1, 2, 3][4, 5][6][7, 8, 9, 10]
here since 2092, 2093, 2094, 2095 are consecutive by 1, their values are
put into a list [1573, 1576, 1575, 1577, 1574].
based on Detecting consecutive integers in a list
,
a simple solution can be built when the distance between two
neighbouring sub keys is set to 1.
results = []for key, sub_dict in d.items():
sub_dict_keys = sorted(sub_dict.keys())
for k, g in groupby(enumerate(sub_dict_keys), lambda ix: ix[0] - ix[1]):
consecutive_keys = list(map(itemgetter(1), g))
val_list = []
for dict_key in consecutive_keys:
val_list.extend(sub_dict[dict_key])
results.append(val_list)
print(results)
, however, the code can only work when the difference between two keys is 1,
I am wondering how to make the code account for an arbitrary distance, e.g.
the distance between two consecutive keys are less than or equal to 2 or 3,
... e.g. set the distance to 2,
'A' = {2092: [1573], 2093: [1576, 1575], 2095: [1577], 2097:
[1574]}'B' = {2098: [1], 2099: [2, 3], 2101: [4], 2102: [5]}'C' =
{2001: [6], 2003: [7, 8], 2008: [9], 2009: [10]}
the result list will look like,
[1573, 1576, 1575, 1577, 1574][1, 2, 3, 4, 5][6, 7, 8][9, 10]
--
https://mail.python.org/mailman/listinfo/python-list
Re: Calling of GetVolumeInformation returns empty serial number
Hello!
Eryk, your solution is the best solution for me:
os.stat(drive).st_dev
I don't need the real ID. I write a Recycle Bin manager in Python - for my
machine only.
It just simply registers all rec. bin files to an SQLite DB (only the new
ones with a date).
After 30 days it deletes too old registered recycle bin files.
Without the serial the external drives make more records for one file (E:\,
F:\, G:\).
And because of different drives I may search in wrong drive (on deletion
process the registered E:\...\x.dcu is on G:\., so I can't find it).
But with this code is I can substitute the drive + RecBin folder with the
serial, and later I can search it in good drive.
Thank you!
dd
2017-11-07 13:10 GMT+01:00 eryk sun :
> On Tue, Nov 7, 2017 at 7:58 AM, Durumdara wrote:
> >
> > I want to get the serial number of the drives (without external modules
> > like Win32 or WMI).
>
> The volume serial number is more easily available as
> os.stat(drive).st_dev, which comes from calling
> GetFileInformationByHandle. Note that despite using the volume serial
> number (VSN) as the nearest equivalent of POSIX st_dev, there is no
> requirement that the VSN is unique or even non-zero. The same applies
> to the file index number that's used for POSIX st_ino. For example,
> both values are 0 on a WebDav drive, for which Python's implementation
> of os.path.samefile is useless. Practically speaking, however, it's
> good enough in most cases, especially for mounted disk volumes.
>
> That said, maybe what you really want is the hardware (disk) serial
> number -- not a volume serial number. The easiest way to get that is
> via WMI. You can use subprocess to run wmic.exe if you don't want an
> external dependency. You can also get the disk serial number by
> calling DeviceIoControl via ctypes. This is a fairly complex
> IOCTL_STORAGE_QUERY_PROPERTY request, with an input
> STORAGE_PROPERTY_QUERY structure requesting the StorageDeviceProperty.
> The result is a STORAGE_DEVICE_DESCRIPTOR structure that has a
> SerialNumberOffset field that's the byte offset from the beginning of
> the buffer of the serial number as a null-terminated string.
>
> Getting back to the VSN, note that the mount-point manager doesn't
> rely on it as a unique identifier. For associating volume devices with
> logical DOS drives and volume GUID names (i.e. names like
> "Volume{12345678----123456789abc}", which are used to
> mount volumes as NTFS junctions), the mount-point manager queries a
> unique ID via IOCTL_MOUNTDEV_QUERY_UNIQUE_ID. Sometimes the volume
> driver returns a unique ID that's very long -- over 200 bytes. This
> doesn't matter because it's only used to uniquely associate a GUID
> name (and maybe a DOS drive) with the given volume when the system
> boots. This association is persisted in HKLM\System\MountedDevices.
>
--
https://mail.python.org/mailman/listinfo/python-list
import issues python3.4
Dear all, I have a software code that is written in python and has a structure like this. package/ run_my_gui.py#gui sub_package/ main.py sub_sub_package/ __init__.py A.py B.py C.py All the imports in main.py are absolute and look like below: (1) from package.sub_package.sub_sub_package import A The issue is I have an external script that tests main.py. I do not want to manually edit all import statements in my code to look like below: (2) from sub_sub_package import A Is there anyway I can run my external script without changing the absolute path from (1) to (2) in my code. I use subprocess.call to run main.py within my external script and it gets few arguments to run. Thanks a lot in advance for your replies, -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)
On Tue, Nov 7, 2017 at 2:42 PM, Chris Angelico wrote: > On Wed, Nov 8, 2017 at 8:16 AM, Ian Kelly wrote: >>> Not one of these is syntactically invalid. Why should "else without >>> break" be trapped by the parser? Your other examples mostly have good >>> parser-level reasons for being errors >> >> No, they don't. All four of them could just as easily also be accepted >> by the parser and only flagged as linter warnings. > > If everyone in the world agreed that a tab was equal to eight spaces, > then I would agree that the tab/space discrepancy could be considered > a linter warning. But there's no such agreement, which means that > having the language declare some equivalency is extremely dangerous. Really? I've never actually heard a story of anybody being bitten by this. I'm not disputing that it was a useful change, but I think "extremely dangerous" is an exaggeration. > Py2 had several language features and misfeatures that are that > dangerous (having the simple name "input()" do evaluation is a trap > that MANY people have fallen into), and it's correct to fix that. If > Python had, from the start, treated tabs and spaces as different forms > of indentation, there would be no reason to change that now. There were also plenty of backward-incompatible changes in Py3 that had nothing to do with dangerous code. > Whether True and False are keywords or builtins is a matter of debate, > but there are definite advantages to them being locked down, and the > only real disadvantage that I see is the question of consistency (eg > "Ellipsis" is not a keyword, so you can still assign to that). The other disadvantages are: making the change was backward-incompatible, and it prevents the user from overriding their values, which might sometimes be useful in the same way that overriding print might sometimes be useful -- which was one of the reasons for demoting print from keyword status! > Having star imports be bypassed when looking for nonlocals is going to > be extremely confusing if you DO import a name from the other module. > There's no right answer to the nonlocal lookup question, so the best > thing to do is to not permit it. There's fundamentally no way for this > to be both legal and sane in all situations, so it can't be left up to > the linter. I disagree. Always using the variable that is explicitly assigned would be both legal and sane in all situations. It also allows an easy fix: just explicitly assign the variable in the scope where you actually want it. Yes, some people might be confused when their star import isn't picked up by nonlocal, but people also get confused by late binding of nonlocals, or the behavior of mutable default values, or the distinction between modifying a list and reassigning it, etc. etc. Nobody is suggesting that defining a closure inside a loop ought to be a SyntaxError, but it is probably something that linters should be looking for, if they don't already. > Mixing 'async def' and 'yield from' is, AIUI, more of a > NotImplementedError than a SyntaxError; the wording of the PEP > basically says that it's low priority, not that it's a bad thing. So > that one is never going to be flagged by a linter - once it's made > possible, it'll be the normal and expected behaviour, so there's no > reason to flag it (except perhaps as "beware that this is not backward > compatible with Python <3.8"). I was not referring to the possible future use of yield from for async generators; I was referring to the possibility *today* of using "yield from" as a synonym for *await*. As far as I know the only major obstacle to that is that the authors (with good reason) made it a SyntaxError. This is exactly the same sort of situation: it's a construct that would otherwise be perfectly valid, but it's made a SyntaxError specifically to prevent users from doing some the devs don't want them to. -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)
On Thu, Nov 9, 2017 at 3:19 AM, Ian Kelly wrote: > I was not referring to the possible future use of yield from for async > generators; I was referring to the possibility *today* of using "yield > from" as a synonym for *await*. As far as I know the only major > obstacle to that is that the authors (with good reason) made it a > SyntaxError. This is exactly the same sort of situation: it's a > construct that would otherwise be perfectly valid, but it's made a > SyntaxError specifically to prevent users from doing some the devs > don't want them to. I don't understand why you would use "yield from" as a synonym for "await". They are not equivalent. Why would you use one in place of the other? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: dictionary comparing int keys and joins their values if two key are within a certain distance
Daiyue Weng wrote:
> I have a nested dictionary of defaultdict(dict) whose sub dict have int
> keys and lists (list of ints) as values,
>
> 'A' = {2092: [1573], 2093: [1576, 1575], 2094: [1577], 2095:
> [1574]}'B' = {2098: [1], 2099: [2, 3], 2101: [4], 2102: [5]}'C' =
> {2001: [6], 2003: [7, 8], 2004: [9], 2005: [10]}
>
> I union two list values if the difference of their sub keys equals to 1
> under the same outer key e.g. A, and put the joined lists into another
> list. So this list will look like,
>
> [1573, 1576, 1575, 1577, 1574][1, 2, 3][4, 5][6][7, 8, 9, 10]
>
> here since 2092, 2093, 2094, 2095 are consecutive by 1, their values are
> put into a list [1573, 1576, 1575, 1577, 1574].
>
> based on Detecting consecutive integers in a list
>
> integers-in-a-list>,
> a simple solution can be built when the distance between two
> neighbouring sub keys is set to 1.
>
> results = []for key, sub_dict in d.items():
> sub_dict_keys = sorted(sub_dict.keys())
> for k, g in groupby(enumerate(sub_dict_keys), lambda ix: ix[0] -
> ix[1]):
> consecutive_keys = list(map(itemgetter(1), g))
> val_list = []
>
> for dict_key in consecutive_keys:
> val_list.extend(sub_dict[dict_key])
>
> results.append(val_list)
> print(results)
>
> , however, the code can only work when the difference between two keys is
> 1, I am wondering how to make the code account for an arbitrary distance,
> e.g. the distance between two consecutive keys are less than or equal to 2
> or 3, ... e.g. set the distance to 2,
>
> 'A' = {2092: [1573], 2093: [1576, 1575], 2095: [1577], 2097:
> [1574]}'B' = {2098: [1], 2099: [2, 3], 2101: [4], 2102: [5]}'C' =
> {2001: [6], 2003: [7, 8], 2008: [9], 2009: [10]}
>
> the result list will look like,
>
> [1573, 1576, 1575, 1577, 1574][1, 2, 3, 4, 5][6, 7, 8][9, 10]
There's a lot of noise in your question. The actual problem has nothing to
do with dictionaries, it's about dividing a list into groups.
The answer boils down to building the groups by identifying gaps between
them instead of calculating a key that is common to the group. To find a gap
you need two adjacent items, and while you can get those by combining tee
and zip, or by constructing a stateful key function that remembers the
previous value I prefer to start from scratch, with the grouped() generator
replacing itertools.groupby():
$ cat group_neighbors_simple.py
from itertools import groupby
def grouped(items, is_neighbor):
items = iter(items)
try:
prev = next(items)
except StopIteration:
return
group = [prev]
for value in items:
if is_neighbor(prev, value):
group.append(value)
else:
yield group
group = [value]
prev = value
yield group
sample = [1, 1, 2, 4, 6, 7, 6]
print([
[v for i, v in group] for key, group in
groupby(enumerate(sample), lambda iv: iv[0] - iv[1])
])
print(list(grouped(sample, lambda a, b: b - a == 1)))
print(list(grouped(sample, lambda a, b: b - a == 2)))
print(list(grouped(sample, lambda a, b: abs(b - a) < 2)))
$ python3 group_neighbors_simple.py
[[1], [1, 2], [4], [6, 7], [6]]
[[1], [1, 2], [4], [6, 7], [6]]
[[1], [1], [2, 4, 6], [7], [6]]
[[1, 1, 2], [4], [6, 7, 6]]
--
https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)
On Wed, Nov 8, 2017 at 9:31 AM, Chris Angelico wrote: > On Thu, Nov 9, 2017 at 3:19 AM, Ian Kelly wrote: >> I was not referring to the possible future use of yield from for async >> generators; I was referring to the possibility *today* of using "yield >> from" as a synonym for *await*. As far as I know the only major >> obstacle to that is that the authors (with good reason) made it a >> SyntaxError. This is exactly the same sort of situation: it's a >> construct that would otherwise be perfectly valid, but it's made a >> SyntaxError specifically to prevent users from doing some the devs >> don't want them to. > > I don't understand why you would use "yield from" as a synonym for > "await". They are not equivalent. Why would you use one in place of > the other? There's not really a good reason to use "yield from" with "async def" when you could just use "await", but the point is that in principle you could. In a generator-based coroutine (e.g. asyncio prior to Python 3.5), "yield from" is used to pause the coroutine and wait on some future. In a native coroutine (e.g. after Python 3.5), "await" is used to pause the coroutine and wait on some future. The implementation AIUI is essentially the same; the __await__ method is even required to return an iterator, just like __iter__. That's why I'm saying that they're basically synonyms. All that's really separating them is the syntax error. -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)
On Thu, Nov 9, 2017 at 5:05 AM, Ian Kelly wrote: > On Wed, Nov 8, 2017 at 9:31 AM, Chris Angelico wrote: >> On Thu, Nov 9, 2017 at 3:19 AM, Ian Kelly wrote: >>> I was not referring to the possible future use of yield from for async >>> generators; I was referring to the possibility *today* of using "yield >>> from" as a synonym for *await*. As far as I know the only major >>> obstacle to that is that the authors (with good reason) made it a >>> SyntaxError. This is exactly the same sort of situation: it's a >>> construct that would otherwise be perfectly valid, but it's made a >>> SyntaxError specifically to prevent users from doing some the devs >>> don't want them to. >> >> I don't understand why you would use "yield from" as a synonym for >> "await". They are not equivalent. Why would you use one in place of >> the other? > > There's not really a good reason to use "yield from" with "async def" > when you could just use "await", but the point is that in principle > you could. In a generator-based coroutine (e.g. asyncio prior to > Python 3.5), "yield from" is used to pause the coroutine and wait on > some future. In a native coroutine (e.g. after Python 3.5), "await" is > used to pause the coroutine and wait on some future. The > implementation AIUI is essentially the same; the __await__ method is > even required to return an iterator, just like __iter__. > > That's why I'm saying that they're basically synonyms. All that's > really separating them is the syntax error. Except that "yield from" is used by generators to delegate to other generators, and "await" is used by coroutines to delegate to other coroutines. In an asynchronous generator, "yield" produces values, and "yield from" would delegate to another asynchronous generator. They are NOT synonyms. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave
On 2017-11-08, Ben Finney wrote: > I also think Jon had cause to bristle somewhat at the characterisation. > I don't think Jon was attacked by Steve's remark, but I do sympathise > with the instinct to feel a criticism as an attack. Steve called me arrogant, that's an attack - never mind that he hadn't the slightest justification for it. If you're going to respond again that he was calling the idea arrogant, then please just stop and think for a moment: an idea, in the abstract, cannot be arrogant. Arrogance is simply not a concept that applies to ideas, it is a concept that applies to people. If you call an idea arrogant you are necessarily stating that the person espousing the idea is guilty of arrogance - that's what the word means. Chris also called the idea "ridiculous", which is also fairly rude, not least because, again, he hadn't the slightest justification for it. The idea is clearly not ridiculous. One might reasonably think that the idea was a bad idea, or unwise, etc, and someone else might reasonably think it isn't - but to call it ridiculous is not legitimate disagrement, it is insulting hyperbole. You have also, in the past, pretty much straight-up called me a liar. That is also, obviously, insulting - yet again, not that you had any justification for it at all. It is my experience of this group/list that if one disagrees with any of you, Steve and Chris, you all rally round and gang up on that person to insult and belittle them. This makes the atmosphere quite hostile, and it would be quite remarkable if it isn't hurting the community by driving people away. Please stop doing it. (Finally, to forestall the inevitable accusation that I am being unusually fragile, please let me point out that I have been around on Usenet since the early 1990s. I am used to flamewars etc. But this is not alt.usenet.kooks, this is comp.lang.python / python-list, and it's supposed to be a civilised discussion forum. If people can't have on-topic discussions without being called ridiculous arrogant liars, then there's something wrong.) -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)
On Wed, Nov 8, 2017 at 11:12 AM, Chris Angelico wrote: > On Thu, Nov 9, 2017 at 5:05 AM, Ian Kelly wrote: >> On Wed, Nov 8, 2017 at 9:31 AM, Chris Angelico wrote: >>> On Thu, Nov 9, 2017 at 3:19 AM, Ian Kelly wrote: I was not referring to the possible future use of yield from for async generators; I was referring to the possibility *today* of using "yield from" as a synonym for *await*. As far as I know the only major obstacle to that is that the authors (with good reason) made it a SyntaxError. This is exactly the same sort of situation: it's a construct that would otherwise be perfectly valid, but it's made a SyntaxError specifically to prevent users from doing some the devs don't want them to. >>> >>> I don't understand why you would use "yield from" as a synonym for >>> "await". They are not equivalent. Why would you use one in place of >>> the other? >> >> There's not really a good reason to use "yield from" with "async def" >> when you could just use "await", but the point is that in principle >> you could. In a generator-based coroutine (e.g. asyncio prior to >> Python 3.5), "yield from" is used to pause the coroutine and wait on >> some future. In a native coroutine (e.g. after Python 3.5), "await" is >> used to pause the coroutine and wait on some future. The >> implementation AIUI is essentially the same; the __await__ method is >> even required to return an iterator, just like __iter__. >> >> That's why I'm saying that they're basically synonyms. All that's >> really separating them is the syntax error. > > Except that "yield from" is used by generators to delegate to other > generators, and "await" is used by coroutines to delegate to other > coroutines. In an asynchronous generator, "yield" produces values, and > "yield from" would delegate to another asynchronous generator. They > are NOT synonyms. Only because the devs have chosen to reserve the possibility of asynchronous generators. Abstractly, coroutines and generators are distinct concepts, but pragmatically, coroutines *are* generators. Native coroutines don't actually change this; they just do a better job of hiding it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave
On Thu, Nov 9, 2017 at 5:18 AM, Jon Ribbens wrote: > On 2017-11-08, Ben Finney wrote: >> I also think Jon had cause to bristle somewhat at the characterisation. >> I don't think Jon was attacked by Steve's remark, but I do sympathise >> with the instinct to feel a criticism as an attack. > > Steve called me arrogant, that's an attack - never mind that he hadn't > the slightest justification for it. If you're going to respond again > that he was calling the idea arrogant, then please just stop and > think for a moment: an idea, in the abstract, cannot be arrogant. > Arrogance is simply not a concept that applies to ideas, it is > a concept that applies to people. If you call an idea arrogant > you are necessarily stating that the person espousing the idea is > guilty of arrogance - that's what the word means. If that's true, then it's not possible for software to be "opinionated" either, because that definitely implies something human. And it's illogical to say "Windows is feeling cranky today" when something inexplicably fails. Nor should you talk about autocorrect "thinking it knows better than you". But all of these are ways that we talk about software. Ideas are just like software for our brains; when they're complex enough, they have lives and characteristics of their own. I suppose if this were comp.lang.iso.standardized.python or something, we could stick with dry and dull language, and avoid any of these problems. But personally, I would consider that a step backwards. The occasional confusion is the price we pay for what we have - and don't forget, we're discussing a language that derives heavily from high class comedy. Please, Jon, accept that we were not deliberately trying to put you down. Steve, if you can clearly state your position on this (possibly worded in the form of an apology?), it would go a long way to clearing this up. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)
On Thu, Nov 9, 2017 at 5:20 AM, Ian Kelly wrote: > On Wed, Nov 8, 2017 at 11:12 AM, Chris Angelico wrote: >> Except that "yield from" is used by generators to delegate to other >> generators, and "await" is used by coroutines to delegate to other >> coroutines. In an asynchronous generator, "yield" produces values, and >> "yield from" would delegate to another asynchronous generator. They >> are NOT synonyms. > > Only because the devs have chosen to reserve the possibility of > asynchronous generators. Abstractly, coroutines and generators are > distinct concepts, but pragmatically, coroutines *are* generators. > Native coroutines don't actually change this; they just do a better > job of hiding it. Coroutines *are implemented using* generators. And I don't know what you mean by "reserve the possibility of"; asynchronous generators do exist: >>> async def gen(): ... yield 1 ... yield 2 ... yield 3 ... await something ... yield 4 ... >>> gen() PEP 525 https://www.python.org/dev/peps/pep-0525/ says: """ While it is theoretically possible to implement yield from support for asynchronous generators, it would require a serious redesign of the generators implementation. """ In other words, it's only because of *implementation details* that "yield from" inside a generator is difficult. There's no language-level reason for it to be forbidden, and there is absolutely NO correlation between "await" and "yield from" in an async function. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave
On 11/08/2017 11:29 AM, Chris Angelico wrote: > If that's true, then it's not possible for software to be > "opinionated" either, because that definitely implies something human. > And it's illogical to say "Windows is feeling cranky today" when > something inexplicably fails. Nor should you talk about autocorrect > "thinking it knows better than you". But all of these are ways that we > talk about software. Ideas are just like software for our brains; when > they're complex enough, they have lives and characteristics of their > own. This reminds me of a classic video clip from a few years ago. The new Microsoft "We Share Your Pain" program. https://www.youtube.com/watch?v=D28FkfJiauk > Please, Jon, accept that we were not deliberately trying > to put you down. Thanks for saying this, Chris. Sometimes we all need to be humble and apologize even when offense was not intended. -- https://mail.python.org/mailman/listinfo/python-list
Re: Any good explanations on pd.merge(df,df2, on=['Code', 'Region'])
Assuming df and df2 are dataframes you are essentially doing a SQL-like join of the two objects where the records within match on both the Code and Region columns Sent from my iPhone -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave
On Thu, Nov 9, 2017 at 6:44 AM, Michael Torrie wrote: > This reminds me of a classic video clip from a few years ago. The new > Microsoft "We Share Your Pain" program. > > https://www.youtube.com/watch?v=D28FkfJiauk I've never actually seen this before. That's awesome! Thanks for sharing :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)
On Wed, Nov 8, 2017 at 11:34 AM, Chris Angelico wrote: > On Thu, Nov 9, 2017 at 5:20 AM, Ian Kelly wrote: >> On Wed, Nov 8, 2017 at 11:12 AM, Chris Angelico wrote: >>> Except that "yield from" is used by generators to delegate to other >>> generators, and "await" is used by coroutines to delegate to other >>> coroutines. In an asynchronous generator, "yield" produces values, and >>> "yield from" would delegate to another asynchronous generator. They >>> are NOT synonyms. >> >> Only because the devs have chosen to reserve the possibility of >> asynchronous generators. Abstractly, coroutines and generators are >> distinct concepts, but pragmatically, coroutines *are* generators. >> Native coroutines don't actually change this; they just do a better >> job of hiding it. > > Coroutines *are implemented using* generators. And I don't know what > you mean by "reserve the possibility of"; asynchronous generators do > exist: They didn't exist when native coroutines were implemented. That's when the possibility was reserved. > PEP 525 https://www.python.org/dev/peps/pep-0525/ says: > """ > While it is theoretically possible to implement yield from support for > asynchronous generators, it would require a serious redesign of the > generators implementation. > """ > > In other words, it's only because of *implementation details* that > "yield from" inside a generator is difficult. There's no > language-level reason for it to be forbidden, and there is absolutely > NO correlation between "await" and "yield from" in an async function. Since we're quoting PEPs, here's what PEP 492 says about "await": https://www.python.org/dev/peps/pep-0492/#id56 """ await, similarly to yield from, suspends execution of [the] coroutine until [the] awaitable completes and returns the result data. It uses the yield from implementation with an extra step of validating its argument. await only accepts an awaitable, which can be one of: * A native coroutine object returned from a native coroutine function. * A generator-based coroutine object returned from a function decorated with types.coroutine(). * An object with an __await__ method returning an iterator. Any yield from chain of calls ends with a yield. This is a fundamental mechanism of how Futures are implemented. Since, internally, coroutines are a special kind of generators, every await is suspended by a yield somewhere down the chain of await calls (please refer to PEP 3156 for a detailed explanation). To enable this behavior for coroutines, a new magic method called __await__ is added. In asyncio, for instance, to enable Future objects in await statements, the only change is to add __await__ = __iter__ line to asyncio.Future class. [remainder of section snipped for brevity] """ Points to note: "similarly to yield from"; "uses the yield from implementation"; "internally, coroutines are a special kind of generators"; "every await is suspended by a yield"; "to enable Future objects in await statements, the only change is to add __await__ = __iter__". "await" was designed to be a *drop-in replacement* for "yield from" so your insistence that they're unrelated is kind of mind-boggling. -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave
Jon Ribbens writes: > On 2017-11-08, Ben Finney wrote: > > I also think Jon had cause to bristle somewhat at the characterisation. > > I don't think Jon was attacked by Steve's remark, but I do sympathise > > with the instinct to feel a criticism as an attack. > > Steve called me arrogant, that's an attack To say that someone is being arrogant simply is not an attack, and I really want you to see that. It's also not true that he called you arrogant. > Arrogance is simply not a concept that applies to ideas, it is > a concept that applies to people. Arrogance, like generosity or cleverness or foolishness, is a concept that applies to *behaviour*. Someone can commit an act that is arrogant, or generous or clever or foolish, and we can call the *idea that informed that act* as arrogant or generous or clever or foolish. > If you call an idea arrogant you are necessarily stating that the > person espousing the idea is guilty of arrogance - that's what the > word means. Yes: it describes the behaviour. It does not imply characterisation of the person. To describe the idea as arrogant, or generous or clever or foolish, is *not* to say that the person holding that idea is arrogant. That would be as unwarranted as calling Bill Gates generous merely because he sometimes gives a small portion of his wealth to charity. Yet we would not hesitate to say that the giving of funds to malaria research is a generous idea. Similarly, to say that someone expressed an arrogant idea is indeed to say their bewhaviour was arrogant, and that necessarily accuses the person of arrogant behaviour. That does not characterise the person as arrogant and it is not an attack on the person. > Chris also called the idea "ridiculous", which is also fairly rude, It is not rude to describe an idea as ridiculous. It is deeply *respectful* to people to show when ideas are ridiculous. If the idea *is* correctly described as ridiculous, we want the *person* to stop holding the ridiculous idea. The idea is not the person, and rudeness to the idea is often *compassion and respect* for the person. (Whether the idea is correctly described that way is a separate matter, of course; that is why discussion is required, preferably with the participation of the person holding the idea.) > The idea is clearly not ridiculous. Great! That should be a good discussion to have. No-one needs to identify with an idea about how software behaves, in order to participate in that discussion; no-one is attacked by merely calling the idea ridiculous. > You have also, in the past, pretty much straight-up called me a liar. > That is also, obviously, insulting - yet again, not that you had any > justification for it at all. I hope that we can do the necessary work of seeking factual basis for claims talk about facts, without calling each other liars. I also hope that we can receive challenges on our claims, without being perceived as under attack. -- \“If you continue running Windows, your system may become | `\unstable.” —Microsoft, Windows 95 bluescreen error message | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave
On Thu, Nov 9, 2017 at 9:22 AM, Ben Finney wrote: >> If you call an idea arrogant you are necessarily stating that the >> person espousing the idea is guilty of arrogance - that's what the >> word means. > > Yes: it describes the behaviour. It does not imply characterisation of > the person. > > To describe the idea as arrogant, or generous or clever or foolish, is > *not* to say that the person holding that idea is arrogant. > > That would be as unwarranted as calling Bill Gates generous merely > because he sometimes gives a small portion of his wealth to charity. Yet > we would not hesitate to say that the giving of funds to malaria > research is a generous idea. > > Similarly, to say that someone expressed an arrogant idea is indeed to > say their bewhaviour was arrogant, and that necessarily accuses the > person of arrogant behaviour. That does not characterise the person as > arrogant and it is not an attack on the person. Yep. My way of looking at this is: actions are generous, or arrogant, or whatever, based on the moral decisions behind them. (So for example, it doesn't count as "generous" to accidentally drop a whole lot of money to the Mudders of Higgins' Moon, even though people benefited a lot from it.) To describe a *person* as any of those things is to say that you expect, on balance, that this person's decisions (and thus actions) are likely to fit that description. You would describe Superman as altruistic and a helper of those in trouble, because you can confidently expect that he will selflessly help anyone who needs it. Describing *him* as altruistic is a descriptor/predictor. To call a *person* arrogant is to say "Not only was this action of yours arrogant, I fully expect that your future actions will be arrogant too". But that isn't what happened here. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave
On 11/8/17 5:22 PM, Ben Finney wrote: Jon Ribbens writes: On 2017-11-08, Ben Finney wrote: I also think Jon had cause to bristle somewhat at the characterisation. I don't think Jon was attacked by Steve's remark, but I do sympathise with the instinct to feel a criticism as an attack. Steve called me arrogant, that's an attack To say that someone is being arrogant simply is not an attack, and I really want you to see that. Ben, this idea is really stupid! Be honest: when you read what I just wrote, did you feel a dispassionate discussion starting, or did you feel a bit attacked? I think it is unrealistic to expect people to be completely dissociated from the ideas they hold. Second, now you want us to agree that calling someone arrogant isn't an attack? Perhaps you are able to discuss your own behavior this way, but I assure you, most people are not. You are holding up this kind of distance from yourself as an ideal we should all strive for. To me it seems like a Dr.-Spock-like separation from feelings. People don't work this way. How many paragraphs of close parsing are we going to twist ourselves through, just to avoid saying, "Yeah, sorry, that went a bit far. I didn't want to alienate you in the pursuit of a demonstration of my own correctness." --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave
On 09Nov2017 05:29, Chris Angelico wrote: On Thu, Nov 9, 2017 at 5:18 AM, Jon Ribbens wrote: On 2017-11-08, Ben Finney wrote: I also think Jon had cause to bristle somewhat at the characterisation. I don't think Jon was attacked by Steve's remark, but I do sympathise with the instinct to feel a criticism as an attack. Steve called me arrogant, that's an attack - never mind that he hadn't the slightest justification for it. If you're going to respond again that he was calling the idea arrogant, then please just stop and think for a moment: an idea, in the abstract, cannot be arrogant. I'm with Jon here. Arrogance is simply not a concept that applies to ideas, it is a concept that applies to people. If you call an idea arrogant you are necessarily stating that the person espousing the idea is guilty of arrogance - that's what the word means. If that's true, then it's not possible for software to be "opinionated" either, because that definitely implies something human. [...] That is also true (let us ignore hypothical sentient software). And I admit that I have myself spoken of "opinionated" software, and when I do so I'm usually talking about software with IMO excessive "policy" over mechanism, particularly software whose policy cannot be adjusted. When I do that, the opinion/policy comes from the developer (mandated by management or not) and arguably I'm impugning the quality of the dev's decisions. While I'd hope that a term like "opinionated" might be tolerable (though in some contexts, particularly with an audience of the dev's peers or colleagues, possibly a source of affront), I think I'm again with Jon on "arrogant": without a lot of context or ambiance, I think I'd take this as personal and somewhat attacking if it were used directed at me or my code. I've just dug out the source posting, Message-ID <[email protected]>, and we've already got the word "obvious" being bandied about in a slightly heated exchange. I've discovered myself that "obvious" is a remarkably subjective desciption. I think Jon is arguing that an "obvious" inference is inherently "right" and that if the language semantics don't match that, _particularly_ in a language like Python where significant thought has gone into making the language read quite naturally to most English speakers, then such a disconnect between an obvious/intuitive expectation of the code's prose and the actual language semantics constitutes a design bug. I think Steve was making the point that the language's semntics are what they are and that inferring different semantics, regardless of how obvious they seem, is the wrong thing to do. And then went on to characterise an inferred "idea of purity" as "arrogant and foolish". I think I can, myself, imagine why Steve thinks of the idea this way, but that will be inference on inference. Regardless, I think that "arrogant and foolish" crosses into incivility, to use Ben's term. And that is because, as Jon remarks, "an idea, in the abstract, cannot be arrogant"; the terms inherently characterise the person holding the idea. And because of that, I want to argue for avoiding terms like this. I've definitely sinned in this way myself in the past. In the distant past, a _lot_. Particularly here (python-list) I try to reread my own posts for this kind of thing before sending (and also for my very high typo rate). We _should_ strive really hard to be dispassionate and civil, _particularly_ when criticising things: criticism is usually unpleasant to receive, regardless of how valid or constructive. I'm not a big believer in "egoless programming" as my ego is bound up in my desire for quality, but a consequence of that is that criticism _is_ received personally, and therefore it should be as well phrased as feasible. Before signing out, let me hark to some words from the glorious film "Harvey": "I used to be smart. I recommend nice." Cheers, Cameron Simpson (formerly [email protected]) -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave
Jon Ribbens : > It is my experience of this group/list that if one disagrees with any > of you, Steve and Chris, you all rally round and gang up on that > person to insult and belittle them. This makes the atmosphere quite > hostile, and it would be quite remarkable if it isn't hurting the > community by driving people away. Please stop doing it. This forum is about a dead thing, a programming language. I wouldn't make too big a deal about "the community." If someone's postings constantly frustrate you, simply place them in your killfile. I've done that to people. People have done that to me. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave
Ned Batchelder writes: > On 11/8/17 5:22 PM, Ben Finney wrote: > > To say that someone is being arrogant simply is not an attack, and I > > really want you to see that. > Ben, this idea is really stupid! > > Be honest: when you read what I just wrote, did you feel a > dispassionate discussion starting, or did you feel a bit attacked? I feel attacked. Does that mean I am attacked? If I feel attacked, does that mean one should never call an idea stupid? I think the answer to both those questions is “no”. > I think it is unrealistic to expect people to be completely > dissociated from the ideas they hold. I don't expect that. What I do expect is that people will, when experiencing that feeling, to figure out whether the feeling of attack reflects the nature of what happened, or merely a perception. That's how I expect adults to behave. Sometimes we – and of course I include myself – don't meet that, yet we need to keep aiming for that. > Second, now you want us to agree that calling someone arrogant isn't > an attack? It's one thing to say “this idea is arrogant”, which is what Steve did. That's not in any way personal, nor an attack on a person. It criticises an idea. If instead Steve said “that was an arrogant action”, the person is being criticised. But it's still not *characterising* the person; it characterises the action. It says nothing about whether the person is arrogant. If instead of either of those Steve said “you are arrogant”, that would warrant the response, in my estimation. That it got nowhere near that is why I'm pleading that we stop treating criticism of ideas as though it were an attack on a person. > Perhaps you are able to discuss your own behavior this way Too often I fail. But it's what we need to keep trying to do. > but I assure you, most people are not. I think we are better than that. We all have these responses to some degree; we can choose to respond differently. I think we can, and I ask that we do. > You are holding up this kind of distance from yourself as an ideal we >should all strive for. To me it seems like a Dr.-Spock-like separation >from feelings. People don't work this way. We can't avoid feeling what we feel, and I would never fault someone for that. > How many paragraphs of close parsing are we going to twist ourselves > through, just to avoid saying, "Yeah, sorry, that went a bit far. I > didn't want to alienate you in the pursuit of a demonstration of my > own correctness." I don't have any aim of avoiding that. If I need to apologise for something, that hasn't been made clear to me. If you're seeking an apology from someone else, I can't do it for them. What has been made clear to me is that we have a long way to go in pursuit of allowing ideas to be held at arm's length, discussed and criticised, with respect and compassion for one another. -- \ “[…] we don’t understand what we mean when we say that [God] is | `\‘good’, ‘wise’, or ‘intelligent’.” —Karen Armstrong, _The Case | _o__) For God_, 2009 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave
Marko Rauhamaa writes: > Jon Ribbens : > > It is my experience of this group/list that if one disagrees with any > > of you, Steve and Chris, you all rally round and gang up on that > > person to insult and belittle them. This makes the atmosphere quite > > hostile, and it would be quite remarkable if it isn't hurting the > > community by driving people away. Please stop doing it. > > This forum is about a dead thing, a programming language. I wouldn't > make too big a deal about "the community." On the contrary, this forum is about a *community of people*, formed around a programming language. The community is primary here, I am in full agreement with Jon on that. -- \“Room service? Send up a larger room.” —Groucho Marx | `\ | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
converting numbers into words
How can I covert numbers into word like ex:-123 One hundred twenty three? -- https://mail.python.org/mailman/listinfo/python-list
Re: converting numbers into words
On Wednesday, November 8, 2017 at 10:51:35 PM UTC-8, [email protected] wrote: > How can I covert numbers into word like ex:-123 One hundred twenty three? That's a classic homework exercise. Expect guidance, not an answer. Why don't you solve a related, but simpler task first? This is a good approach to learning computer programming. Write a program that accepts a single digit as input, and outputs the corresponding word. Post the code here. -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave
Chris Angelico wrote: I don't understand why you would use "yield from" as a synonym for "await". They are not equivalent. Why would you use one in place of the other? As far as I understand, currently the implementations of "yield from" and "await" are sufficiently similar that they *would* be equivalent if the compiler didn't go out of its way to prevent you from mixing them up. It does that because they're conceptually different things, and a future version of CPython might implement them differently. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
