Re: A new feature request - parser add_mutually_exclusive_group - add a default value
Thank you. Uri. אורי u...@speedy.net On Tue, Jul 9, 2024 at 6:40 PM Barry Scott wrote: > > > On 9 Jul 2024, at 06:13, אורי via Python-list <python-list@python.org> > wrote: > > I tried to subscribe to Python-ideas > > > These days ideas are discussed on https://discuss.python.org/ > It is rare to see an idea on the mailing list. > > Barry > > > -- https://mail.python.org/mailman/listinfo/python-list
Re: A new feature request - parser add_mutually_exclusive_group - add a default value
> On 9 Jul 2024, at 06:13, אורי via Python-list <python-list@python.org> > wrote: > > I tried to subscribe to Python-ideas These days ideas are discussed on https://discuss.python.org/ It is rare to see an idea on the mailing list. Barry -- https://mail.python.org/mailman/listinfo/python-list
A new feature request - parser add_mutually_exclusive_group - add a default value
Hi, Please look at this Stack Overflow post: https://stackoverflow.com/questions/78722378/parser-add-mutually-exclusive-group-how-can-i-set-a-default-value 1. Is there a way to add a default to parser add_mutually_exclusive_group groups - a value that will be set by default? In this case I want test-default-languages=True to be set as a default. 2. I tried to subscribe to Python-ideas python-id...@python.org, but I can't login to https://mail.python.org/mailman3/lists/python-ideas.python.org/. Although I did login to https://mail.python.org/mailman/options/python-list . Do I have to create a new account? Thanks, Uri. אורי u...@speedy.net -- https://mail.python.org/mailman/listinfo/python-list
Re: Feature Request
On Wed, 23 Mar 2022 01:55:37 -0700 (PDT), Kazuya Ito
declaimed the following:
>Add "trun()" function to Python to truncate decimal part.
You'll have to define what specific behavior you think is missing from
the currently available functions?
>>> plusover = 2.78
>>> plusunder = 3.14
>>> minusover = -2.78
>>> minusunder = -3.14
>>> import math
>>> for v in (plusover, plusunder, minusover, minusunder):
... print("%s: int %s, round %s, math.trunc %s, math.floor %s,
math.ceil %s"
... % (v, int(v), round(v), math.trunc(v), math.floor(v),
math.ceil(v)))
...
2.78: int 2, round 3, math.trunc 2, math.floor 2, math.ceil 3
3.14: int 3, round 3, math.trunc 3, math.floor 3, math.ceil 4
-2.78: int -2, round -3, math.trunc -2, math.floor -3, math.ceil -2
-3.14: int -3, round -3, math.trunc -3, math.floor -4, math.ceil -3
>>>
int() and .trunc() move toward 0, .floor() moves to less positive,
.ceil() moves to more positive.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Feature Request
On 23/03/2022 03.55, Kazuya Ito wrote: Add "trun()" function to Python to truncate decimal part. Which of these should its behavior copy? from math import pi int(pi) 3 pi-int(pi) 0.14159265358979312 -- Michael F. Stemper This post contains greater than 95% post-consumer bytes by weight. -- https://mail.python.org/mailman/listinfo/python-list
Feature Request
Add "trun()" function to Python to truncate decimal part. -- https://mail.python.org/mailman/listinfo/python-list
Python 3 Feature Request: `pathlib` Use Trailing Slash Flag
`pathlib` trims trailing slashes by default, but certain packages require
trailing slashes. In particular, `cx_Freeze.bdist_msi` option "directories" is
used to build the package directory structure of a program and requires
trailing slashes.
Does anyone think it would be a good idea to add a flag or argument to
`pathlib.Path` to keep trailing slashes? For instance, I envision something
like:
```
from pathlib import Path
my_path = Path(r"foo/bar/", keep_trailing_slash=True)
```
The argument could be made `False` by default to maintain backwards
compatibility. The only way I know to keep the backslash and maintain
cross-compatibility is as follows:
```
import os
from pathlib import Path
my_path = f"{Path(r"foo/bar").resolve()}{os.sep}"
```
although this returns a string and the `Path` object is lost.
Any thoughts?
--
https://mail.python.org/mailman/listinfo/python-list
Feature request: method to cancel or bail out from fileinput.input(inplace=True)
After using https://docs.python.org/3/library/fileinput.html to open a file for inplace filtering, a backup is created before output is redirected to the new file. It is possible, but non-trivial and non-obvious, to bail out of this situation, putting the backed up file back in place and ending the output redirection. My request is for a .cancel() or similar method that will automate this bail out process, leaving the filesystem and streams in the state they were in before fileinput.input() was called. The primary use case for this functionality would be upon encountering an exception in the middle of file processing. While on the subject, I also believe the following additional functionality would be worthwhile, even without fulfillment of the main request: A method to return the extension provided for the backup file, and/or to return the full name of the backup file. A parameter to disallow silent overwrite of the backup file. -- https://mail.python.org/mailman/listinfo/python-list
Re: Undocumented issue: Open system call blocks on named pipes (and a feature request)
On 28Dec2018 20:21, Daniel Ojalvo wrote: I agree that previous behavior shouldn't be changed, but I would suggest updating the documentation to point it out as a footnote. The current behavior is correct just unclear. Most people just learning about the open command wouldn't have this expectation. Maybe, maybe not. "Most" is a conjecture. IMO people will only find it surprising if they think any filesystem object can be instantly opened. However that is a misapprehension on their part. My personal expectation is that open() will come back when the object is open. I don't have a timeframe in mind unless I have a strong expectation about _what_ I'm opening. I came across the issue when I had a program that would open up all the files in a directory to read a few bytes from the beginning. My concern would be someone just making a named pipe over a file that a program would open. What about a symlink to a magic /dev/tcp/host:port device, initiating a TCP connection? Particularly if "host" is down or inaccessible? Etc. Arguably, anyone affected by that would be shooting themselves in the foot to begin with, but I think there are "security" concerns because someone could cause a bit of mischief that would be difficult to diagnose. It isn't hard to diagnose at all. Point strace at the hung pogram, see it is opening some path, "ls -ld the-path", oooh, it isn't a regular file. The point here is that if a programme opens every file in a directory, maybe it should constrain itself to regular files. Opening anything else may not just hang, it can have real world side effects. (Usually such effect happen at some point after open, for example opening a rewind take device will physicially rewind the tape on close, but you've committed to that happening by opening it in the first place.) I think Chris offered the example of a subdirectory to suggest that such a programme already has an opnion about what to open and what to leave alone (unless is _does_ open() subdirectories, which might be useful but is usually misleading and on some OSes unsupported). So the programme should be pickier anyway. That all being said, I think I would like to put in a feature request for a non-blocking option. How should I go about doing so? I agree with the suggestion already made: devise a well thought out proposal which fits nicely with the existing open() call (eg an addition to the mode argument or something), and describe it clearly in python-ideas. Certainly a number of things can be opened in a "nonblocking" mode, which means that reads return instantly if there's no available data, so having an open not block isn't unreasonable to want. But it may be unreasonable to implement in general: OSes may not support it directly. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Undocumented issue: Open system call blocks on named pipes (and a feature request)
On Sat, Dec 29, 2018 at 7:21 AM Daniel Ojalvo wrote: > > Thank you for the advice! > > I haven't used the opener argument before, but I'll keep it for future > reference. I think it's still a little kludge-y, but it works. It has a very similar effect to what you were proposing, but still works within the normal open() ecosystem. Its main benefit is that it works on existing Pythons, whereas any idea proposed today can't get into 3.7 and maybe not even 3.8. > I agree that previous behavior shouldn't be changed, but I would suggest > updating the documentation to point it out as a footnote. The current > behavior is correct just unclear. Most people just learning about the open > command wouldn't have this expectation. > That's what I'm not sure about. Do people really have an expectation of nonblocking behaviour? > I came across the issue when I had a program that would open up all the files > in a directory to read a few bytes from the beginning. My concern would be > someone just making a named pipe over a file that a program would open. > Arguably, anyone affected by that would be shooting themselves in the foot to > begin with, but I think there are "security" concerns because someone could > cause a bit of mischief that would be difficult to diagnose. > What happens if someone has a subdirectory in there? To be resilient against everything you might come across, you probably need to check anyway. > That all being said, I think I would like to put in a feature request for a > non-blocking option. How should I go about doing so? Hmm, there are a few options. If you reckon it's pretty easy, you could just go straight to a GitHub pull request, and discuss it there. Or you could open a bugs.python.org tracker issue and hope someone else does the coding. Alternatively, you could find out who else supports the idea by posting to the python-id...@python.org mailing list. Of those, I think posting to python-ideas is possibly the best, as there will likely be some bikeshedding about the name and such. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: Undocumented issue: Open system call blocks on named pipes (and a feature request)
Thank you for the advice!
I haven't used the opener argument before, but I'll keep it for future
reference. I think it's still a little kludge-y, but it works.
I agree that previous behavior shouldn't be changed, but I would suggest
updating the documentation to point it out as a footnote. The current behavior
is correct just unclear. Most people just learning about the open command
wouldn't have this expectation. I came across the issue when I had a program
that would open up all the files in a directory to read a few bytes from the
beginning. My concern would be someone just making a named pipe over a file
that a program would open. Arguably, anyone affected by that would be shooting
themselves in the foot to begin with, but I think there are "security" concerns
because someone could cause a bit of mischief that would be difficult to
diagnose.
That all being said, I think I would like to put in a feature request for a
non-blocking option. How should I go about doing so?
Thanks again,
Dan
-Original Message-
From: Chris Angelico
Sent: Thursday, December 27, 2018 7:10 PM
To: python-list@python.org
Subject: Re: Undocumented issue: Open system call blocks on named pipes (and a
feature request)
On Fri, Dec 28, 2018 at 1:38 PM Daniel Ojalvo via Python-list
wrote:
>
> Hello,
>
> I've been working on a python3 project and I came across an issue with the
> open system call that, at the very least, isn't documented. In my humble
> opinion, the
> documentation<https://docs.python.org/3/library/functions.html#open> should
> be updated because folks wouldn't expect open to be a blocking operation and
> simply error out. Worse yet, open doesn't have an option to make itself
> non-blocking. You have to use the os system calls to kludge a solution.
>
Hmm. I disagree that the docs are deceptive here; I would normally expect
open() to block if it needs to. But looking at this as a feature request, it
seems reasonable. Actually, it's not even that hard to do, since open() is
already pluggable:
rosuav@sikorsky:~/tmp$ rm rene_magritte
rosuav@sikorsky:~/tmp$ mkfifo rene_magritte rosuav@sikorsky:~/tmp$ ls -l
rene_magritte
prw-r--r-- 1 rosuav rosuav 0 Dec 28 14:05 rene_magritte rosuav@sikorsky:~/tmp$
python3 Python 3.8.0a0 (heads/master:8b9c33ea9c, Nov 20 2018, 02:18:50) [GCC
6.3.0 20170516] on linux Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> def nonblock(fn, mode): return os.open(fn, mode | os.O_NONBLOCK)
...
>>> open("rene_magritte", opener=nonblock)
<_io.TextIOWrapper name='rene_magritte' mode='r' encoding='UTF-8'>
>>> _.read(1)
''
> Here is how I reproduced the issue:
>
> root@beefy:~/sandbox# mkfifo this_is_a_pipe
(my example file name is a more subtle reference...)
> I'm doing this to get a fileobject and make it error out if we do have a
> blocking special file:
> with os.fdopen(os.open(, os.O_RDONLY| os.O_NONBLOCK) , mode='rb')
> as file_obj:
>
> I think this is mostly a documentation bug because this wouldn't be expected
> behavior to someone reading the docs, but open is behaving as the fifo man
> page<http://man7.org/linux/man-pages/man7/fifo.7.html> is documented. The
> feature request would be to add a non-blocking option to the default open
> system call.
>
Honestly, I don't think there's a problem with it blocking by default.
Most of Python works that way. But it would be pretty straight-forward to add
"nonblocking=False" as another keyword-only parameter, and for compatibility
with existing versions (back as far as 3.3), the opener should work just fine.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Undocumented issue: Open system call blocks on named pipes (and a feature request)
On Sat, Dec 29, 2018 at 4:24 AM Grant Edwards wrote:
>
> On 2018-12-27, Daniel Ojalvo via Python-list wrote:
>
> open("this_is_a_pipe")
> >
>
> Opening a tty device can also block[1]. However, if somebody is using
> the open() builtin on tty devices that's probably the least of their
> problems.
Depending on what you mean by "block", pretty much anything can. It's
not indefinite, but this is clearly an example of blocking behaviour:
rosuav@sikorsky:~$ mkdir gideon_home
rosuav@sikorsky:~$ sshfs gideon: gideon_home/
rosuav@sikorsky:~$ python3
Python 3.8.0a0 (heads/master:8b9c33ea9c, Nov 20 2018, 02:18:50)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.time(); open("gideon_home/.bashrc"); time.time()
1546018477.1130645
<_io.TextIOWrapper name='gideon_home/.bashrc' mode='r' encoding='UTF-8'>
1546018477.8339248
Due to the latency introduced by having a completely-out-of-cache
remote access directory, simply opening an ordinary file with an
ordinary path took over half a second. But *this* type of blocking
access is NOT changed by adding os.O_NONBLOCK; it will still take that
half second even if you say "opener=nonblock". OTOH, this form of
blocking is a lot safer - normal file systems [1] might be slow, but
they can't deadlock, whereas a pipe most certainly could.
ChrisA
[1] Of course, you could use fusermount and shenanigans to do
basically anything. But at that point, you're deliberately shooting
yourself in the foot, and all I can advise is "don't do that".
--
https://mail.python.org/mailman/listinfo/python-list
Re: Undocumented issue: Open system call blocks on named pipes (and a feature request)
On 2018-12-27, Daniel Ojalvo via Python-list wrote:
open("this_is_a_pipe")
>
Opening a tty device can also block[1]. However, if somebody is using
the open() builtin on tty devices that's probably the least of their
problems.
[1] Technically, opening any character-mode device could block --
serial ports are the only "common" example I can think of.
--
Grant Edwards grant.b.edwardsYow! How many retured
at bricklayers from FLORIDA
gmail.comare out purchasing PENCIL
SHARPENERS right NOW??
--
https://mail.python.org/mailman/listinfo/python-list
Re: Undocumented issue: Open system call blocks on named pipes (and a feature request)
On Fri, Dec 28, 2018 at 1:38 PM Daniel Ojalvo via Python-list
wrote:
>
> Hello,
>
> I've been working on a python3 project and I came across an issue with the
> open system call that, at the very least, isn't documented. In my humble
> opinion, the
> documentation<https://docs.python.org/3/library/functions.html#open> should
> be updated because folks wouldn't expect open to be a blocking operation and
> simply error out. Worse yet, open doesn't have an option to make itself
> non-blocking. You have to use the os system calls to kludge a solution.
>
Hmm. I disagree that the docs are deceptive here; I would normally
expect open() to block if it needs to. But looking at this as a
feature request, it seems reasonable. Actually, it's not even that
hard to do, since open() is already pluggable:
rosuav@sikorsky:~/tmp$ rm rene_magritte
rosuav@sikorsky:~/tmp$ mkfifo rene_magritte
rosuav@sikorsky:~/tmp$ ls -l rene_magritte
prw-r--r-- 1 rosuav rosuav 0 Dec 28 14:05 rene_magritte
rosuav@sikorsky:~/tmp$ python3
Python 3.8.0a0 (heads/master:8b9c33ea9c, Nov 20 2018, 02:18:50)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> def nonblock(fn, mode): return os.open(fn, mode | os.O_NONBLOCK)
...
>>> open("rene_magritte", opener=nonblock)
<_io.TextIOWrapper name='rene_magritte' mode='r' encoding='UTF-8'>
>>> _.read(1)
''
> Here is how I reproduced the issue:
>
> root@beefy:~/sandbox# mkfifo this_is_a_pipe
(my example file name is a more subtle reference...)
> I'm doing this to get a fileobject and make it error out if we do have a
> blocking special file:
> with os.fdopen(os.open(, os.O_RDONLY| os.O_NONBLOCK) , mode='rb')
> as file_obj:
>
> I think this is mostly a documentation bug because this wouldn't be expected
> behavior to someone reading the docs, but open is behaving as the fifo man
> page<http://man7.org/linux/man-pages/man7/fifo.7.html> is documented. The
> feature request would be to add a non-blocking option to the default open
> system call.
>
Honestly, I don't think there's a problem with it blocking by default.
Most of Python works that way. But it would be pretty straight-forward
to add "nonblocking=False" as another keyword-only parameter, and for
compatibility with existing versions (back as far as 3.3), the opener
should work just fine.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Undocumented issue: Open system call blocks on named pipes (and a feature request)
Hello,
I've been working on a python3 project and I came across an issue with the open
system call that, at the very least, isn't documented. In my humble opinion,
the documentation<https://docs.python.org/3/library/functions.html#open> should
be updated because folks wouldn't expect open to be a blocking operation and
simply error out. Worse yet, open doesn't have an option to make itself
non-blocking. You have to use the os system calls to kludge a solution.
Here is how I reproduced the issue:
root@beefy:~/sandbox# mkfifo this_is_a_pipe
root@beefy:~/sandbox# ls -l this_is_a_pipe
prw-r--r-- 1 root root 0 Dec 27 14:28 this_is_a_pipe
root@beefy:~/sandbox# python3 --version
Python 3.6.7
root@beefy:~/sandbox# python3
Python 3.6.7 (default, Oct 22 2018, 11:32:17)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> open("this_is_a_pipe")
The mitigation is to use the os calls and specify to be nonblocking when
opening the file.
I'm doing this to get a fileobject and make it error out if we do have a
blocking special file:
with os.fdopen(os.open(, os.O_RDONLY| os.O_NONBLOCK) , mode='rb') as
file_obj:
I think this is mostly a documentation bug because this wouldn't be expected
behavior to someone reading the docs, but open is behaving as the fifo man
page<http://man7.org/linux/man-pages/man7/fifo.7.html> is documented. The
feature request would be to add a non-blocking option to the default open
system call.
I've also found this with some named special character files, but I don't have
a reproduction at the moment.
Thank you and have a good day!
Dan
--
https://mail.python.org/mailman/listinfo/python-list
Re: Feature Request: Reposition Execution
Am 15.05.15 um 05:58 schrieb Skybuck Flying: Thanks for the ideas, I haven't tried them yet. I wonder if they will work in a multi-threaded fashion. I doubt it. The run_script runs in it's own thread. It would be of enormous help if you would create a minimal script just like the above for your situation. What does it mean, runs in a thread? How do you achieve that from Jython? The exception would have to be raise from another thread. (The other thread check for errors and needs to abort the run script). Well usually you can pass messages between the threads, wait for termination etc. I've got no experience with threading in Jython; however this site http://www.jython.org/jythonbook/en/1.0/Concurrency.html suggests that there is a large number of primitives available to do that. Concerning "Resume", what do you expect: A) starting afresh from the beginning or B) continue the execution at the point where the exception was thrown? Because A) is/should be easy, B) could be impossible Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: Feature Request: Reposition Execution
"Steven D'Aprano" wrote in message
news:5553145b$0$9$c3e8...@news.astraweb.com...
On Wednesday 13 May 2015 17:27, Christian Gollwitzer wrote:
A clean way to exit your script could be to raise an exception. It
should propagate to the toplevel and halt your script. However it is not
possible to back and resume the execution.
"
while True:
try:
run_script() # May raise TryAgain
break
except TryAgain:
pass
If you prefer to only retry a finite number of times:
for i in range(10):
try:
run_script() # May raise TryAgain
break
except TryAgain:
pass
else:
# break skips past the for...else block
raise GiveUpError('too many failures')
"
Hi,
Thanks for the ideas, I haven't tried them yet.
I wonder if they will work in a multi-threaded fashion.
I doubt it.
The run_script runs in it's own thread.
The exception would have to be raise from another thread. (The other thread
check for errors and needs to abort the run script).
I doubt thread B can interrupt thread A via exceptions/exception handling
?!?
Bye,
Skybuck.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Feature Request: Reposition Execution
On Wednesday 13 May 2015 17:27, Christian Gollwitzer wrote:
> A clean way to exit your script could be to raise an exception. It
> should propagate to the toplevel and halt your script. However it is not
> possible to back and resume the execution.
while True:
try:
run_script() # May raise TryAgain
break
except TryAgain:
pass
If you prefer to only retry a finite number of times:
for i in range(10):
try:
run_script() # May raise TryAgain
break
except TryAgain:
pass
else:
# break skips past the for...else block
raise GiveUpError('too many failures')
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
Re: Feature Request: Reposition Execution
Am 12.05.15 um 22:18 schrieb Skybuck Flying: Thanks for suggestion, but I need a solution which can work in SikuliX as well. What the hell is that? Especially inside an observer handler that would be ideal. So far os.kill() is not supported in SikuliX as far as I can tell. OK a quick look to the webpage sikulix.com suggests, that it is based on Java and Python runs on top of the JVM (Jython). So maybe there is a JVM based mechanism to do that. A clean way to exit your script could be to raise an exception. It should propagate to the toplevel and halt your script. However it is not possible to back and resume the execution. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: Feature Request: Reposition Execution
"Dave Angel" wrote in message news:mailman.354.1431345441.12865.python-l...@python.org... On 05/11/2015 07:46 AM, Skybuck Flying wrote: Hello, Sometimes it can be handy to "interrupt/reset/reposition" a running script. For example something externally goes badly wrong. " os.kill() then in your process, handle the exception, and do whatever you think is worthwhile. " Thanks for suggestion, but I need a solution which can work in SikuliX as well. Especially inside an observer handler that would be ideal. So far os.kill() is not supported in SikuliX as far as I can tell. Bye, Skybuck. -- https://mail.python.org/mailman/listinfo/python-list
Re: Feature Request: Reposition Execution
On 2015-05-11, Steven D'Aprano wrote:
> On Mon, 11 May 2015 09:57 pm, Dave Angel wrote:
>
>> On 05/11/2015 07:46 AM, Skybuck Flying wrote:
>>> Hello,
>>>
>>> Sometimes it can be handy to "interrupt/reset/reposition" a running
>>> script.
>>>
>>> For example something externally goes badly wrong.
>>>
>>
>> os.kill()
>>
>> then in your process, handle the exception, and do whatever you think is
>> worthwhile.
>
>
> Are you suggesting that the app sends itself a signal?
>
> Is that even allowed?
Of course (at least on Unix/Linux/Posix systems).
And there's even a special case defined to make sending signals to
yourself easy: you just send them to PID 0.
>From "man 2 kill" on Linux:
DESCRIPTION
The kill() system call can be used to send any signal to any
process group or process.
[...]
If pid equals 0, then sig is sent to every process in the
process group of the calling process.
And just to make sure I ran a little test, and it works exactly as
advertised:
-testit.py
#!/usr/bin/python
import os, sys, time, threading, signal
def thread1():
while True:
sys.stdout.write("Hello %s\n" % time.time())
time.sleep(1)
threading.Thread(target=thread1).start()
time.sleep(2)
os.kill(0,signal.SIGKILL)
---
$ ./testit.py
Hello 1431354383.19
Hello 1431354384.19
Killed
$
--
Grant Edwards grant.b.edwardsYow! Hello. Just walk
at along and try NOT to think
gmail.comabout your INTESTINES being
almost FORTY YARDS LONG!!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Feature Request: Reposition Execution
On 05/11/2015 08:35 AM, Steven D'Aprano wrote: On Mon, 11 May 2015 09:57 pm, Dave Angel wrote: On 05/11/2015 07:46 AM, Skybuck Flying wrote: Hello, Sometimes it can be handy to "interrupt/reset/reposition" a running script. For example something externally goes badly wrong. os.kill() then in your process, handle the exception, and do whatever you think is worthwhile. Are you suggesting that the app sends itself a signal? Is that even allowed? No idea if it's allowed. I didn't notice his sample was multithreaded, as i grabbed on the "externally goes badly wrong". -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Feature Request: Reposition Execution
On Mon, 11 May 2015 09:57 pm, Dave Angel wrote: > On 05/11/2015 07:46 AM, Skybuck Flying wrote: >> Hello, >> >> Sometimes it can be handy to "interrupt/reset/reposition" a running >> script. >> >> For example something externally goes badly wrong. >> > > os.kill() > > then in your process, handle the exception, and do whatever you think is > worthwhile. Are you suggesting that the app sends itself a signal? Is that even allowed? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Feature Request: Reposition Execution
Dave Angel : > On 05/11/2015 07:46 AM, Skybuck Flying wrote: >> Hello, >> >> Sometimes it can be handy to "interrupt/reset/reposition" a running script. >> For example something externally goes badly wrong. > > os.kill() > > then in your process, handle the exception, and do whatever you think > is worthwhile. One thing that gives me trouble quite often is that Ctrl-C doesn't kill a multithreaded Python program. Instead, you need to do: Ctrl-Z [1]+ Stopped kill %1 Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Feature Request: Reposition Execution
On 05/11/2015 07:46 AM, Skybuck Flying wrote: Hello, Sometimes it can be handy to "interrupt/reset/reposition" a running script. For example something externally goes badly wrong. os.kill() then in your process, handle the exception, and do whatever you think is worthwhile. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Feature Request: Reposition Execution
Hello, Sometimes it can be handy to "interrupt/reset/reposition" a running script. For example something externally goes badly wrong. The script is unaware of this. Current solution would require to have an "Abort" boolean everywhere. The abort boolean could then be set to True to indicate all code and all loops must abort. This is far from the ideal solution. I think a much better solution could be to "reposition" the "instruction pointer" so to speak. However for x86 stack clean up would be necessary. I would assume python has a stack too... which would need cleaning up. Perhaps the entire stack can simply be cleaned up. So that the point for execution continuation is always "clean" in a "clean state". So this allows for the stack to be cleaned completely... without any trouble. I also hope this feature gets implemented quickly cause I kinda need it. Therefore I will give some example code to see how it could look like: def MyFunction(): while SomeCondition: RunMyCode return def OtherFunction(): while BatmanIsAliveLOL: BustPenguins return def DetectProblem: if ProblemDetected: Aborted = True Abort( AbortToPoint ) return SpawnThread( DetectProblem) while MyMainLoop: AbortToPoint: if Aborted: Reset stuff MainCode, Call Routines. Bye, Skybuck. -- https://mail.python.org/mailman/listinfo/python-list
Re: idle feature request
On 2/11/2015 9:48 PM, Rustom Mody wrote: On Thursday, February 12, 2015 at 7:57:48 AM UTC+5:30, Terry Reedy wrote: If one saves the shell with 'save as', the filename is added to the title bar. If one does something more, the name in bracketed with *s to indicate the the memory buffer has been changed since it was last saved. This is the same as regular edit windows. However, when one quits, then, unlike a regular edit window, there is no ask-to-save warning. Is this what you want? This would seem reasonable and likely easy. The Shell window is a subclass of the (base) Editor window. So enhancement 1, invoke ask-to-save after save-as should be easy. Find the current code (grep the message) and determine why it does not work for the shell. Saving the shell is, I believe, rare, and I believe there is half a chance that a person who has saved the shell once will want to do so again. (I would, however, not want the prompt when the buffer has not been saved -- or this could be a configuration option.) Enhancement 2 would be adding a configuration option to invoke ask-to-save even without save-as. I am sure that this would be harder. Yeah thats what I want. In a file-window there is 'ask-to-save' as soon as a single character is typed. I want similar for shell window. As I said if there is a config option for that, thats best. But if I have to put in a few lines in my own idle that's fine too². [BTW I have some other feature requests too. Is this the best forum to talk of them? And thanks for your work on idle :-) ] Idle-sig is pretty dead, so go ahead here. You do not have to search the tracker if you do not want to. I have a categorized list of all Idle issues on the tracker (with issue numbers) and will look up ideas against that list anyway. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: idle feature request
On 12/02/2015 02:48, Rustom Mody wrote: [BTW I have some other feature requests too. Is this the best forum to talk of them? And thanks for your work on idle :-) ] Here is as good a place as any although there is an IDLE development mailing list at https://mail.python.org/mailman/listinfo/idle-dev or gmane.comp.python.idle Have you checked on the bug tracker to see what has already been requested? Also have you seen IDLEX http://idlex.sourceforge.net/ ? You might be able to beg, steal or borrow something from it and it's available from pypi. -- 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: idle feature request
On Thu, Feb 12, 2015 at 1:27 PM, Terry Reedy wrote: > However, when one quits, then, unlike a regular edit window, there is no > ask-to-save warning. Is this what you want? This would seem reasonable and > likely easy. (I would, however, not want the prompt when the buffer has not > been saved -- or this could be a configuration option.) That's my understanding of the request, too. It seems reasonable to have a way to be prompted about saving. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: idle feature request
On Thursday, February 12, 2015 at 7:57:48 AM UTC+5:30, Terry Reedy wrote: > On 2/11/2015 1:00 PM, Mark Lawrence wrote: > > On 11/02/2015 13:11, Rustom Mody wrote: > >> Context: > >> I am using idle for taking python classes. > > Teaching or taking? Teaching -- I would like to mail¹ students the interaction so they can pay more attention and less bother about taking notes. > > >> Finish the class and run out usually in a hurry and forget to save the > >> idle interaction window. > > Do you mean the shell window? Yeah > > >> Would like to save it so that I can mail it to the students. > > Then save it. What am I not understainding? Your problem scenario is > not clear to me. See below for a possible description that I do understand. > > >> In emacs I could set a hook to make arbitrary 'buffers' like the > >> python-idle > >> shell become 'saving-buffers' like typical file buffers. > >> ie in emacs like most other editors, a modified file is ask-to-save > > That is true in Idle as well. > > >> The same can be setup for other (non-file) buffers like a python > >> interaction shell > > I have never used emacs so I do not understand your reference thereto. > In Windows, the interactive console history cannot be saved except by > awkwardly selecting and cutting. Idle does allow the shell contents to > be saved. > > >> Can I do the same for idle. > > "Same what?" is the question. > > > If there isn't an enhancement request on the bug tracker for this please > > raise one, that way this doesn't get lost. > > Let us clarify the request here first. > > If one saves the shell with 'save as', the filename is added to the > title bar. If one does something more, the name in bracketed with *s to > indicate the the memory buffer has been changed since it was last saved. > This is the same as regular edit windows. > > However, when one quits, then, unlike a regular edit window, there is no > ask-to-save warning. Is this what you want? This would seem reasonable > and likely easy. (I would, however, not want the prompt when the buffer > has not been saved -- or this could be a configuration option.) Yeah thats what I want. In a file-window there is 'ask-to-save' as soon as a single character is typed. I want similar for shell window. As I said if there is a config option for that, thats best. But if I have to put in a few lines in my own idle that's fine too². [BTW I have some other feature requests too. Is this the best forum to talk of them? And thanks for your work on idle :-) ] ¹ I just discovered that mail is passe and they would prefer whatsapp! Well whatever :-) ² I have a class tomorrow! (but I'll try to remember)!! -- https://mail.python.org/mailman/listinfo/python-list
Re: idle feature request
On 2/11/2015 1:00 PM, Mark Lawrence wrote: On 11/02/2015 13:11, Rustom Mody wrote: Context: I am using idle for taking python classes. Teaching or taking? Finish the class and run out usually in a hurry and forget to save the idle interaction window. Do you mean the shell window? Would like to save it so that I can mail it to the students. Then save it. What am I not understainding? Your problem scenario is not clear to me. See below for a possible description that I do understand. In emacs I could set a hook to make arbitrary 'buffers' like the python-idle shell become 'saving-buffers' like typical file buffers. ie in emacs like most other editors, a modified file is ask-to-save That is true in Idle as well. The same can be setup for other (non-file) buffers like a python interaction shell I have never used emacs so I do not understand your reference thereto. In Windows, the interactive console history cannot be saved except by awkwardly selecting and cutting. Idle does allow the shell contents to be saved. Can I do the same for idle. "Same what?" is the question. If there isn't an enhancement request on the bug tracker for this please raise one, that way this doesn't get lost. Let us clarify the request here first. If one saves the shell with 'save as', the filename is added to the title bar. If one does something more, the name in bracketed with *s to indicate the the memory buffer has been changed since it was last saved. This is the same as regular edit windows. However, when one quits, then, unlike a regular edit window, there is no ask-to-save warning. Is this what you want? This would seem reasonable and likely easy. (I would, however, not want the prompt when the buffer has not been saved -- or this could be a configuration option.) -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: idle feature request
On 11/02/2015 13:11, Rustom Mody wrote: Context: I am using idle for taking python classes. Finish the class and run out usually in a hurry and forget to save the idle interaction window. Would like to save it so that I can mail it to the students. In emacs I could set a hook to make arbitrary 'buffers' like the python-idle shell become 'saving-buffers' like typical file buffers. ie in emacs like most other editors, a modified file is ask-to-save The same can be setup for other (non-file) buffers like a python interaction shell Can I do the same for idle. [Note it would be great to have this feature in idle but I am only looking for a hand in where in the idle sources I an fudge a patch for my own use ] If there isn't an enhancement request on the bug tracker for this please raise one, that way this doesn't get lost. -- 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: idle feature request
On 11.02.2015 14:29, Rustom Mody wrote: So getting up and running with minimal headache is an important priority. Yes true. I consider Notebooks as a way to do "frontal" teaching, not necessarily usefull if students have to redo what you are doing on screen. For that, notebooks are rather prone to confusion because the order with wich you run the cells is important, so total beginners are really confused about variables overwritting etc. Fabien -- https://mail.python.org/mailman/listinfo/python-list
Re: idle feature request
On Wednesday, February 11, 2015 at 6:50:35 PM UTC+5:30, Fabien wrote: > On 11.02.2015 14:11, Rustom Mody wrote: > > Context: > > I am using idle for taking python classes. > > I know this is not your question, but: have you considered using iPython > notebooks for teaching? They save automatically, look nice, and can be > sent as code, html, rst, ... > > Fabien Yeah I have considered (and thanks for reminding). However we are at that peculiar point where - de jure college provides computers - de facto everyone has a laptop Exploiting the second is a big advantage but its also chaos. Some windows; some linux; some macs etc So getting up and running with minimal headache is an important priority. -- https://mail.python.org/mailman/listinfo/python-list
Re: idle feature request
On 11.02.2015 14:11, Rustom Mody wrote: Context: I am using idle for taking python classes. I know this is not your question, but: have you considered using iPython notebooks for teaching? They save automatically, look nice, and can be sent as code, html, rst, ... Fabien -- https://mail.python.org/mailman/listinfo/python-list
idle feature request
Context: I am using idle for taking python classes. Finish the class and run out usually in a hurry and forget to save the idle interaction window. Would like to save it so that I can mail it to the students. In emacs I could set a hook to make arbitrary 'buffers' like the python-idle shell become 'saving-buffers' like typical file buffers. ie in emacs like most other editors, a modified file is ask-to-save The same can be setup for other (non-file) buffers like a python interaction shell Can I do the same for idle. [Note it would be great to have this feature in idle but I am only looking for a hand in where in the idle sources I an fudge a patch for my own use ] -- https://mail.python.org/mailman/listinfo/python-list
Re: argparse feature request
On 2013-11-22 18:15, Neal Becker wrote: Robert Kern wrote: On 2013-11-22 16:52, Neal Becker wrote: Robert Kern wrote: On 2013-11-22 14:56, Neal Becker wrote: I use arparse all the time and find it serves my needs well. One thing I'd like to see. In the help message, I'd like to automatically add the default values. What I'd like to see is: --size SIZE [2000] <<< the default value is displayed Use formatter_class=argparse.ArgumentDefaultsHelpFormatter http://docs.python.org/2/library/argparse#argparse.ArgumentDefaultsHelpFormatter Thanks! Almost perfect. Problem is, I don't usually bother to add help='help me' options. It seems that ArgumentDefaultsHelpFormatter doesn't do anything unless help='blah' option is used. Not sure what to do about that. Since python test_freq3.py -h produces useful messages without my adding help=... everywhere, it'd be nice if ArgumentDefaultsHelpFormatter would work here. Patches are welcome, I am sure. Implement a HelpFormatter that does what you want. _format_action() is where the relevant logic is. Try something like this, and modify to suit. class BeckerDefaultFormatter(argparse.ArgumentDefaultsHelpFormatter): def _format_action(self, action): monkeypatched = False if action.default is not None and action.help is None: # Trick the default _format_action() method into writing out # the defaults. action.help = ' ' monkeypatched = True formatted = super(BeckerDefaultFormatter, self)._format_action(action) if monkeypatched: action.help = None return formatted Thanks! Seems to work great. It gave reasonable output for both case where I include help=... and also without. I have no idea how that above code works, but I guess as long as it works... Just take a look at the implementation of HelpFormatter._format_action() and look for where my monkeypatch would change the logic. It took me just a few minutes to figure out how to do it in the first place. There really isn't anything tricky going on. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- https://mail.python.org/mailman/listinfo/python-list
Re: argparse feature request
Robert Kern wrote: > On 2013-11-22 16:52, Neal Becker wrote: >> Robert Kern wrote: >> >>> On 2013-11-22 14:56, Neal Becker wrote: I use arparse all the time and find it serves my needs well. One thing I'd like to see. In the help message, I'd like to automatically add the default values. > What I'd like to see is: --size SIZE [2000] <<< the default value is displayed >>> >>> Use formatter_class=argparse.ArgumentDefaultsHelpFormatter >>> >>> >>> http://docs.python.org/2/library/argparse#argparse.ArgumentDefaultsHelpFormatter > >> Thanks! Almost perfect. Problem is, I don't usually bother to add >> help='help >> me' options. It seems that ArgumentDefaultsHelpFormatter doesn't do anything >> unless help='blah' option is used. Not sure what to do about that. Since >> python test_freq3.py -h >> produces useful messages without my adding help=... everywhere, it'd be nice >> if ArgumentDefaultsHelpFormatter would work here. > > Patches are welcome, I am sure. Implement a HelpFormatter that does what you > want. _format_action() is where the relevant logic is. Try something like > this, and modify to suit. > > > class BeckerDefaultFormatter(argparse.ArgumentDefaultsHelpFormatter): > > def _format_action(self, action): > monkeypatched = False > if action.default is not None and action.help is None: > # Trick the default _format_action() method into writing out > # the defaults. > action.help = ' ' > monkeypatched = True > formatted = super(BeckerDefaultFormatter, > self)._format_action(action) if monkeypatched: > action.help = None > return formatted > Thanks! Seems to work great. It gave reasonable output for both case where I include help=... and also without. I have no idea how that above code works, but I guess as long as it works... -- https://mail.python.org/mailman/listinfo/python-list
Re: argparse feature request
On 2013-11-22 16:52, Neal Becker wrote: Robert Kern wrote: On 2013-11-22 14:56, Neal Becker wrote: I use arparse all the time and find it serves my needs well. One thing I'd like to see. In the help message, I'd like to automatically add the default values. What I'd like to see is: --size SIZE [2000] <<< the default value is displayed Use formatter_class=argparse.ArgumentDefaultsHelpFormatter http://docs.python.org/2/library/argparse#argparse.ArgumentDefaultsHelpFormatter Thanks! Almost perfect. Problem is, I don't usually bother to add help='help me' options. It seems that ArgumentDefaultsHelpFormatter doesn't do anything unless help='blah' option is used. Not sure what to do about that. Since python test_freq3.py -h produces useful messages without my adding help=... everywhere, it'd be nice if ArgumentDefaultsHelpFormatter would work here. Patches are welcome, I am sure. Implement a HelpFormatter that does what you want. _format_action() is where the relevant logic is. Try something like this, and modify to suit. class BeckerDefaultFormatter(argparse.ArgumentDefaultsHelpFormatter): def _format_action(self, action): monkeypatched = False if action.default is not None and action.help is None: # Trick the default _format_action() method into writing out # the defaults. action.help = ' ' monkeypatched = True formatted = super(BeckerDefaultFormatter, self)._format_action(action) if monkeypatched: action.help = None return formatted -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- https://mail.python.org/mailman/listinfo/python-list
Re: argparse feature request
Robert Kern wrote:
> On 2013-11-22 14:56, Neal Becker wrote:
>> I use arparse all the time and find it serves my needs well. One thing I'd
>> like
>> to see. In the help message, I'd like to automatically add the default
>> values.
>>
>> For example, here's one of my programs:
>>
>> python3 test_freq3.py --help
>> usage: test_freq3.py [-h] [--size SIZE] [--esnodB ESNODB] [--tau TAU]
>> [--trials TRIALS]
>> [--training TRAINING] [--sps SPS] [--si SI] [--alpha
>> [ALPHA] --range RANGE] [--dfunc {gradient,delay}]
>> [--mod
>> {gaussian,qpsk,8psk,16apsk,32apsk,32dlr,64apsk,256apsk}]
>> [--sym-freq-err SYM_FREQ_ERR] [--calibrate [CALIBRATE]]
>>
>> optional arguments:
>>-h, --helpshow this help message and exit
>>--size SIZE
>>--esnodB ESNODB, -e ESNODB
>>--tau TAU, -t TAU
>>--trials TRIALS
>>--training TRAINING
>>--sps SPS
>>--si SI
>>--alpha ALPHA
>>--range RANGE
>>--dfunc {gradient,delay}
>>--mod {gaussian,qpsk,8psk,16apsk,32apsk,32dlr,64apsk,256apsk}
>>--sym-freq-err SYM_FREQ_ERR
>>--calibrate [CALIBRATE], --with-calibrate [CALIBRATE], --enable-calibrate
>> [CALIBRATE], --no-calibrate [CALIBRATE], --without-calibrate [CALIBRATE], --
>> disable-calibrate [CALIBRATE]
>>
>> What I'd like to see is:
>>
>> --size SIZE [2000] <<< the default value is displayed
>
> Use formatter_class=argparse.ArgumentDefaultsHelpFormatter
>
>
http://docs.python.org/2/library/argparse#argparse.ArgumentDefaultsHelpFormatter
>
> E.g.
>
> [git/mpstack]$ cat print_stacks.py
> ...
> def main():
> import argparse
> parser = argparse.ArgumentParser(
> formatter_class=argparse.ArgumentDefaultsHelpFormatter)
> parser.add_argument('-p', '--percent', action='store_true', help='Show
> percentages.')
> parser.add_argument('file', help='The sample file.')
> ...
>
> [git/mpstack]$ python print_stacks.py -h
> usage: print_stacks.py [-h] [-p] file
>
> positional arguments:
>file The sample file.
>
> optional arguments:
>-h, --help show this help message and exit
>-p, --percent Show percentages. (default: False)
>
Thanks! Almost perfect. Problem is, I don't usually bother to add help='help
me' options. It seems that ArgumentDefaultsHelpFormatter doesn't do anything
unless help='blah' option is used. Not sure what to do about that. Since
python test_freq3.py -h
produces useful messages without my adding help=... everywhere, it'd be nice
if ArgumentDefaultsHelpFormatter would work here.
--
https://mail.python.org/mailman/listinfo/python-list
Re: argparse feature request
On 2013-11-22 14:56, Neal Becker wrote:
I use arparse all the time and find it serves my needs well. One thing I'd like
to see. In the help message, I'd like to automatically add the default values.
For example, here's one of my programs:
python3 test_freq3.py --help
usage: test_freq3.py [-h] [--size SIZE] [--esnodB ESNODB] [--tau TAU] [--trials
TRIALS]
[--training TRAINING] [--sps SPS] [--si SI] [--alpha
ALPHA]
[--range RANGE] [--dfunc {gradient,delay}]
[--mod
{gaussian,qpsk,8psk,16apsk,32apsk,32dlr,64apsk,256apsk}]
[--sym-freq-err SYM_FREQ_ERR] [--calibrate [CALIBRATE]]
optional arguments:
-h, --helpshow this help message and exit
--size SIZE
--esnodB ESNODB, -e ESNODB
--tau TAU, -t TAU
--trials TRIALS
--training TRAINING
--sps SPS
--si SI
--alpha ALPHA
--range RANGE
--dfunc {gradient,delay}
--mod {gaussian,qpsk,8psk,16apsk,32apsk,32dlr,64apsk,256apsk}
--sym-freq-err SYM_FREQ_ERR
--calibrate [CALIBRATE], --with-calibrate [CALIBRATE], --enable-calibrate
[CALIBRATE], --no-calibrate [CALIBRATE], --without-calibrate [CALIBRATE], --
disable-calibrate [CALIBRATE]
What I'd like to see is:
--size SIZE [2000] <<< the default value is displayed
Use formatter_class=argparse.ArgumentDefaultsHelpFormatter
http://docs.python.org/2/library/argparse#argparse.ArgumentDefaultsHelpFormatter
E.g.
[git/mpstack]$ cat print_stacks.py
...
def main():
import argparse
parser = argparse.ArgumentParser(
formatter_class=argparse.ArgumentDefaultsHelpFormatter)
parser.add_argument('-p', '--percent', action='store_true', help='Show
percentages.')
parser.add_argument('file', help='The sample file.')
...
[git/mpstack]$ python print_stacks.py -h
usage: print_stacks.py [-h] [-p] file
positional arguments:
file The sample file.
optional arguments:
-h, --help show this help message and exit
-p, --percent Show percentages. (default: False)
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
--
https://mail.python.org/mailman/listinfo/python-list
argparse feature request
I use arparse all the time and find it serves my needs well. One thing I'd
like
to see. In the help message, I'd like to automatically add the default values.
For example, here's one of my programs:
python3 test_freq3.py --help
usage: test_freq3.py [-h] [--size SIZE] [--esnodB ESNODB] [--tau TAU] [--trials
TRIALS]
[--training TRAINING] [--sps SPS] [--si SI] [--alpha ALPHA]
[--range RANGE] [--dfunc {gradient,delay}]
[--mod
{gaussian,qpsk,8psk,16apsk,32apsk,32dlr,64apsk,256apsk}]
[--sym-freq-err SYM_FREQ_ERR] [--calibrate [CALIBRATE]]
optional arguments:
-h, --helpshow this help message and exit
--size SIZE
--esnodB ESNODB, -e ESNODB
--tau TAU, -t TAU
--trials TRIALS
--training TRAINING
--sps SPS
--si SI
--alpha ALPHA
--range RANGE
--dfunc {gradient,delay}
--mod {gaussian,qpsk,8psk,16apsk,32apsk,32dlr,64apsk,256apsk}
--sym-freq-err SYM_FREQ_ERR
--calibrate [CALIBRATE], --with-calibrate [CALIBRATE], --enable-calibrate
[CALIBRATE], --no-calibrate [CALIBRATE], --without-calibrate [CALIBRATE], --
disable-calibrate [CALIBRATE]
What I'd like to see is:
--size SIZE [2000] <<< the default value is displayed
--
https://mail.python.org/mailman/listinfo/python-list
Re: Feature Request: `operator.not_in`
On 4/19/13 2:27 PM, Terry Jan Reedy wrote: On 4/19/2013 10:27 AM, Matthew Gilson wrote: ) It seems to me that the operator module should have a `not_in` or `not_contains` function. It seems asymmetric that there exists a `is_not` function which implements `x is not y` but there isn't a function to represent `x not in y`. There is also no operator.in. True. I'm not arguing that there should be ... There is operator.contains and operator.__contains__. Thankfully :-) There is no operator.not_contains because there is no __not_contains__ special method. (Your point two, which I disagree with.) But there's also no special method `__is_not__`, but there's a corresponding `is_not` in the operator module so I don't really see that argument. It's a matter of functionality that I'm thinking about in the first part. itertools.starmap(operator.not_in,x,y) vs. itertools.starmap(lambda a,b: a not in b,x,y) Pretty much every other operator in python (that I can think of) has an analogous function in the operator module. 2) I suspect this one might be a little more controversial, but it seems to me that there should be a separate magic method bound to the `not in` operator. The reference manual disagrees. "The operator not in is defined to have the inverse true value of in." I would still leave that as the default behavior. It's by far the most useful and commonly expected. And I suppose if you *can't* have default behavior like that because that is a special case in itself, then that makes this second part of the request dead in the water at the outset (and I can live with that explanation). Currently, when inspecting the bytecode, it appears to me that `not x in y` is translated to `x not in y` (this supports item 1 slightly). However, I don't believe this should be the case. In python, `x < y` does not imply `not x >= y` because a custom object can do whatever it wants with `__ge__` and `__lt__` -- They don't have to fit the normal mathematical definitions. The reason for this is that the rich comparisons do not have to return boolean values, and do not for numarray arrays which, I believe, implement the operators itemwise. Yes, you're correct about numpy arrays behaving that way. It can be very useful for indexing them. It would also be fine for a special method `__not_contains__` to be expected to return a boolean value as well. It could still be very useful. Consider a finite square well from quantum mechanics. I could define `in` for my particle in the square well to return `True` if there is a 70% chance that it is located in the well (It's a wave-function, so it doesn't have a well defined position -- the particle could be anyway, but 7 out of 10 measurements will tell me it's in the well). It might be nice if I could define `not in` to be `True` if there is only a 30% chance that it is in the well. Of course, this leaves us with a no-man's land around the 50% mark. Is it in the well or not? There's no telling. I'm sure you could argue that this sort of thing *could* be done with rich comparisons, but I would consider that a deflection from the point at hand. It seems it should be up to the user to design the API most suited for their task. Or what about a `Fraternity` class. Are the new pledges in the fraternity or not? Maybe they should be considered neither in, nor out until pledge season is over. > I don't see any reason why containment should behave differently. 'Design by analogy' is tricky because analogies often leave out important details. __contains__ *is* expected to return true/false. " object.__contains__(self, item) Called to implement membership test operators. Should return true if item is in self, false otherwise" -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature Request: `operator.not_in`
On 4/19/2013 10:27 AM, Matthew Gilson wrote: ) It seems to me that the operator module should have a `not_in` or `not_contains` function. It seems asymmetric that there exists a `is_not` function which implements `x is not y` but there isn't a function to represent `x not in y`. There is also no operator.in. There is operator.contains and operator.__contains__. There is no operator.not_contains because there is no __not_contains__ special method. (Your point two, which I disagree with.) 2) I suspect this one might be a little more controversial, but it seems to me that there should be a separate magic method bound to the `not in` operator. The reference manual disagrees. "The operator not in is defined to have the inverse true value of in." Currently, when inspecting the bytecode, it appears to me that `not x in y` is translated to `x not in y` (this supports item 1 slightly). However, I don't believe this should be the case. In python, `x < y` does not imply `not x >= y` because a custom object can do whatever it wants with `__ge__` and `__lt__` -- They don't have to fit the normal mathematical definitions. The reason for this is that the rich comparisons do not have to return boolean values, and do not for numarray arrays which, I believe, implement the operators itemwise. > I don't see any reason why containment should behave differently. 'Design by analogy' is tricky because analogies often leave out important details. __contains__ *is* expected to return true/false. " object.__contains__(self, item) Called to implement membership test operators. Should return true if item is in self, false otherwise" -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Feature Request: `operator.not_in`
I believe that I read somewhere that this is the place to start discussions on feature requests, etc. Please let me know if this isn't the appropriate venue (and what the appropriate venue would be if you know). This request has 2 related parts, but I think they can be considered seperately: 1) It seems to me that the operator module should have a `not_in` or `not_contains` function. It seems asymmetric that there exists a `is_not` function which implements `x is not y` but there isn't a function to represent `x not in y`. 2) I suspect this one might be a little more controversial, but it seems to me that there should be a separate magic method bound to the `not in` operator. Currently, when inspecting the bytecode, it appears to me that `not x in y` is translated to `x not in y` (this supports item 1 slightly). However, I don't believe this should be the case. In python, `x < y` does not imply `not x >= y` because a custom object can do whatever it wants with `__ge__` and `__lt__` -- They don't have to fit the normal mathematical definitions. I don't see any reason why containment should behave differently. `x in y` shouldn't necessarily imply `not x not in y`. I'm not sure if `object` could have a default `__not_contains__` method (or whatever name seems most appropriate) implemented equivalently to: def __not_contains__(self,other): return not self.__contains__(other) If not, it could probably be provided by something like `functools.total_ordering`. Anyway, it's food for thought and I'm interested to see if anyone else feels the same way that I do. Thanks, ~Matt -- http://mail.python.org/mailman/listinfo/python-list
Re: [Bug / Feature Request] IDLE Shell
On Wed, Apr 13, 2011 at 11:50 AM, rantingrick wrote: > In the IDLE shell when pressing the key combos "Control+Up" and > "Control+Down" the insertion cursor should jump to the nearest prompt > (>>>) above or below it's current position respectively. > > Note: In the Editor Window of IDLE the current behavior is for the > insertion cursor to jump to the next block (which is just fine for the > Editing Source code!) HOWEVER in the shell we need a much more > intelligent behavior. Not to be rude or anything - but why can't you get the latest IDLE source code, patch it, test it, see how you like it and if you feel it useful, share the patch and/or file a bug with the patch. cheers James -- -- James Mills -- -- "Problems are solved by method" -- http://mail.python.org/mailman/listinfo/python-list
[Bug / Feature Request] IDLE Shell
Hello folks, In the IDLE shell when pressing the key combos "Control+Up" and "Control+Down" the insertion cursor should jump to the nearest prompt (>>>) above or below it's current position respectively. Note: In the Editor Window of IDLE the current behavior is for the insertion cursor to jump to the next block (which is just fine for the Editing Source code!) HOWEVER in the shell we need a much more intelligent behavior. py> shell != editor True -- http://mail.python.org/mailman/listinfo/python-list
Re: [Feature Request] dict.setdefault()
On 04/11/2011 05:44 PM, Chris Angelico wrote:
On Tue, Apr 12, 2011 at 8:41 AM, MRAB wrote:
I'm not sure that "setdefault" should take **kw args for this because
of its existing argument structure (key + optional value).
A new method like "updatedefault" may be better, IMHO. It would act
like "update" except that it wouldn't overwrite existing values.
Wouldn't x.updatedefault(y) be pretty much y.update(x) ?
As I understand, the difference would be the following pseudocode:
def update(self, d):
for k,v in dict(d).iteritems():
self[k] = v
def updatedefault(self, d={}, **kwargs):
for k,v in chain(
dict(d).iteritems(),
kwargs.iteritems()
):
# MRAB's comment about "wouldn't overwrite existing"
if k not in self:
self[k] = v
My concern with the initial request is that dict.setdefault()
already returns the (existent or defaulted) value, so you can do
things like
d.setdefault(my_key, []).append(item)
If you allow it to take multiple kwargs, what would the return
value be (positionality of kwargs is lost, so returning a tuple
wouldn't be readily possible)?
Finally, if it were added, I'd call it something like merge()
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Feature Request] dict.setdefault()
On 11/04/2011 23:44, Chris Angelico wrote: On Tue, Apr 12, 2011 at 8:41 AM, MRAB wrote: I'm not sure that "setdefault" should take **kw args for this because of its existing argument structure (key + optional value). A new method like "updatedefault" may be better, IMHO. It would act like "update" except that it wouldn't overwrite existing values. Wouldn't x.updatedefault(y) be pretty much y.update(x) ? I suppose it would, except that it wouldn't be in-place as such, and it wouldn't be as efficient if you're wanting to default only a few entries in a larger dict. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Feature Request] dict.setdefault()
On Mon, Apr 11, 2011 at 2:35 PM, rantingrick wrote:
>
> setdefault should take **kw args in the case of needing to set
> multiple defaults at one time. I would even settle for an *arg list if
> i had to.
What would the return value be? dict.setdefault() doesn't currently
just return None you know.
> Anything is better than...
>
> d.setdefault(blah, blah)
> d.setdefault(blah, blah)
> d.setdefault(blah, blah)
> d.setdefault(blah, blah)
> if blah is not blah:
> d.setdefault(blah, blah)
The redundancy is easily removed:
defaults = {blah: blah, blah: blah, blah: blah, blah: blah}
defaults.update(d) # clobber defaults with specified vals
d = defaults # swap in, assuming not aliased
# if aliased, then instead:
# d.clear()
# d.update(defaults)
if blah is not blah:
d.setdefault(blah, blah)
Cheers,
Chris
--
http://blog.rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Feature Request] dict.setdefault()
On Tue, Apr 12, 2011 at 8:41 AM, MRAB wrote: > I'm not sure that "setdefault" should take **kw args for this because > of its existing argument structure (key + optional value). > > A new method like "updatedefault" may be better, IMHO. It would act > like "update" except that it wouldn't overwrite existing values. Wouldn't x.updatedefault(y) be pretty much y.update(x) ? Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: [Feature Request] dict.setdefault()
On 11/04/2011 23:16, Westley Martínez wrote: On Mon, 2011-04-11 at 14:35 -0700, rantingrick wrote: setdefault should take **kw args in the case of needing to set multiple defaults at one time. I would even settle for an *arg list if i had to. Anything is better than... d.setdefault(blah, blah) d.setdefault(blah, blah) d.setdefault(blah, blah) d.setdefault(blah, blah) if blah is not blah: d.setdefault(blah, blah) ...nuff said. PS: And to counter the very *extemely* likely chance of some smart arse responses * YES, i know i could create my own setdefault method but that is not the point. * I know we are under the moratorium but someone had to mention it, --rr Go to bugs.python.org I'm not sure that "setdefault" should take **kw args for this because of its existing argument structure (key + optional value). A new method like "updatedefault" may be better, IMHO. It would act like "update" except that it wouldn't overwrite existing values. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Feature Request] dict.setdefault()
On Mon, 2011-04-11 at 14:35 -0700, rantingrick wrote: > setdefault should take **kw args in the case of needing to set > multiple defaults at one time. I would even settle for an *arg list if > i had to. Anything is better than... > > d.setdefault(blah, blah) > d.setdefault(blah, blah) > d.setdefault(blah, blah) > d.setdefault(blah, blah) > if blah is not blah: > d.setdefault(blah, blah) > > ...nuff said. > > PS: And to counter the very *extemely* likely chance of some smart > arse responses > * YES, i know i could create my own setdefault method but that is > not the point. > * I know we are under the moratorium but someone had to mention it, > > --rr Go to bugs.python.org -- http://mail.python.org/mailman/listinfo/python-list
[Feature Request] dict.setdefault()
setdefault should take **kw args in the case of needing to set multiple defaults at one time. I would even settle for an *arg list if i had to. Anything is better than... d.setdefault(blah, blah) d.setdefault(blah, blah) d.setdefault(blah, blah) d.setdefault(blah, blah) if blah is not blah: d.setdefault(blah, blah) ...nuff said. PS: And to counter the very *extemely* likely chance of some smart arse responses * YES, i know i could create my own setdefault method but that is not the point. * I know we are under the moratorium but someone had to mention it, --rr -- http://mail.python.org/mailman/listinfo/python-list
Re: feature request: string.contains('...')
On 9/24/2010 2:45 PM, Tim Chase wrote:
On 09/24/10 13:01, Ethan Furman wrote:
John Posner wrote:
Another "missing feature" candidate: sublist
>>> 'bc' in 'abcde'
True
>>> list('bc') in list('abcde')
False
I'm not aware of any idioms, but how about a simple function?
Foldable into a one-line version if one's sick enough to use it:
Looking at this a bit more, I can see why the *in* operator applies to
strings, but not to lists. Consider the ambiguity in this
"heterogeneous" list:
mylist = [0, 1, 2, 3, [a, b], 10, 11, 12, a, b, 13]
Should the expression *[a, b] in mylist* get a hit at offset 4, or at
slice [8:10]?
If you know that your lists will be homogeneous ("scalar" values only),
or if you're willing to program around the potential ambiguity, then
Ethan's function can easily be adapted into a __contains__() method of a
*list* subclass.
Tx,
John
--
http://mail.python.org/mailman/listinfo/python-list
Re: feature request: string.contains('...')
On 09/24/10 13:01, Ethan Furman wrote:
John Posner wrote:
Another "missing feature" candidate: sublist
>>> 'bc' in 'abcde'
True
>>> list('bc') in list('abcde')
False
I'm not aware of any idioms, but how about a simple function?
def listinlist(list1, list2):
"checks if list1 is in list2"
if not list1:
return True
if not list2:
return False
length = len(list1)
pos = 0
while True:
try:
pos = list2.index(list1[0], pos)
except ValueError:
return False
if list2[pos:pos+length] == list1:
return True
pos += 1
Which I suppose could be rewritten something like
def listinlist(l1, l2):
len1 = len(l1)
offsets_to_consider = 1 + len(l2) - len1
return any(
l1 == l2[i:i+len1]
for i in xrange(offsets_to_consider)
)
Foldable into a one-line version if one's sick enough to use it:
list_in_list = lambda l1, l2: any(l1 == l2[i:i+len(l1)] for i
in range(1 + len(l2) - len(l1)))
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
Re: feature request: string.contains('...')
John Posner wrote:
Another "missing feature" candidate: sublist
>>> 'bc' in 'abcde'
True
>>> list('bc') in list('abcde')
False
I'm not aware of any idioms, but how about a simple function?
def listinlist(list1, list2):
"checks if list1 is in list2"
if not list1:
return True
if not list2:
return False
length = len(list1)
pos = 0
while True:
try:
pos = list2.index(list1[0], pos)
except ValueError:
return False
if list2[pos:pos+length] == list1:
return True
pos += 1
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
Re: feature request: string.contains('...')
On 9/24/2010 4:21 AM, Peter Otten wrote:
If you are not interested in the position of the substr use the "in"
operator:
if substr in s:
print "found"
else:
print "not found"
Another "missing feature" candidate: sublist
>>> 'bc' in 'abcde'
True
>>> list('bc') in list('abcde')
False
A little Googling indicates that Haskell *does* have this feature: [1]
ghci> [2,6] `isInfixOf` [3,1,4,1,5,9,2,6,5,3,5,8,9,7,9]
True
I haven't located an equivalent Python idiom, though. I took a quick
look through numpy, but no luck. Can anyone help?
Tx,
John
[1] http://book.realworldhaskell.org/read/functional-programming.html
--
http://mail.python.org/mailman/listinfo/python-list
Re: feature request: string.contains('...')
On Freitag 24 September 2010, Wim Feijen wrote:
> would really like having a string.contains('...') function
> which returns either True or False. I know I can mimick this
> behaviour by saying string.find('...') != -1 , however, I
> find this harder to read.
>>> a = 'xy134'
>>> '13' in a
True
>>> '15' in a
False
>>>
--
Wolfgang
--
http://mail.python.org/mailman/listinfo/python-list
Re: feature request: string.contains('...')
Wim Feijen wrote:
> I was wondering, how to make a feature request?
You can post suggestions to improve python on the python-ideas mailing list
or make feature requests on the bugtracker at bugs.python.org
> I would really like having a string.contains('...') function which returns
> either True or False. I know I can mimick this behaviour by saying
> string.find('...') != -1 , however, I find this harder to read.
>
> string.contains('...') is easier to understand and more closely resembles
> natural language.
In modern python those functions provided by the string module that are also
available as methods should not be used anymore. Instead of
string.find(s, substr)
write
s.find(substr)
If you are not interested in the position of the substr use the "in"
operator:
if substr in s:
print "found"
else:
print "not found"
Peter
--
http://mail.python.org/mailman/listinfo/python-list
feature request: string.contains('...')
Hello,
I was wondering, how to make a feature request?
I would really like having a string.contains('...') function which returns
either True or False. I know I can mimick this behaviour by saying
string.find('...') != -1 , however, I find this harder to read.
string.contains('...') is easier to understand and more closely resembles
natural language.
Thanks for your help and best regards,
Wim Feijen
--
Wim Feijen
Algemeen directeur
w...@go2people.nl
06 3316
Go2People
Keizersgracht 8
1015 CN Amsterdam
020 7370378
www.go2people.nl
--
http://mail.python.org/mailman/listinfo/python-list
Re: feature request for a wget -r like implementation in python3
On Apr 17, 1:14 am, "Gabriel Genellina" wrote: > En Thu, 15 Apr 2010 16:37:37 -0300, gert escribió: > > > [a wget -r like implementation in python3] > > So I can make a recursive http download script > > What about calling wget itself? subprocess.call(['wget',...]) > The only dependency I would like is python3 -- http://mail.python.org/mailman/listinfo/python-list
Re: feature request for a wget -r like implementation in python3
On Apr 16, 3:41 am, alex23 wrote:
> On Apr 16, 5:37 am, gert wrote:
>
> > So I can make a recursive http download script
> > My goal is a one click instruction to install and launch my
> > projecthttp://code.google.com/p/appwsgi/
>
> Here's Guido's take on wget:
>
> import sys, urllib
> def reporthook(*a): print a
> for url in sys.argv[1:]:
> i = url.rfind('/')
> file = url[i+1:]
> print url, "->", file
> urllib.urlretrieve(url, file, reporthook)
>
> If you extend this, you can offer an easy-download-and-run python
> script that does the installation you want.
>
Guido is not talking about the same wget -r I think
I expected something like this
def hook(url):print(url)
def dir(url):
with urllib.request.urlopen(url) as f:
for u in f:
s=u.decode('latin1')
m=re.search('.*href="([^\.].*)"',s)
if m:
t=url+m.group(1)
if t[-1]=='/': dir(t)
else:
d=os.path.dirname(t[33:])
if d=='': d='./'
if not os.path.exists(d):
os.makedirs(os.path.dirname(t[33:]))
urllib.request.urlretrieve(t,t[33:],hook(t))
dir('http://appwsgi.googlecode.com/hg/')
How do I get rit of 33:
> But why duplicate existing effort? Why not pip[1]?
> 1:http://pypi.python.org/pypi/pip
pip is a chainsaw, I need a pocket knife
--
http://mail.python.org/mailman/listinfo/python-list
Re: feature request for a wget -r like implementation in python3
En Thu, 15 Apr 2010 16:37:37 -0300, gert escribió: [a wget -r like implementation in python3] So I can make a recursive http download script What about calling wget itself? subprocess.call(['wget',...]) -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: feature request for a wget -r like implementation in python3
On Apr 16, 5:37 am, gert wrote:
> So I can make a recursive http download script
> My goal is a one click instruction to install and launch my
> projecthttp://code.google.com/p/appwsgi/
Here's Guido's take on wget:
import sys, urllib
def reporthook(*a): print a
for url in sys.argv[1:]:
i = url.rfind('/')
file = url[i+1:]
print url, "->", file
urllib.urlretrieve(url, file, reporthook)
If you extend this, you can offer an easy-download-and-run python
script that does the installation you want.
But why duplicate existing effort? Why not pip[1]?
1: http://pypi.python.org/pypi/pip
--
http://mail.python.org/mailman/listinfo/python-list
feature request for a wget -r like implementation in python3
So I can make a recursive http download script My goal is a one click instruction to install and launch my project http://code.google.com/p/appwsgi/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
Brad Harms a écrit :
On Fri, 04 Dec 2009 18:05:03 +1100, Ben Finney wrote:
(snip)
2.) Attributes whose values are determined or assigned dynamically by
indirectly calling a function (like properties and instancemethods)
Yes, the term “property” seems to do what you want.
I wasn't asking what you call any object or any /kind/ of object. I was
asking for a term (noun?) that describes the WAY the object is accessed
as an attribute of an instance, with the connotation that the value of
the attribute would be calculated dynamically (by calling a function) at
the time the attribute was accessed.
Then you definitly want "computed attribute" - which is quite standard
OO terminology FWIW.
(snip - Ben, I think you shouldn't have tred to teach your grandmother
how to suck eggs )
Also note the fact that Foo.spam is an _instancemethod_ object and not
just a function, even though it was defined as "just a function" in the
class body. That's because function objects are descriptors as well; it
lets them produce unbound instancemethods. I'm not precisely sure how
this works,
class function(object):
def __get__(self, instance, cls):
if instance:
assert isinstance(instance, cls)
return boundmethod(instance, cls)
else
return unboundmethod(cls)
though. I think it only happens when the metaclass of a class
processes the functions in the class block.
Nope, this is totally unrelated.
class Foo(object):
def __init__(self, bar):
self.bar = 42
def baaz(obj, whatever):
print obj.bar, whatever
Foo.baaz = baaz
f= Foo()
f.baaz("is the answer")
3.) Attributes that are read from an object with regular .dot syntax,
but are actually attributes (in the sense of #1 above) of the __dict__
of the object's class.
This is a “class attribute” as distinct from an “instance attribute”.
I know it's called that, but I was talking more about the fact of it
being accessed through an instance of the class rather than
Except for descriptors, this doesn't make much difference difference.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
Ben Finney a écrit : Brad Harms writes: (snip) 2.) Attributes whose values are determined or assigned dynamically by indirectly calling a function (like properties and instancemethods) Yes, the term “property” seems to do what you want. The property type is just one possible application of the descriptor protocol which provides most of the support for computed attributes in Python, so it might be way too restrictive. The value of an instance method is *not* determined dynamically: It is, actually. The function type implements the protocol descriptor, with the __get__ method returning an instancemethod object. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
Brad Harms a écrit : On Tue, 2009-12-01 at 16:58 +0100, Bruno Desthuilliers wrote: The Music Guy a écrit : (snip) Lie Ryan, I think I see what you're saying about using __dict__ to add members No "members" in Python - only attributes. to a class, but it's not quite the same. __dict__ is only for attributes, NOT properties, methods, etc. which all come from the class of an object rather than the object's __dict__. properties and methods (well, functions actually) ARE attributes... of the class object. And you can of course access the obj.__class__.__dict__ Just for the record... When I say "member" I am using it as a general term that describes any value that can be accessed (get, set, del) through an object. These are what we call "attributes". If the object is referenced by a variable named `foo`, then by using `foo.name` or one of the XXXattr functions, one can access the member of `foo` called `name`. What's important to note, though, is that the term "member" does not make any assumption about how `foo.name` is implemented. > When I say "attribute," however, I am referring specifically to a member of an object where the member's name is a key in the object's __dict__, and the value is the one that is paired with that key. What if the class uses slots then ?-) Ok, just kidding. More seriously: these are named "instance attributes". Essentially, I just use "member" as a convenience term. I thought that was the convention among the community, but evidently it isn't as widely used as such as I thought. "members" is really C++ vocabulary. Anyway, it looks like the docs agree with you (http://docs.python.org/glossary.html#term-attribute), I'd put it the other way round - I have no responsabilities wrt/ the usual Pythonic vocabulary !-) so I'm not going to argue. However, for the purpose of clean communication, I'd still like to have terms that refer specifically to: 1.) "Regular" attributes, ie. those that are shortcuts to items in the directly associated object's __dict__, instance attributes 2.) Attributes whose values are determined or assigned dynamically by indirectly calling a function (like properties and instancemethods) computed attributes 3.) Attributes that are read from an object with regular .dot syntax, but are actually attributes (in the sense of #1 above) of the __dict__ of the object's class. class attributes. Now things are even a bit more complex since computed attributes are usually handled by objects implementing the descriptor protocol (instance of the function or property type or any other custom descriptor), which are themselves class attributes. So sometimes - depending on the context - you may have to make clear whether you're talking about the descriptor object itself or the attribute as seen by client code. HTH -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Thu, 03 Dec 2009 23:12:39 -0600, Brad Harms wrote: > On Tue, 2009-12-01 at 14:38 +, Steven D'Aprano wrote: [...] >> It's just special double-underscore methods like __init__ __add__ etc >> that have to be in the class rather than the instance. (To be precise, >> you can add such a method to the instance, but it won't be called >> automatically.) Likewise staticmethods and classmethods won't work >> correctly unless they are in the class. But ordinary methods work fine: >> the only tricky bit is creating them in the first place. >> >> >>> class K(object): >> ... pass >> ... >> >>> k = K() >> >>> import types >> >>> k.method = types.MethodType(lambda self: "I am %s" % self, k) >> >>> k.method() >> 'I am <__main__.K object at 0xb7cc7d4c>' > > ...I'm not sure I follow your logic. > > Yes, you can create an instancemethod out of a function and assign it to > an instance after (or during) its instantiation, which is what Python's > class/instance model provides automatically. However, to do so manually > in this manner completely disregards the fundamentals of object-oriented > programming, not to mention the basic guiding principles of nearly all > Python code in existence. It totally breaks inheritance and > polymorphism. Maybe I'm missing something, but I can't see how that line > of thought helps anything. I'm not recommending it as a standard technique instead of defining methods via the usual class statement. But it does work, and can be handy for the odd occasion where you want per-instance behaviour of some class. I'm not saying this is a common occurrence, but it does happen -- it's particularly handy if you have a standard behaviour which you want to override, e.g. monkey-patching specific instances. Instead of this: class K: marker = None def method(self): if self.marker: return "special" return "normal" k = K() k.marker = 1 you can do this: class K: def method(self): return "normal" k = K() k.method = type(k.method)(lambda self: "special", k) So although unusual, it is useful. As for breaking inheritance and polymorphism, not at all. Inheritance still works, and polymorphism is irrelevant: methods are, or aren't, polymorphic regardless of whether they are per instance or shared. Fundamentally, per-instance methods are nothing more than as per-instance attributes which happen to be callable. It is "magic methods" like __len__ and friends that break the usual rules of inheritance. The normal lookup chain for instance.name, whether name is a callable method or a non-callable attribute, is: instance class base class(es) but for magic methods, the chain skips the instance step. That's done as an optimization, and given how rare it is to have per-instance methods, that's quite reasonable. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Fri, 04 Dec 2009 09:00:42 +, Steven D'Aprano wrote: > Not all such attributes are actually found in instance.__dict__. ...I hadn't even considered __slots__ yet. Hm... > Or dynamic attributes returned by __getattr__ or __getattribute__. I'm looking for a generic term, because it's too cumbersome to say "properties or dynamic attributes using __getattr__ or __getattribute__" all the time. That will be my last message for a while...good night, c.p.l. -- Brad Harms -- http://alphaios.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Fri, 04 Dec 2009 18:05:03 +1100, Ben Finney wrote: > Brad Harms writes: > >> Anyway, it looks like the docs agree with you >> (http://docs.python.org/glossary.html#term-attribute), so I'm not going >> to argue. > > That's good, because the terms are quite well established in Python > terminology. I'm just saying, if the official documentation defines the term "attribute" thusly, it would be silly of me to continue using my own made- up term that means pretty much the same thing. > >> However, for the purpose of clean communication, I'd still like to have >> terms that refer specifically to: >> >> 1.) "Regular" attributes, ie. those that are shortcuts to items in the >> directly associated object's __dict__, > > I don't know what you mean by “shortcuts to items”. The names are looked > up in dictionaries; where do shortcuts play a part? > > Try “instance attribute”, as distinct from “class attribute”. > >> 2.) Attributes whose values are determined or assigned dynamically by >> indirectly calling a function (like properties and instancemethods) > > Yes, the term “property” seems to do what you want. I wasn't asking what you call any object or any /kind/ of object. I was asking for a term (noun?) that describes the WAY the object is accessed as an attribute of an instance, with the connotation that the value of the attribute would be calculated dynamically (by calling a function) at the time the attribute was accessed. Note that the value does not have to exist in ANY __dict__ anywhere, it could, for example, be calculated by object.__getattribute__. Example: >>> obj.attr Without knowing what "obj" is or what "attr" is as it pertains to obj, but knowing that "attr" does not actually a key in obj.__dict_,_ and that its value has to be determined by some other means, what do you call the thing on the code line above? That is what I'm trying to find out. (HINT: Don't think about how the Python interpreter parses it or how the value is eventually determined. That's not relevant. Just understand that the value does not come directly from obj.__dict__.) By the way, a "property" is an object of type __builtin__.property. A property with a reference in an attribute of a class /does/ call a function when you try to access that property as an attribute of the class's instances. However, properties are not the only objects that have this behavior, so calling objects that behave in this way is ambiguous. I think the actual, general term for such an object is "data descriptor," or just "descriptor." (http://docs.python.org/glossary.html#term- descriptor) > > The value of an instance method is *not* determined dynamically: its > value is a function, and that value is no more dynamic than any other > attribute of the instance. That is incorrect. Indirectly accessing an instancemethod of a class through an instance of that class will trigger the descriptor behavior of the instancemethod type. This produces a new object, another instancemethod, that is bound to the instance through which it was accessed. It's a mouthful to say, but it is sufficiently accurate. Heck, just look at this: >>> class Foo(object): ... def spam(self): pass ... >>> foo = Foo() >>> foo.spam > >>> Foo.spam >>> foo.spam is Foo.spam False >>> foo.spam == Foo.spam False >>> Foo.spam.__get__(foo, Foo) > >>> Foo.__dict__["spam"].__get__(foo, Foo) > >>> Foo.__dict__["spam"].__get__(foo, Foo) is foo.spam False >>> Foo.__dict__["spam"].__get__(foo, Foo) == foo.spam True Also note the fact that Foo.spam is an _instancemethod_ object and not just a function, even though it was defined as "just a function" in the class body. That's because function objects are descriptors as well; it lets them produce unbound instancemethods. I'm not precisely sure how this works, though. I think it only happens when the metaclass of a class processes the functions in the class block. > >> 3.) Attributes that are read from an object with regular .dot syntax, >> but are actually attributes (in the sense of #1 above) of the __dict__ >> of the object's class. > > This is a “class attribute” as distinct from an “instance attribute”. > I know it's called that, but I was talking more about the fact of it being accessed through an instance of the class rather than > The distinction isn't often worth knowing, though, so you'll probably > still have to explain it when you use it. I beg to differ. For one thing, it affects descriptors. Anyway, these metadiscussions are starting to give me headaches. Let's talk about something more interesting... PS. I'm truly sorry once again for using email addresses and names inconsistently. I really am trying to solve the problem. I'm going to try accessing the list via comp.lang.python and Pan (newsreader for Gnome) for a while. Hopefully it will help. -- Brad Harms -- http://alphaios.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Fri, 04 Dec 2009 18:05:03 +1100, Ben Finney wrote: > Brad Harms writes: ... >> 1.) "Regular" attributes, ie. those that are shortcuts to items in the >> directly associated object's __dict__, > > I don't know what you mean by “shortcuts to items”. The names are looked > up in dictionaries; where do shortcuts play a part? > > Try “instance attribute”, as distinct from “class attribute”. Not all such attributes are actually found in instance.__dict__. >>> class Example(object): ... __slots__ = 'spam' ... >>> x = Example() >>> y = Example() >>> x.spam = 23 >>> >>> x.__dict__['spam'] Traceback (most recent call last): File "", line 1, in AttributeError: 'Example' object has no attribute '__dict__' >>> x.spam 23 >>> y.spam Traceback (most recent call last): File "", line 1, in AttributeError: spam So it is possible to have per-instance attributes that don't live inside the instance __dict__. >> 2.) Attributes whose values are determined or assigned dynamically by >> indirectly calling a function (like properties and instancemethods) > > Yes, the term “property” seems to do what you want. Or dynamic attributes returned by __getattr__ or __getattribute__. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
Brad Harms writes: > Anyway, it looks like the docs agree with you > (http://docs.python.org/glossary.html#term-attribute), so I'm not > going to argue. That's good, because the terms are quite well established in Python terminology. > However, for the purpose of clean communication, I'd still like to > have terms that refer specifically to: > > 1.) "Regular" attributes, ie. those that are shortcuts to items in the > directly associated object's __dict__, I don't know what you mean by “shortcuts to items”. The names are looked up in dictionaries; where do shortcuts play a part? Try “instance attribute”, as distinct from “class attribute”. > 2.) Attributes whose values are determined or assigned dynamically by > indirectly calling a function (like properties and instancemethods) Yes, the term “property” seems to do what you want. The value of an instance method is *not* determined dynamically: its value is a function, and that value is no more dynamic than any other attribute of the instance. > 3.) Attributes that are read from an object with regular .dot syntax, > but are actually attributes (in the sense of #1 above) of the __dict__ > of the object's class. This is a “class attribute” as distinct from an “instance attribute”. The distinction isn't often worth knowing, though, so you'll probably still have to explain it when you use it. -- \ “‘Did you sleep well?’ ‘No, I made a couple of mistakes.’” | `\—Steven Wright | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Tue, 2009-12-01 at 14:38 +, Steven D'Aprano wrote: > On Mon, 30 Nov 2009 18:55:46 -0800, The Music Guy wrote: > > > Lie Ryan, I think I see what you're saying about using __dict__ to add > > members to a class, but it's not quite the same. __dict__ is only for > > attributes, NOT properties, methods, etc. which all come from the class > > of an object rather than the object's __dict__. > > Almost but not quite. > > It's just special double-underscore methods like __init__ __add__ etc > that have to be in the class rather than the instance. (To be precise, > you can add such a method to the instance, but it won't be called > automatically.) Likewise staticmethods and classmethods won't work > correctly unless they are in the class. But ordinary methods work fine: > the only tricky bit is creating them in the first place. > > >>> class K(object): > ... pass > ... > >>> k = K() > >>> import types > >>> k.method = types.MethodType(lambda self: "I am %s" % self, k) > >>> k.method() > 'I am <__main__.K object at 0xb7cc7d4c>' > Yes, you can create an instancemethod out of a function and assign it to > an instance after (or during) its instantiation, which is what Python's > class/instance model provides automatically. [...] ...Hmm, let me clarify that statement as I think it could be misunderstood: When I say "which is what [Python] does automatically", I mean that Python automatically creates a BOUND instancemethod object from the UNBOUND instancemethod whenever you try to access the unbound instancemethod as an attribute of the instance _at the moment that you try to access it_. I did NOT mean to imply that the bound instancemethod objects are created and assigned to the instance at the time of its instantiation (because Python obviously doesn't do that). Sorry for the rapid-fire posting. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Tue, 2009-12-01 at 16:58 +0100, Bruno Desthuilliers wrote: > The Music Guy a écrit : > (snip) > > Lie Ryan, I think I see what you're saying about using __dict__ to add > > members > > No "members" in Python - only attributes. > > to a class, but it's not quite the same. __dict__ is only for > > attributes, NOT properties, methods, etc. which all come from the > > class of an object rather than the object's __dict__. > > properties and methods (well, functions actually) ARE attributes... of > the class object. And you can of course access the obj.__class__.__dict__ > > Just for the record... When I say "member" I am using it as a general term that describes any value that can be accessed (get, set, del) through an object. If the object is referenced by a variable named `foo`, then by using `foo.name` or one of the XXXattr functions, one can access the member of `foo` called `name`. What's important to note, though, is that the term "member" does not make any assumption about how `foo.name` is implemented. When I say "attribute," however, I am referring specifically to a member of an object where the member's name is a key in the object's __dict__, and the value is the one that is paired with that key. Example: class Foo(object): def __init__(self): self._x = 5 @property def x(self): return self._x @x.setter def x(self,val): self._x = val def frob(self): print "I've been frobbed!" foo = Foo() foo._x # Each of these is both a member and an attribute. foo.y = 6 foo.x # Each of these is a member, but neither is an attribute. foo.frob To be perfectly precise, foo.y is only an attribute AFTER the assignment has been performed. Before 6 is assigned, foo.y is only a "member" and not an "attribute" because "y" does not yet exist as a key in foo's __dict__. Essentially, I just use "member" as a convenience term. I thought that was the convention among the community, but evidently it isn't as widely used as such as I thought. Anyway, it looks like the docs agree with you (http://docs.python.org/glossary.html#term-attribute), so I'm not going to argue. However, for the purpose of clean communication, I'd still like to have terms that refer specifically to: 1.) "Regular" attributes, ie. those that are shortcuts to items in the directly associated object's __dict__, 2.) Attributes whose values are determined or assigned dynamically by indirectly calling a function (like properties and instancemethods) 3.) Attributes that are read from an object with regular .dot syntax, but are actually attributes (in the sense of #1 above) of the __dict__ of the object's class. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Tue, 2009-12-01 at 14:38 +, Steven D'Aprano wrote: > On Mon, 30 Nov 2009 18:55:46 -0800, The Music Guy wrote: > > > Lie Ryan, I think I see what you're saying about using __dict__ to add > > members to a class, but it's not quite the same. __dict__ is only for > > attributes, NOT properties, methods, etc. which all come from the class > > of an object rather than the object's __dict__. > > Almost but not quite. > > It's just special double-underscore methods like __init__ __add__ etc > that have to be in the class rather than the instance. (To be precise, > you can add such a method to the instance, but it won't be called > automatically.) Likewise staticmethods and classmethods won't work > correctly unless they are in the class. But ordinary methods work fine: > the only tricky bit is creating them in the first place. > > >>> class K(object): > ... pass > ... > >>> k = K() > >>> import types > >>> k.method = types.MethodType(lambda self: "I am %s" % self, k) > >>> k.method() > 'I am <__main__.K object at 0xb7cc7d4c>' ...I'm not sure I follow your logic. Yes, you can create an instancemethod out of a function and assign it to an instance after (or during) its instantiation, which is what Python's class/instance model provides automatically. However, to do so manually in this manner completely disregards the fundamentals of object-oriented programming, not to mention the basic guiding principles of nearly all Python code in existence. It totally breaks inheritance and polymorphism. Maybe I'm missing something, but I can't see how that line of thought helps anything. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Dec 1, 10:21 am, Raymond Hettinger wrote: > [Gregory Ewing] > > > >>I just posted to my blog about a feature that I'd like to see added to > > >>Python. > > > >>http://alphaios.blogspot.com/2009/11/python-string-inferred-names-wor... > > > I don't think getattr and setattr are used anywhere near > > frequently enough to justify special syntax. > > Perhaps that would change if we had the proposed syntax. > I would expect that powerful and expressive idioms would emerge. I doubt it. Such expressive idioms haven't emerged in languages that do this (e.g., Javascript, Matlab) as far as I can tell. The objects end up being used as nothing more than a poor replacement for dictionaries. > > (A frequent question asked by newcomers from certain > > other kinds of languages is something like "How do I > > assign to a variable whose name is in another variable?" > > The answer is almost always "Don't do that, use a > > dictionary.") > > The proposed syntax works better with class namespaces > which automatically provide inheritance logic and > method binding. Dictionaries don't provide equivalent > support. The right approach to having "inheritance-like behavior" AND "typically don't know the name of the thing being accessed at compile time" in the same object--and I doubt that would be widely useful--is to add an option to dictionaries to support inheritance. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
[Gregory Ewing] > >>I just posted to my blog about a feature that I'd like to see added to > >>Python. > > >>http://alphaios.blogspot.com/2009/11/python-string-inferred-names-wor... > > I don't think getattr and setattr are used anywhere near > frequently enough to justify special syntax. Perhaps that would change if we had the proposed syntax. I would expect that powerful and expressive idioms would emerge. > (A frequent question asked by newcomers from certain > other kinds of languages is something like "How do I > assign to a variable whose name is in another variable?" > The answer is almost always "Don't do that, use a > dictionary.") The proposed syntax works better with class namespaces which automatically provide inheritance logic and method binding. Dictionaries don't provide equivalent support. Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
The Music Guy a écrit : (snip) Lie Ryan, I think I see what you're saying about using __dict__ to add members No "members" in Python - only attributes. to a class, but it's not quite the same. __dict__ is only for attributes, NOT properties, methods, etc. which all come from the class of an object rather than the object's __dict__. properties and methods (well, functions actually) ARE attributes... of the class object. And you can of course access the obj.__class__.__dict__ Just for the record... -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Mon, 30 Nov 2009 18:55:46 -0800, The Music Guy wrote: > Lie Ryan, I think I see what you're saying about using __dict__ to add > members to a class, but it's not quite the same. __dict__ is only for > attributes, NOT properties, methods, etc. which all come from the class > of an object rather than the object's __dict__. Almost but not quite. It's just special double-underscore methods like __init__ __add__ etc that have to be in the class rather than the instance. (To be precise, you can add such a method to the instance, but it won't be called automatically.) Likewise staticmethods and classmethods won't work correctly unless they are in the class. But ordinary methods work fine: the only tricky bit is creating them in the first place. >>> class K(object): ... pass ... >>> k = K() >>> import types >>> k.method = types.MethodType(lambda self: "I am %s" % self, k) >>> k.method() 'I am <__main__.K object at 0xb7cc7d4c>' -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
> Brad Harms FearsomeDragonfly at gmail.com > Mon Nov 30 05:04:37 CET 2009 > > That was a relatively simple example; classes as simple as the ones > generated by the It is more likely that the class generation could would > appear in a metaclass's class constructor or decorator function, and there > would be more than just the three attributes given. Bwa ha ha! Well, I managed to screw up that paragraph pretty badly. (I code better than I write, honest.) Let me try again: That was a relatively simple example; classes as simple as the ones generated by the factory function example given are not needed very often. It is more likely that the class generation would appear in a metaclass's class constructor or decorator function, and there would be more than just the three attributes. That way it could be possible to ADD those properties and methods to a class in the process of being built rather than make a class with just those attributes. Lie Ryan, I think I see what you're saying about using __dict__ to add members to a class, but it's not quite the same. __dict__ is only for attributes, NOT properties, methods, etc. which all come from the class of an object rather than the object's __dict__. Adding things to __dict__ would only work halfway; it wouldn't be very extensible. That's (one of the reasons) why the members have to be accessed as attributes rather than dict items. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
Brad Harms wrote: Well, yes, the names would have to be determined at run time. That's what getattr and setattr do, except that that do it in the context of an object rather than the local scope. However, I was under the impression that python's mechanism for looking up local names was the same as the mechanism used to look up attributes because names and attributes seem to function pretty much the same way. This I assumed because of the functionality of the locals() and globals() functions, which seem to act like the __dict__ attribute on objects except that the work on the current scope. The definition of locals() allows it to just be a dict *copy* of the local namespace, rather than the local namespace itself. Within functions, (at least for CPython, and probably for other implementations), locals() is just a copy, and changes to locals() are *not* propagated back to the local namespace. Within functions, local name 'lookup' has nothing to do with dict lookup. (It is more like list indexing.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On 12/1/2009 3:35 AM, Bruno Desthuilliers wrote: Lie Ryan a écrit : On 11/28/2009 3:08 PM, The Music Guy wrote: (snip the part about the proposed feature - which I don't like but that's not the point) My projects rely on a lot of metaclassing for the automatic generation of properties and methods, which saves tremendous amounts of coding. If you use it a lot, it is likely 1) you have abused class syntax for what should have been a dict or 2) what you need is to override __getattr__/__getattribute__ and __setattr__ I have to totally disagree here. The way the OP uses metaprogramming is a really common and handy solution in lots of frameworks, and drastically reduces the need for boilerplate (and the potential for bugs). It's *WAY* cleaner (readability, introspection, doc etc) and far less error-prone than going the __getattr(ibute)__ / __setattr__, and also way more efficient (from execution time POV). I won't argue with the usefulness of metaclass, I agree that metaclass is the cleanest way to implement certain things; but the main point is the OP's use of getattr/setattr while he got full control of the namespace dictionary. Using __getattr__ and __setattr__ to emulate attributes (usually descriptors) that can be built at class creation time is IMHO what should be labeled as an "abuse" (at best). -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
Lie Ryan a écrit : On 11/28/2009 3:08 PM, The Music Guy wrote: (snip the part about the proposed feature - which I don't like but that's not the point) My projects rely on a lot of metaclassing for the automatic generation of properties and methods, which saves tremendous amounts of coding. If you use it a lot, it is likely 1) you have abused class syntax for what should have been a dict or 2) what you need is to override __getattr__/__getattribute__ and __setattr__ I have to totally disagree here. The way the OP uses metaprogramming is a really common and handy solution in lots of frameworks, and drastically reduces the need for boilerplate (and the potential for bugs). It's *WAY* cleaner (readability, introspection, doc etc) and far less error-prone than going the __getattr(ibute)__ / __setattr__, and also way more efficient (from execution time POV). Using __getattr__ and __setattr__ to emulate attributes (usually descriptors) that can be built at class creation time is IMHO what should be labeled as an "abuse" (at best). -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
P.S., not trying to start a flame war. It's just that I can't stand to keep silent on the matter any longer. -- Brad Harms -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
Cameron Simpson writes: > The Zen promotes the guideline that there should be only one (obvious) > way to do most things and that's a surprisingly effective design rule. It's also important to realise that the Zen places the “preferably only one” in a parenthetical, and note that “preferably” qualifier. That is, it's: There should be one obvious way to do it. without that parenthetical. I think that “obvious” is the important part there, and seems to be to be the design principle that (far more than “only one”) is guiding in Python's development. -- \ “Too many pieces of music finish too long after the end.” —Igor | `\ Stravinskey | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
Lie Ryan a écrit : (snip) > setattr, getattr, and delattr are already sugar for accessing instance.__dict__. They are actually much more than that - else descriptors and inheritance wouldn't work. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Sun, Nov 29, 2009 at 11:01 PM, Brad Harms wrote: > > May the Penguin in the sky bless your every subroutine, > Um...feel free to ignore that. >_> -- Brad Harms -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Sun, Nov 29, 2009 at 9:59 PM, Carl Banks wrote: > Another thing that can be determined through common sense is that if > you have object that you are calling getattr and setattr on so much > that you think you need special syntax, you should have been using a > dict. > (Re-send; original was sent to the wrong address. I--I mean, Gmail--sent it to the wrong address by mistake. :P ) While you were writing this and your previous reply I was working on a response that kind of covers what you were talking about, but I'm going to say something anyway. Well, yes, the names would have to be determined at run time. That's what getattr and setattr do, except that that do it in the context of an object rather than the local scope. However, I was under the impression that python's mechanism for looking up local names was the same as the mechanism used to look up attributes because names and attributes seem to function pretty much the same way. This I assumed because of the functionality of the locals() and globals() functions, which seem to act like the __dict__ attribute on objects except that the work on the current scope. Also, there is the __builtins__ module, which actually _is_ an object, but its names can be accessed in the same way as locals and globals. I had considered the possibility of a peformance hit, however I didn't anticipate that it would be all that much. Not that it matters, but how much are we talking? 10% ? 50% ? In any case, I'm not really an expert on Python's internal constructions, but because of this discussion I'm considering taking some time to learn them. Python is unique compared to several other languages in that it makes a distinction between "items" and "attributes". Some languages, like JavaScript and Lua, do not make this distinction. They leave it to the programmer to access members of an object either as an item or as an attribute. I don't think there is necessarily anything wrong with this, nor do I think there is anything wrong with Python's separation. That said, just because you can use the proposed syntax to use an object in the same way as a dict does not mean that it works the other way around. I'm not talking about the allowance of any specific object to have any number of pairings between arbitrary keys and values. That's what dicts are for, and that's what indexing syntax implies. Rather, I'm talking about specific, concrete variables which objects are expected (though not technically required) to have bound to them according to how the object is intended to be used. (That's probably not the best definition of an attribute, but it's the best I can think of ATM.) I'm not trying to discard Python's distinction between items and attributes, but I don't want to be limited by it due to mere syntactical constraints, either. May the Penguin in the sky bless your every subroutine, Brad Harms -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Sun, Nov 29, 2009 at 7:49 PM, Lie Ryan wrote:
> On 11/29/2009 12:22 PM, The Music Guy wrote:
>
>> When I first started seeing @ show up in Python code, I said "what the
>> heck is that? It looks so weird and _ugly_.I would never try to mess
>> with that." But I started seeing it more and more, so I asked #python
>> what it was. They told me about decorators, so I looked it up in the
>> docs, and I thought the idea was interesting. It took me a while to
>> figure out exactly how they worked--and judging from messages I've
>> seen in #python a number of people have the same trouble understanding
>> them.
>>
>
> And we don't want a second flood of users asking about foo.$bar.
>
>
> My point is that any particular syntax would look ugly to you only
>> because you haven't seen it in use enough, and haven't used it enough
>> yourself.
>>
>
> You're absolutely right, and I have *never needed* to use the plain
> getattr/setattr/delattr enough to even bother considering a syntax that
> already looks ugly at first sight. For @decorators, everyone used it *often
> enough* BEFORE it turned into a syntax that the ugly syntax is justified and
> become "acceptable". If you can find a syntax that doesn't look ugly at
> first sight +0, fine by me; otherwise -1, I don't want to be forced to read
> an ugly syntax for a feature that I don't use often enough. It's not just
> the syntax, the necessity+syntax don't add up well.
>
>
> > But of course you haven't--it's not currently a valid
>
>> syntax. However, the ugliness would seem to go away after the syntax
>> had been in use for a while. And again, the EXACT syntax of the
>> feature can be adjusted until its "just right".
>>
>
> In so far, your definition of adjusting only means something around
> "[a-zA-Z0-9_]+\.[^a-zA-Z0-9_][<{(\[]?[a-zA-Z0-9_]+[>})\]]?"
> that class of syntax is ugly; some are more acceptable (e.g. obj.[arg]) the
> old thread have spawned better alternatives than that class of syntax.
>
> As for my specific use case, it's somewhat difficult to explain.
>>
>
> You know that:
> If the implementation is hard to explain it's a bad idea.
> -- Zen of Python --
>
> right?
>
>
> > The
>
>> general idea was to isolate a pattern that I spotted repeated in
>> several unrelated parts of my project. The pattern manifested itself
>> as a set of 4-5 methods and/or properties on a class whose objects
>> were designed to work in conjunction with other objects that fit a
>> particular behavior. These other objects had methods and properties
>> that were designed to interact with the first type of object in a
>> similar but--how should I say--"inverted" fashion.
>>
>
> Do you mean something like this?
>
> class A(object):
>@property
>def the_b(self):
>return self._b
>@the_b
>def the_b(self, new_b):
>self._b = new_b
>self._b._a = self
>
> class B(object):
>@property
>def the_a(self):
>return self._a
>@the_a
>def the_a(self, new_a):
>self._a = new_a
>self._a._b = self
>
> am I getting you right? If not, please elaborate and give an example of
> what you actually meant.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
I understand that in all likelyhood this feature won't be added to Python
anytime soon, if at all. But I'd like to continue this discussion anyway;
it's been enlightening for me. Even though I don't agree with the views of
some of the people who've replied, I like the insight. And anyway, I think
that if the syntax were already present, people would feel a lot more
positively about it; it's the idea of adding it in so late in the game that
people seem to have a problem with for the most part.
It doesn't seem like anybody besides inhahe has actually realized that my
proposition is actually different than PEP 363 in a subtle but crucial way.
It's not _literally_ a shorthand for accessing the *attr functions; that's
just the way I originally assumed it would be used most often. However, I
have since realized that the syntax is more powerful than I originally
thought: ANYWHERE that a name appeared--this includes function names, class
names, function parameters, possibly even module names--could be replaced by
an expression that would be evaluated to the name. That makes the use of any
kind of brackets, except maybe , bad options, as it would
conflict with [lists,] {dicts,} (tuples,) or generic parenthesized
(expressions). There must be a unique indicator of some kind, something that
isn't already in use by the interpreter. That way there is no possible way
that it could get confused with another syntactical construct.
So you could do something like this:
def class_factory(this, that)
get_that = "get_"+that
set_that = "set_"+that
_that = "_" + that
class $this (object):
def __init__(self, $that = None):
self.$_that = $that
def $get_that (self):
return self.$_t
Re: Feature request: String-inferred names
On Nov 28, 3:38 am, The Music Guy wrote: > On Nov 28, 3:07 am, Lie Ryan wrote: > > If you use it a lot, it is likely 1) you have abused class syntax for > > what should have been a dict or 2) what you need is to override > > __getattr__/__getattribute__ and __setattr__ > > Oh boy...here we go. :| > > Please listen. In all the time I've spent in the coding community > (that's at least 7 years) and especially since I started paying > attention to the Python community (2 years), I have noticed a trend: > When one coder does something that another cannot understand, > frequently the other will assume the former is not only doing things > wrong, but is doing them _blatantly_ wrong. I have caught myself > making that very assumption many times in the past, and I've tried > hard to build up an immunity against the impulse to make that > assumption. At this point, I don't even believe in such a thing as a > universal "wrong way" and a "right way" to code that applies to every > circumstance. The way to solve a problem depends on the problem. When > it comes to coding, there is not an absolute "right" way or "wrong" > way--unless we're talking about, say, stealing closed source code > without permission, or deliberately coding in a way that will cause > problems for the end user (like causing memory clogs or buffer > overflows and whatnot). > > All of this can be determined through common sense. Another thing that can be determined through common sense is that if you have object that you are calling getattr and setattr on so much that you think you need special syntax, you should have been using a dict. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Nov 26, 3:43 pm, The Music Guy wrote:
> That aside, I still feel that a new syntax would be a better solution
> than a new class. And, anyway, what I'm proposing isn't *quite* the
> same as what Ben North proposed. Ben's idea was *strictly* to create
> shorthand syntax to the getattr/setattr/delattr in the context of
> specific objects. What I'm suggesting could be more accurately
> described as a namespace-neutral transformation of the value of an
> expression into a name. So if "bar" is the value of foo, then when the
> interpreter sees $foo, it reads bar.
This transformation isn't possible in Python. Python has seperate
compile and run times, and the value of a variable (like foo) isn't
known at compile time, but it would have to be known at compile time
for the interpreter to "see" the value of that variable ("bar" in this
example).
Therefore, to get the effect you want, the evaluation of foo would
have to be delayed until run time. The interpreter would "see" $foo,
and explicitly change it to bar. But that leads to another problem.
Local variables (in CPython at least) are converted to index lookups
during the compile phase, for efficiency reasons. Python doesn't use
the name of a the local variable at run time at all, and you can't
dynamically create local variables. Thus, to use your syntax proposal
with local variables you would have to accept two concessions:
1. You could not use $foo to dynamically create a new local variable;
foo would have to evaluate to the name of a local variable that
already exists.
2. You would take a significant performance hit.
Furthermore, this would introduce a bad analogical inconsistency into
the language. If you can write foo.$bar=1 to create a new attribute,
you'd expect to be able to write $bar=1 to create a new local
variable, but you can't.
These issues are significant, and given that a proposal for just
computed attributes that didn't have these issues was already
rejected, I would say your proposal would have absolutely no chance,
even if there hadn't been a moratorium on new syntax.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On 11/29/2009 12:22 PM, The Music Guy wrote:
When I first started seeing @ show up in Python code, I said "what the
heck is that? It looks so weird and _ugly_.I would never try to mess
with that." But I started seeing it more and more, so I asked #python
what it was. They told me about decorators, so I looked it up in the
docs, and I thought the idea was interesting. It took me a while to
figure out exactly how they worked--and judging from messages I've
seen in #python a number of people have the same trouble understanding
them.
And we don't want a second flood of users asking about foo.$bar.
My point is that any particular syntax would look ugly to you only
because you haven't seen it in use enough, and haven't used it enough
yourself.
You're absolutely right, and I have *never needed* to use the plain
getattr/setattr/delattr enough to even bother considering a syntax that
already looks ugly at first sight. For @decorators, everyone used it
*often enough* BEFORE it turned into a syntax that the ugly syntax is
justified and become "acceptable". If you can find a syntax that doesn't
look ugly at first sight +0, fine by me; otherwise -1, I don't want to
be forced to read an ugly syntax for a feature that I don't use often
enough. It's not just the syntax, the necessity+syntax don't add up well.
> But of course you haven't--it's not currently a valid
syntax. However, the ugliness would seem to go away after the syntax
had been in use for a while. And again, the EXACT syntax of the
feature can be adjusted until its "just right".
In so far, your definition of adjusting only means something around
"[a-zA-Z0-9_]+\.[^a-zA-Z0-9_][<{(\[]?[a-zA-Z0-9_]+[>})\]]?"
that class of syntax is ugly; some are more acceptable (e.g. obj.[arg])
the old thread have spawned better alternatives than that class of syntax.
As for my specific use case, it's somewhat difficult to explain.
You know that:
If the implementation is hard to explain it's a bad idea.
-- Zen of Python --
right?
> The
general idea was to isolate a pattern that I spotted repeated in
several unrelated parts of my project. The pattern manifested itself
as a set of 4-5 methods and/or properties on a class whose objects
were designed to work in conjunction with other objects that fit a
particular behavior. These other objects had methods and properties
that were designed to interact with the first type of object in a
similar but--how should I say--"inverted" fashion.
Do you mean something like this?
class A(object):
@property
def the_b(self):
return self._b
@the_b
def the_b(self, new_b):
self._b = new_b
self._b._a = self
class B(object):
@property
def the_a(self):
return self._a
@the_a
def the_a(self, new_a):
self._a = new_a
self._a._b = self
am I getting you right? If not, please elaborate and give an example of
what you actually meant.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
The Music Guy wrote: When I first started seeing @ show up in Python code, I said "what the heck is that? For future reference, PySymbols.html at http://code.google.com/p/xploro/downloads/list answers all such symbol questions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Sun, Nov 29, 2009 at 6:58 AM, inhahe wrote: > Did you say you were using gmail to post? I think mailing lists tend to > have issues with gmail because it puts html in the message or something like > that. Btw I recently set up this mailing list to send me a message back > when I successfully posted something. oddly enough, i only remember getting > one such message, so maybe none of my other messages got through. :P > i think there's a way to disable html when sending a gmail message, but > don't quote me on that. I wasn't aware it was possible to Enable html but apparently it is. Let me know if you see any html in this post. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Sun, Nov 29, 2009 at 5:15 AM, The Music Guy wrote: > Okay, I'm having a really hard time telling which messages are getting > on to the list and which ones aren't. Some of the messages I send show > up in the comp.lang.python mirror in Google Groups, and some aren't. > Others show up on the Groups mirror, but don't show up in Gmail, or > show up in a different order. It seems the only way I can guarantee > anything showing up on Groups is to post on Groups, but that makes it > difficult because I can't see the messages in the thread that only > appear in my inbox. Is there a quick fix for this, because it's > getting pretty aggravating trying to figure out who heard what. I > don't like mailing lists. :P > -- > http://mail.python.org/mailman/listinfo/python-list > Did you say you were using gmail to post? I think mailing lists tend to have issues with gmail because it puts html in the message or something like that. Btw I recently set up this mailing list to send me a message back when I successfully posted something. oddly enough, i only remember getting one such message, so maybe none of my other messages got through. :P i think there's a way to disable html when sending a gmail message, but don't quote me on that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
Okay, I'm having a really hard time telling which messages are getting on to the list and which ones aren't. Some of the messages I send show up in the comp.lang.python mirror in Google Groups, and some aren't. Others show up on the Groups mirror, but don't show up in Gmail, or show up in a different order. It seems the only way I can guarantee anything showing up on Groups is to post on Groups, but that makes it difficult because I can't see the messages in the thread that only appear in my inbox. Is there a quick fix for this, because it's getting pretty aggravating trying to figure out who heard what. I don't like mailing lists. :P -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
>
>
On Sat, Nov 28, 2009 at 9:39 PM, Steven D'Aprano <
st...@remove-this-cybersource.com.au> wrote:
>
> Removing code redundancy is all very well, but beware of turning into an
>
>> architecture astronaut:
>
>>
> http://www.joelonsoftware.com/articles/fog18.html
>
>>
> There is such a thing as over-generalisation -- if you're having to
>
>> struggle to get the abstract code working abstractly enough, you're
> probably over-generalising.
>
That's an interesting article, but I don't really understand what the
author's point is. It's okay to generalize, but don't make a big fuss about
it? It's okay, but don't do it anyway? I honestly can't tell. He seems to
be criticizing a lot of good products (like Java), not because they are
generalizations exactly, but because there is too much hype surrounding
them.
>
Anyway, I'm not generalizing for the sake of generalizing. I'm generalizing
because it appears to be a logical solution to a _specific_ problem, namely
the fact that nearly identical class definition code was being repeated in
several classes with only a few minor details difference. If it were a
regular processing problem, a function would be created to do the repeated
work, but since the redundancy occurs before any processing has occurred in
the traditional sense, the redundancies have to be collected in a
_different_ way.
>
Now that I think about it, though, Python 2.6 and above support decorators
on classes (an example of generalization, by the way). The metaclass code
could be moved almost verbatim to a decorator function which could then be
used on classes that needed it. It would still be a mess, though.
>
hm...actually, inhahe's code made me realize that the metaclass could be
cleaned up even more than I originally thought by the proposed syntax
because it could be used for naming functions as well as attributes. ;^_^
>
>
> > The code worked very
>
>> > well, and allowed for the pattern to be added to any class by using a
>
>> > single, short line of code (something along the lines of __class_attr =
>
>> > { key: value }). Not only that, but the metaclass code itself was
>
>> > comprised of less than a screenful of code after docstrings and comments
>
>> > had been removed. However, the code was (and still is) very difficult to
>
>> > follow simply because of the way getters and setters had to be used to
>
>> > generate the methods and properties.
>
>>
> That's good evidence that you've over-generalised.
>
I don't follow. Could you please be more specific? (no pun intended)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
i like this idea (i posted some thoughts on it in the blog, but it's not
approved yet as of this writing)
in short, i suggested extending the idea to make it more a) generalized, b)
simple, c) intuitive, and d) flexible.
so instead of just using $ for attributes, you could use it anywhere you
define or reference a name.
as in..
class $a: pass
or
$a = 1
also, you might want to do something like this
b = ["zero", "one"]
$b[0] = 0
but that's ambiguous, so you need some sort of grouping mechanism
like for example
${b[0]} = 0
although "$(b[0]) = 0" might be just as reasonable.
also maybe:
b = 'bar'
foo$b = 'baz'
print foobar
#prints baz
${b}foo = 'baz'
print barfoo
#prints baz
$foo{b}baz = 1
print foobarbaz
#prints 1
but i know that last idea is getting way into php-land and probably isn't
(quote-unquote) necessary.
i know a lot of people would probably hate this idea with a passion. i tend
to be more liberal when it comes to adding concision and dynamicism in a
language, although that could be just because it's too tempting; i.e., maybe
it's only because somebody drew a line somewhere that we're coding in Python
instead of K.
--
http://mail.python.org/mailman/listinfo/python-list
