Re: REMOVE ME
On Sunday 10 April 2016 13:46, fan nie wrote: > We cannot remove you. You subscribed, you have to unsubscribe yourself. If you look at the footer of this email, right at the bottom, it should have instructions for unsubscribing. Otherwise, go here: https://mail.python.org/mailman/listinfo/python-list scroll to the bottom of the page, and follow the instructions to unsubscribe. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode normalisation [was Re: [beginner] What's wrong?]
Ben Bacarisse wrote: The problem with that theory is that 'er/re' (this is e and r in either order) is the 3rd most common pair in English but have been placed together. No, they haven't. The order of the characters in the type basket goes down the slanted columns of keys, so E and R are separated by D and C. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode normalisation [was Re: [beginner] What's wrong?]
Steven D'Aprano :
But when you get down to fundamentals, character sets and alphabets have
always blurred the line between presentation and meaning. W ("double-u")
was, once upon a time, UU
And before that, it was VV, because the Romans used V the
way we now use U, and didn't have a letter U.
When U first appeared, it was just a cursive style of writing
a V. According to this, it wasn't until the 18th century that
the English alphabet got both U and V as separate letters:
http://boards.straightdope.com/sdmb/showthread.php?t=147677
Apparently "uu"/"vv" came to be known as "double u" prior to
that, and the name has persisted.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
function to remove and punctuation
how to write a function taking a string parameter, which returns it after you delete the spaces, punctuation marks, accented characters in python ? -- https://mail.python.org/mailman/listinfo/python-list
Re: function to remove and punctuation
On Sun, 10 Apr 2016 09:37 pm, [email protected] wrote: > how to write a function taking a string parameter, which returns it after > you delete the spaces, punctuation marks, accented characters in python ? In your text editor, open a new file. Now bash your fingers onto the keyboard so that letters appear in the file. When you have the function, click Save. (Sorry, I couldn't resist.) Here is one to get you started: def remove_punctuation(the_string): the_string = the_string.replace(".", "") return the_string -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: function to remove and punctuation
[email protected] wrote: > how to write a function taking a string parameter, which returns it after > you delete the spaces, punctuation marks, accented characters in python ? Looks like you want to remove more characters than you want to keep. In this case I'd decide what characters too keep first, e. g. (assuming Python 3) >>> import string >>> keep = string.ascii_letters + string.digits >>> keep 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789' Now you can iterate over the characters and check if you want to preserve it for each of them: >>> def clean(s, keep): ... return "".join(c for c in s if c in keep) ... >>> clean(" äöü ::42", keep) 'alpha42' >>> clean(" äöü ::42", string.ascii_letters) 'alpha' If you are dealing with a lot of text you can make this a bit more efficient with the str.translate() method. Create a mapping that maps all characters that you want to keep to themselves >>> m = str.maketrans(keep, keep) >>> m[ord("a")] 97 >>> m[ord(">")] Traceback (most recent call last): File "", line 1, in KeyError: 62 and all characters that you want to discard to None >>> from collections import defaultdict >>> trans = defaultdict(lambda: None, m) >>> trans[ord("s")] 115 >>> trans[ord("ß")] # returns None, so nothing is printed >>> Now pass it to the translate() method: >>> " äöü ::42".translate(trans) 'alpha42' You changed your mind and want to translate " " to "_"? Here's how: >>> trans[ord(" ")] = "_" >>> " äöü ::42".translate(trans) 'alpha__42' >>> trans[ord(" ")] = "_" >>> " äöü ::42".translate(trans) -- https://mail.python.org/mailman/listinfo/python-list
Change OnScreen Keyboard StringVar (Show linked to one Entry)
Hi guys, im having a little problem to make the StringVar Linked to my OnScreen
Keyboard Change when the user click in one Entry.
Here's my code:
from tkinter import *
Begin Code___
def frame(root, side):
w = Frame(root)
w.pack(side=side, expand=YES, fill=BOTH)
return w
def button(root, side, text, command=None):
w = Button(root, text=text, command=command)
w.pack(side=side, expand=YES, fill=BOTH)
return w
class Keyboard(Frame):
def __init__(self):
Frame.__init__(self)
self.option_add('*Font', 'Verdana 12 bold')
self.pack(expand=YES, fill=BOTH)
self.master.title('Simple Screen Keyboard')
def detect_Focus(event):
print ('Change selected_display to the display correspondent to
selected entry')
display_1 = StringVar()
entry_1 = Entry(self, relief=SUNKEN, textvariable=display_1)
entry_1.bind('', detect_Focus)
entry_1.pack(side=TOP, expand=YES, fill=BOTH)
display_2 = StringVar()
entry_2 = Entry(self, relief=SUNKEN, textvariable=display_2)
entry_2.bind('', detect_Focus)
entry_2.pack(side=TOP, expand=YES, fill=BOTH)
selected_display = display_1
for key in ("123", "456", "789", "-0."):
keyF = frame(self, TOP)
for char in key:
button(keyF, LEFT, char,
lambda w=selected_display, c=char: w.set(w.get() + c))
if __name__ == '__main__':
Keyboard().mainloop()
End Code___
When i run the detect_Focus Function, i wanted change the selected_display, to
make the user change the entry2(display_2), using my on screen keyboard.
Thanks in advance!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Change OnScreen Keyboard StringVar (Show linked to one Entry)
Diego Lelis wrote:
> Hi guys, im having a little problem to make the StringVar Linked to my
> OnScreen Keyboard Change when the user click in one Entry.
>
> Here's my code:
> from tkinter import *
>
> Begin
> Code___
>
> def frame(root, side):
> w = Frame(root)
> w.pack(side=side, expand=YES, fill=BOTH)
> return w
>
> def button(root, side, text, command=None):
> w = Button(root, text=text, command=command)
> w.pack(side=side, expand=YES, fill=BOTH)
> return w
>
>
> class Keyboard(Frame):
> def __init__(self):
> Frame.__init__(self)
> self.option_add('*Font', 'Verdana 12 bold')
> self.pack(expand=YES, fill=BOTH)
> self.master.title('Simple Screen Keyboard')
>
> def detect_Focus(event):
> print ('Change selected_display to the display correspondent
> to selected entry')
>
> display_1 = StringVar()
> entry_1 = Entry(self, relief=SUNKEN, textvariable=display_1)
> entry_1.bind('', detect_Focus)
> entry_1.pack(side=TOP, expand=YES, fill=BOTH)
>
>
> display_2 = StringVar()
> entry_2 = Entry(self, relief=SUNKEN, textvariable=display_2)
> entry_2.bind('', detect_Focus)
> entry_2.pack(side=TOP, expand=YES, fill=BOTH)
>
> selected_display = display_1
>
> for key in ("123", "456", "789", "-0."):
> keyF = frame(self, TOP)
> for char in key:
> button(keyF, LEFT, char,
>lambda w=selected_display, c=char: w.set(w.get() +
>c))
>
> if __name__ == '__main__':
> Keyboard().mainloop()
>
>
> End
> Code___
>
>
> When i run the detect_Focus Function, i wanted change the
> selected_display, to make the user change the entry2(display_2), using my
> on screen keyboard.
The problem is that by setting the default for w
> button(keyF, LEFT, char,
>lambda w=selected_display, c=char: w.set(w.get() +
>c))
you bind w to the current selected display, and to change that binding
afterwards is messy. Instead you should use a variable in a scope shared by
detect_Focus() and the lambda. If there is only ever one instance of
Keyboard this could be the global scope, but using a function or a helper
class if better. Here's the lazy approach that uses the scope of the
__init__() method:
class Keyboard(Frame):
def __init__(self):
Frame.__init__(self)
self.option_add('*Font', 'Verdana 12 bold')
self.pack(expand=YES, fill=BOTH)
self.master.title('Simple Screen Keyboard')
def detect_Focus(event):
nonlocal display
print ('Change selected_display to the display correspondent to
selected entry')
display = display_2 if display is display_1 else display_1
display_1 = StringVar()
entry_1 = Entry(self, relief=SUNKEN, textvariable=display_1)
entry_1.bind('', detect_Focus)
entry_1.pack(side=TOP, expand=YES, fill=BOTH)
display_2 = StringVar()
entry_2 = Entry(self, relief=SUNKEN, textvariable=display_2)
entry_2.bind('', detect_Focus)
entry_2.pack(side=TOP, expand=YES, fill=BOTH)
display = display_1
for key in ("123", "456", "789", "-0."):
keyF = frame(self, TOP)
for char in key:
button(keyF, LEFT, char,
lambda c=char: display.set(display.get() + c))
--
https://mail.python.org/mailman/listinfo/python-list
Change Windows Tkinter after some time
I need to make a change between windows, after some time. But i am have a
little bit of trouble making my code work: My windows change only when i click
on button, i tried to put lambda in my command and also don't work.
import tkinter as tk # python3
#import Tkinter as tk # python
import datetime
TITLE_FONT = ("Helvetica", 18, "bold")
time_start = datetime.datetime.now()
delta_time = datetime.timedelta(seconds = 5)
class SampleApp(tk.Tk):
def __init__(self, *args, **kwargs):
tk.Tk.__init__(self, *args, **kwargs)
# the container is where we'll stack a bunch of frames
# on top of each other, then the one we want visible
# will be raised above the others
container = tk.Frame(self)
container.pack(side="top", fill="both", expand=True)
container.grid_rowconfigure(0, weight=1)
container.grid_columnconfigure(0, weight=1)
self.frames = {}
for F in (StartPage, TimePage):
page_name = F.__name__
frame = F(container, self)
self.frames[page_name] = frame
# put all of the pages in the same location;
# the one on the top of the stacking order
# will be the one that is visible.
frame.grid(row=0, column=0, sticky="nsew")
self.show_frame("StartPage")
def show_frame(self, page_name):
'''Show a frame for the given page name'''
frame = self.frames[page_name]
frame.tkraise()
class StartPage(tk.Frame):
def __init__(self, parent, controller):
tk.Frame.__init__(self, parent)
self.controller = controller
label = tk.Label(self, text="This is the start page", font=TITLE_FONT)
label.pack(side="top", fill="x", pady=10)
button1 = tk.Button(self, text="Go to Time Page",
command=lambda:
controller.show_frame(self.start_Counting()) )
button1.pack()
def start_Counting(self):
global time_start
time_start = datetime.datetime.now()
return 'TimePage'
class TimePage(tk.Frame):
def __init__(self, parent, controller):
global delta_time
tk.Frame.__init__(self, parent)
self.controller = controller
label = tk.Label(self, text="This is Time Page", font=TITLE_FONT)
label.pack(side="top", fill="x", pady=10)
self.time_exit = tk.StringVar()
self.time_exit.set('%s' %datetime.datetime.now())
label2 = tk.Label(self, text=self.time_exit, font=TITLE_FONT)
label2.pack(side="top", fill="x", pady=10)
button = tk.Button(self, text="Go to the start page",
command=lambda: controller.show_frame("StartPage"))
button.pack()
def update_Page(self):
global time_start, delta_time
#print('Executou o atualizar')
time_until = delta_time - (datetime.datetime.now() - time_start)
self.time_exit.set('%s' %time_until)
if time_until <= 0:
self.controller.show_frame('StartPage') # Go to the start_page
after 5 seconds
self.after(1000, update_Page)
if __name__ == "__main__":
app = SampleApp()
app.mainloop()
--
https://mail.python.org/mailman/listinfo/python-list
Re: QWERTY was not designed to intentionally slow typists down (was: Unicode normalisation [was Re: [beginner] What's wrong?])
On Sat, Apr 9, 2016 at 9:09 PM, pyotr filipivich wrote: > ASINTOER are the top eight English letters (not in any order, it > is just that "A Sin To Err" is easy to remember. What's so hard to remember about ETA OIN SHRDLU? Plus that even gives you the top twelve. :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Unacceptable behavior
On Thursday, April 7, 2016 at 2:50:32 AM UTC-4, Ethan Furman wrote: > On 04/05/2016 01:05 PM, Thomas 'PointedEars' Lahn wrote: > > > | >>> from email import ID10T > > Thomas, as has been pointed out to you in previous threads it is not > necessary to be rude to be heard. > > You are hereby placed in moderation for the Python List mailing list. > > Every one else: If you see offensive posts from Thomas on the usenet > side, please just ignore them. I have no desire to see his posts in > your replies. > > -- > ~Ethan~ > Python List Owners Ethan, As a new member of this group, I am not sure on how to report unacceptable behavior. If this is not the correct way, I apologize. Please check the following thread: Find the number of robots needed to walk through the rectangular grid I believe there was some unnecessary rudeness on the part of one of the respondants to the original post Jeff -- https://mail.python.org/mailman/listinfo/python-list
Re: Unacceptable behavior
On Sun, Apr 10, 2016 at 11:54 PM, Jeff Schumaker wrote: > As a new member of this group, I am not sure on how to report unacceptable > behavior. If this is not the correct way, I apologize. > > Please check the following thread: > > Find the number of robots needed to walk through the rectangular grid > > I believe there was some unnecessary rudeness on the part of one of the > respondants to the original post My guess is you're talking about Mark Lawrence, and yes, I agree; he's been fairly vitriolic. The standard way to report abusive behaviour on mailing lists is to contact the owner. For [email protected], that's [email protected], although the corresponding newsgroup isn't really 'owned' in the same way. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Unacceptable behavior
On 10/04/2016 15:03, Chris Angelico wrote: On Sun, Apr 10, 2016 at 11:54 PM, Jeff Schumaker wrote: As a new member of this group, I am not sure on how to report unacceptable behavior. If this is not the correct way, I apologize. Please check the following thread: Find the number of robots needed to walk through the rectangular grid I believe there was some unnecessary rudeness on the part of one of the respondants to the original post My guess is you're talking about Mark Lawrence, and yes, I agree; he's been fairly vitriolic. The standard way to report abusive behaviour on mailing lists is to contact the owner. For [email protected], that's [email protected], although the corresponding newsgroup isn't really 'owned' in the same way. What Chris said: in the case of this list/newsgroup contact [email protected]. If we decide to take action, and the person in question is coming in via Usenet, all we can do is block them at the gateway. Be aware, though, that aside from patently unacceptable behaviour, we're not really interested in policing specific outbursts. People get hot under the collar, lose their cool, say things they might regret. And, thankfully, often come back a while later and apologise. Where it's a case of persistent offensiveness and/or disruption to the list/newsgroup we'll consider pointing the fact out to the person in question and moderating their posts for a period. All we can do, really. TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: function to remove and punctuation
Peter Otten wrote: > [email protected] wrote: >> how to write a function taking a string parameter, which returns it after >> you delete the spaces, punctuation marks, accented characters in python ? > > Looks like you want to remove more characters than you want to keep. In > this case I'd decide what characters too keep first, e. g. (assuming > Python 3) However, with *that* approach (which is different from the OP’s request), regular expression matching might turn out to be more efficient: --- import re print("".join(re.findall(r'[a-z]+', "...", re.IGNORECASE))) --- With the OP’s original request, they may still be the better approach. For example: -- import re print("".join(re.sub(r'[\s,;.?!ÀÁÈÉÌÍÒÓÙÚÝ]+', "", "...", flags=re.IGNORECASE))) -- or -- import re print("".join(re.findall(r'[^\s,;.?!ÀÁÈÉÌÍÒÓÙÚÝ]+', "", "...", flags=re.IGNORECASE))) -- import string keep = string.ascii_letters + string.digits keep > 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789' > > Now you can iterate over the characters and check if you want to preserve > it for each of them: The good thing about this part of the approach you suggested is that you can build regular expressions from strings, too: keep = '[' + 'a-z' + r'\d' + ']' def clean(s, keep): > ... return "".join(c for c in s if c in keep) > ... Why would one prefer this over "".filter(lambda: c in keep, s)? clean(" äöü ::42", keep) > 'alpha42' clean(" äöü ::42", string.ascii_letters) > 'alpha' > > If you are dealing with a lot of text you can make this a bit more > efficient with the str.translate() method. Create a mapping that maps all > characters that you want to keep to themselves > m = str.maketrans(keep, keep) m[ord("a")] > 97 m[ord(">")] > Traceback (most recent call last): > File "", line 1, in > KeyError: 62 > > and all characters that you want to discard to None Why would creating a *larger* list for *more* operations be *more* efficient? -- PointedEars Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail. -- https://mail.python.org/mailman/listinfo/python-list
Re: function to remove and punctuation
Thomas 'PointedEars' Lahn wrote: > Peter Otten wrote: > >> [email protected] wrote: >>> how to write a function taking a string parameter, which returns it >>> after you delete the spaces, punctuation marks, accented characters in >>> python ? >> >> Looks like you want to remove more characters than you want to keep. In >> this case I'd decide what characters too keep first, e. g. (assuming >> Python 3) > > However, with *that* approach (which is different from the OP’s request), > regular expression matching might turn out to be more efficient: > > --- > import re > print("".join(re.findall(r'[a-z]+', "...", re.IGNORECASE))) > --- > > With the OP’s original request, they may still be the better approach. > For example: > > -- > import re > print("".join(re.sub(r'[\s,;.?!ÀÁÈÉÌÍÒÓÙÚÝ]+', "", "...", > flags=re.IGNORECASE))) > -- > > or > > -- > import re > print("".join(re.findall(r'[^\s,;.?!ÀÁÈÉÌÍÒÓÙÚÝ]+', "", "...", > flags=re.IGNORECASE))) > -- > > import string > keep = string.ascii_letters + string.digits > keep >> 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789' >> >> Now you can iterate over the characters and check if you want to preserve >> it for each of them: > > The good thing about this part of the approach you suggested is that you > can build regular expressions from strings, too: > > keep = '[' + 'a-z' + r'\d' + ']' > > def clean(s, keep): >> ... return "".join(c for c in s if c in keep) >> ... > > Why would one prefer this over "".filter(lambda: c in keep, s)? Because it's idiomatic Python and easy to understand if you are coming from the imperative buf = [] for c in s: if c in keep: buf.append(c) "".join(buf) Because it uses Python syntax instead of the filter/map/reduce trio. Because it avoids the extra function call (the lambda) though the speed difference is not as big as I expected: $ python3 -m timeit -s 'import string; keep = string.ascii_letters + string.digits; s = "alphabet soup ä" * 1000' '"".join(filter(lambda c: c in keep, s))' 100 loops, best of 3: 4.66 msec per loop $ python3 -m timeit -s 'import string; keep = string.ascii_letters + string.digits; s = "alphabet soup ä" * 1000' '"".join(c for c in s if c in keep)' 100 loops, best of 3: 3.11 msec per loop For reference here is a variant using regular expressions (picked at random, feel free to find a faster one): $ python3 -m timeit -s 'import string, re; keep = string.ascii_letters + string.digits; s = "alphabet soup ä" * 1000; sub=re.compile(r"[^a-zA- Z0-9]+").sub' 'sub("", s)' 1000 loops, best of 3: 1.65 msec per loop And finally str.translate(): $ python3 -m timeit -s 'import string, collections as c; keep = string.ascii_letters + string.digits; s = "alphabet soup ä" * 1000; trans = c.defaultdict(lambda: None, str.maketrans(keep, keep))' 's.translate(trans)' 1000 loops, best of 3: 997 usec per loop > clean(" äöü ::42", keep) >> 'alpha42' > clean(" äöü ::42", string.ascii_letters) >> 'alpha' >> >> If you are dealing with a lot of text you can make this a bit more >> efficient with the str.translate() method. Create a mapping that maps all >> characters that you want to keep to themselves >> > m = str.maketrans(keep, keep) > m[ord("a")] >> 97 > m[ord(">")] >> Traceback (most recent call last): >> File "", line 1, in >> KeyError: 62 >> >> and all characters that you want to discard to None > > Why would creating a *larger* list for *more* operations be *more* > efficient? > I don't understand the question. If you mean that the trans dict may become large -- that depends on the input data. The characters to be deleted are lazily added to the defaultdict. For text in european languages the total size should stay well below 256 entries. But you are probably aiming at something else... -- https://mail.python.org/mailman/listinfo/python-list
Moderation and Usenet
Mark Lawrence is currently being moderated. If you see offensive posts from him on the Usenet side please do not respond. Thank you. -- ~Ethan~ Python List Owners -- https://mail.python.org/mailman/listinfo/python-list
Re: Untrusted code execution
On 2016-04-07, Jon Ribbens wrote: > I've put an example script here: > > https://github.com/jribbens/unsafe/blob/master/unsafe.py > > When run as a script, it will execute whatever Python code you pass it > on stdin. > > If anyone can break it (by which I mean escape from the sandbox, > not make it use up all the memory or go into an infinite loop, > both of which are trivial) then I would be very interested. I've updated the script a bit, to fix a couple of bugs, to add back in 'with' and 'import' (of white-listed modules) and to add a REPL mode which makes experimenting inside the sandbox easier. I'm still interested to see if anyone can find a way out of it ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Unacceptable behavior
On Sunday, April 10, 2016 at 2:54:45 PM UTC+1, Jeff Schumaker wrote: > On Thursday, April 7, 2016 at 2:50:32 AM UTC-4, Ethan Furman wrote: > > On 04/05/2016 01:05 PM, Thomas 'PointedEars' Lahn wrote: > > > > > | >>> from email import ID10T > > > > Thomas, as has been pointed out to you in previous threads it is not > > necessary to be rude to be heard. > > > > You are hereby placed in moderation for the Python List mailing list. > > > > Every one else: If you see offensive posts from Thomas on the usenet > > side, please just ignore them. I have no desire to see his posts in > > your replies. > > > > -- > > ~Ethan~ > > Python List Owners > > Ethan, > > As a new member of this group, I am not sure on how to report unacceptable > behavior. If this is not the correct way, I apologize. > > Please check the following thread: > > Find the number of robots needed to walk through the rectangular grid > > I believe there was some unnecessary rudeness on the part of one of the > respondants to the original post > > Jeff I'm been through the entire thread and haven't got the faintest idea what you're talking about. Or are you in the camp that believes when someone is too bone idle to do any work for themselves, and turns up here asking for us to write all of their code for them, we should kill the fatted calf, roll out the red carpet, and then write the code? -- https://mail.python.org/mailman/listinfo/python-list
Re: Unacceptable behavior
On Sunday, April 10, 2016 at 3:03:37 PM UTC+1, Chris Angelico wrote: > On Sun, Apr 10, 2016 at 11:54 PM, Jeff Schumaker > wrote: > > As a new member of this group, I am not sure on how to report unacceptable > > behavior. If this is not the correct way, I apologize. > > > > Please check the following thread: > > > > Find the number of robots needed to walk through the rectangular grid > > > > I believe there was some unnecessary rudeness on the part of one of the > > respondants to the original post > > My guess is you're talking about Mark Lawrence, and yes, I agree; he's > been fairly vitriolic. > > The standard way to report abusive behaviour on mailing lists is to > contact the owner. For [email protected], that's > [email protected], although the corresponding newsgroup > isn't really 'owned' in the same way. > > ChrisA You were wrong, care to have another go? -- https://mail.python.org/mailman/listinfo/python-list
Re: Unacceptable behavior
On Sun, Apr 10, 2016, at 13:15, [email protected] wrote: > Or are you in the camp that believes when someone > is too bone idle to do any work for themselves, and turns up here asking > for us to write all of their code for them, we should kill the fatted > calf, roll out the red carpet, and then write the code? You can be polite while still saying no. -- https://mail.python.org/mailman/listinfo/python-list
Re: Moderation and Usenet
On 4/10/2016 1:05 PM, Ethan Furman wrote: If you see offensive posts from him on the Usenet side please do not respond. Just a reminder for those who, like me, prefer a newsgroup interface for python-list: gmane.comp.python.general at news.gmane.org mirrors the moderated output of python-list. (Gmane does the same for 1000s of tecnhical lists.) I believe that posts submitted from gmane are sent to the list *first*, and never appear on the gmane mirror until they appear on the list. Thus one will not see and cannot accidentally respond to a post that did not appear on the list. One gets the benefits of list moderation without a flooded mailbox. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Change Windows Tkinter after some time
On 4/10/2016 9:36 AM, Diego Lelis wrote: I need to make a change between windows, after some time. But i am have a little bit of trouble making my code work: My windows change only when i click on button, i tried to put lambda in my command and also don't work. I and others have written multiple answers on Stackoverflow about making root.after work. I suggest that you search "[tkinter] root.after" there. [snip somewhat baroque code] I urge you to read SO's "How to create a Minimal, Complete, and Verifiable example" https://stackoverflow.com/help/mcve This not only helps you write questions that get answers, but may help you find the problem yourself. I believe that all the stuff with .now and datetime deltas is inessential noise. The initial parameter to .after is a integer millisecond delta. All the font stuff is irrelevant to the problem, so is some other stuff in your code. I think you problem is that you never call root.after to start the process going. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Change Windows Tkinter after some time
On 4/10/2016 2:11 PM, Terry Reedy wrote: On 4/10/2016 9:36 AM, Diego Lelis wrote: I need to make a change between windows, after some time. But i am have a little bit of trouble making my code work: My windows change only when i click on button, i tried to put lambda in my command and also don't work. I and others have written multiple answers on Stackoverflow about making root.after work. I suggest that you search "[tkinter] root.after" there. [snip somewhat baroque code] I urge you to read SO's "How to create a Minimal, Complete, and Verifiable example" https://stackoverflow.com/help/mcve This not only helps you write questions that get answers, but may help you find the problem yourself. I believe that all the stuff with .now and datetime deltas is inessential noise. The initial parameter to .after is a integer millisecond delta. All the font stuff is irrelevant to the problem, so is some other stuff in your code. I think you problem is that you never call root.after to start the process going. I see you also posted on SO and got essentially the same answer 4 hours before I wasted my time saying the same thing because I thought you had been ignored. Please don't do this. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Unacceptable behavior
On 10/04/2016 18:15, [email protected] wrote: [... snip Mark again, using a different address to avoid the moderation check ...] Mark, Please don't do this. If you genuinely want this list to be a useful and friendly resource, which is what your posts suggest, then please step back and look at your own words and see whether they actually further that end. As moderators, we don't intervene lightly or often. And it seems that the things for which we intervene (such as your repeated bolshy manner lately) are not the things for you which you would intervene (such as off-topic posts or ill-considered questions). So be it. If this list isn't the thing you want it to be, and if its current moderators don't feel that it needs to change in the way you want it to change, then perhaps you should consider directing your undoubted energies elsewhere. But please don't play cat-and-mouse just because you want to have the upper hand and get the last word. I said it before and I'll say it again here: have a little dignity and accept that your ideal is not everyone's and move on. Or be the better person and contribute usefully to the list as you've often done. TJG -- https://mail.python.org/mailman/listinfo/python-list
Most probably a stupid question, but I still want to ask
let's look at this:
$ python3.4
Python 3.4.0 (default, Apr 11 2014, 13:05:11)
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> line1 = '"String1" | bla'
>>> parts1 = line1.split(" | ")
>>> parts1
['"String1"', 'bla']
>>> tokens1 = eval(parts1[0])
>>> tokens1
'String1'
>>> tokens1[0]
'S'
and now this
>>> line2 = '"String1","String2" | bla'
>>> parts2 = line2.split(" | ")
>>> tokens2 = eval(parts2[0])
>>> tokens2
('String1', 'String2')
>>> tokens2[0]
'String1'
>>> type(tokens1)
>>> type(tokens2)
>>>
the question is: at which point did the language designers decide to betray the
"path of least surprise" principle and create a 'discontinuity' in the language?
Open to the idea that I am getting something fundamentally wrong. I'm new to
Python...
Thanks
--
https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
On Mon, Apr 11, 2016 at 8:51 AM, Fillmore wrote: > the question is: at which point did the language designers decide to betray > the > "path of least surprise" principle and create a 'discontinuity' in the > language? > Open to the idea that I am getting something fundamentally wrong. I'm new to > Python... Can you please simplify your example and show what the discontinuity is you're referring to? You keep messing with eval and split and stuff, and then looking at the types of things. Which part are you surprised at? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
Fillmore writes: > let's look at this: Can you set a “Subject” field that pertains to the actual question? As is, it doesn't help know what you want to discuss. > the question is: at which point did the language designers decide to > betray the "path of least surprise" principle and create a > 'discontinuity' in the language? This, also, doesn't help us know what the question is. Please describe what you expect that code to do, and if possible what it is that surprises you about its behaviour. -- \ “Repetition leads to boredom, boredom to horrifying mistakes, | `\ horrifying mistakes to God-I-wish-I-was-still-bored, and it | _o__) goes downhill from there.” —Will Larson, 2008-11-04 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
On Sun, Apr 10, 2016, at 03:51 PM, Fillmore wrote:
>
> let's look at this:
>
> $ python3.4
> Python 3.4.0 (default, Apr 11 2014, 13:05:11)
> [GCC 4.8.2] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> line1 = '"String1" | bla'
> >>> parts1 = line1.split(" | ")
> >>> parts1
> ['"String1"', 'bla']
> >>> tokens1 = eval(parts1[0])
> >>> tokens1
> 'String1'
> >>> tokens1[0]
> 'S'
>
> and now this
>
> >>> line2 = '"String1","String2" | bla'
> >>> parts2 = line2.split(" | ")
> >>> tokens2 = eval(parts2[0])
I *THINK* what you're asking is why this returns a tuple, where in the
first eval you got a string. The answer is because commas create tuples
(not parens), so:
"String1", "String2"
is a tuple expression. Whereas:
"String1"
is a string expression.
> the question is: at which point did the language designers decide to
> betray the
> "path of least surprise" principle and create a 'discontinuity' in the
> language?
There's nothing inconsistent or surprising going on besides you doing
something vaguely weird and not really expressing what you find
surprising.
--Stephen
m e @ i x o k a i . i o
--
https://mail.python.org/mailman/listinfo/python-list
one-element tuples [Was: Most probably a stupid question, but I still want to ask]
Sorry guys. It was not my intention to piss off anyone...just trying to
understand how the languare works
I guess that the answer to my question is: there is no such thing as a
one-element tuple,
and Python will automatically convert a one-element tuple to a string... hence
the
behavior I observed is explained...
>>> a = ('hello','bonjour')
>>> b = ('hello')
>>> b
'hello'
>>> a
('hello', 'bonjour')
>>>
Did I get this right this time?
--
https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]
On Sun, Apr 10, 2016, at 05:13 PM, Fillmore wrote:
> I guess that the answer to my question is: there is no such thing as a
> one-element tuple,
> and Python will automatically convert a one-element tuple to a string...
> hence the
> behavior I observed is explained...
>
> >>> a = ('hello','bonjour')
> >>> b = ('hello')
> >>> b
> 'hello'
> >>> a
> ('hello', 'bonjour')
> >>>
>
>
> Did I get this right this time?
No, you didn't. Your mistake is again -- parens don't make tuples,
commas do.
A one element tuple is:
>>> b = ("hello,)
The parens are optional, I always put them in because:
>>> b = "hello",
The parens group an expression, they don't make a type.
--
Stephen Hansen
m e @ i x o k a i . i o
--
https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]
On Sun, Apr 10, 2016, at 05:18 PM, Stephen Hansen wrote: > The parens are optional, I always put them in because: > >>> b = "hello", Ahem, "because its easy to miss the trailing comma" is what I meant to say here. -- https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
On 04/10/2016 07:30 PM, Stephen Hansen wrote: There's nothing inconsistent or surprising going on besides you doing something vaguely weird and not really expressing what you find surprising. well, I was getting some surprising results for some of my data, so I can guarantee that I was surprised! apparently my 'discontinuity' is mappable to the fact that there's no such thing as one-element tuples in Python, and attempts to create one will result in a string (i.e. an object of a different kind!)... -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]
On 04/10/2016 08:13 PM, Fillmore wrote:
Sorry guys. It was not my intention to piss off anyone...just trying to
understand how the languare works
I guess that the answer to my question is: there is no such thing as a
one-element tuple,
and Python will automatically convert a one-element tuple to a string... hence
the
behavior I observed is explained...
>>> a = ('hello','bonjour')
>>> b = ('hello')
>>> b
'hello'
>>> a
('hello', 'bonjour')
>>>
Hold on a sec! it turns up that there is such thing as single-element tuples in
python:
>>> c = ('hello',)
>>> c
('hello',)
>>> c[0]
'hello'
>>> c[1]
Traceback (most recent call last):
File "", line 1, in
IndexError: tuple index out of range
>>>
So, my original question makes sense. Why was a discontinuation point
introduced by the language designer?
--
https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]
On Mon, Apr 11, 2016 at 10:13 AM, Fillmore wrote:
> Sorry guys. It was not my intention to piss off anyone...just trying to
> understand how the languare works
>
> I guess that the answer to my question is: there is no such thing as a
> one-element tuple,
> and Python will automatically convert a one-element tuple to a string...
> hence the
> behavior I observed is explained...
>
a = ('hello','bonjour')
b = ('hello')
b
> 'hello'
a
> ('hello', 'bonjour')
>
>
> Did I get this right this time?
Okay, now you're asking a question in a reasonable way, so we can answer :)
The thing you're confused at is that it's not the parentheses that
create a tuple. Parentheses merely group.
>>> 'hello', 'bonjour'
('hello', 'bonjour')
>>> 'hello',
('hello',)
One-element tuples are perfectly possible, but you MUST have a comma,
so you have one at the end. The trailing comma is perfectly legal (and
ignored) on larger tuples.
>>> 'hello', 'bonjour',
('hello', 'bonjour')
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]
On Sun, Apr 10, 2016, at 05:22 PM, Fillmore wrote:
> Hold on a sec! it turns up that there is such thing as single-element
> tuples in python:
>
> >>> c = ('hello',)
> >>> c
> ('hello',)
> >>> c[0]
> 'hello'
> >>> c[1]
> Traceback (most recent call last):
>File "", line 1, in
> IndexError: tuple index out of range
> >>>
>
> So, my original question makes sense. Why was a discontinuation point
> introduced by the language designer?
What discontinuation point?
You keep masterfully managing to *not explain what you're asking*. What
is surprising to you?
--S
--
https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]
On 2016-04-11 01:13, Fillmore wrote:
Sorry guys. It was not my intention to piss off anyone...just trying to
understand how the languare works
I guess that the answer to my question is: there is no such thing as a
one-element tuple,
and Python will automatically convert a one-element tuple to a string... hence
the
behavior I observed is explained...
>>> a = ('hello','bonjour')
>>> b = ('hello')
>>> b
'hello'
>>> a
('hello', 'bonjour')
>>>
Did I get this right this time?
Nope. :-)
A one-element tuple can be written as:
>>> ('hello',)
('hello',)
As has been said already, it's the comma that makes the tuple. The
parentheses are often needed to avoid ambiguity.
For example, object are passed into a function thus:
f(x, y)
(In reality, it's making a tuple and then passing that in.)
What if you want to pass in the tuple (1, 2) as a single argument?
f((1, 2))
If you write this:
f(1, 2)
it passes them in as 2 separate arguments.
Or consider this:
f((1, 2), 3)
This has 2 arguments: the first is the tuple (1, 2) and the second is
the int 3.
There _is_ one exception though: (). It's the empty tuple (a 0-element
tuple). It doesn't have a comma and the parentheses are mandatory.
There's no other way to write it.
--
https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]
Fillmore writes:
> Sorry guys. It was not my intention to piss off anyone...just trying
> to understand how the languare works
Frustration is understandable when learning something new :-) Hopefully
that can be a signal to take a breath, and compose messages to minimise
frustration for the readers.
> I guess that the answer to my question is: there is no such thing as a
> one-element tuple,
Certainly there is. Tuples – like any container type – can contain zero,
one, or more items.
>>> foo = ()
>>> bar = ("spam",)
>>> baz = ("spam", "eggs")
>>> blub = ("spam", "eggs", "beans")
>>> len(foo)
0
>>> len(bar)
1
>>> len(baz)
2
>>> len(blub)
3
> and Python will automatically convert a one-element tuple to a
> string...
You appear to be confusing text representation, and program syntax, and
the values themselves.
Program syntax is the structured text you type, in order that Python
should compile it and result in program code. That source code is text
with a specific representation of values and statements.
The values themselves are what exist within the Python process while it
is executing your compiled code. There is no text representation of
that, Python manipulates the values in an internal representation
normally inaccessible to the program itself.
The text representation that objects can generate on request is yet
another matter; for convenience it sometimes matches a syntactic text
that could be used to construct an equal value, but often that's not the
case. It should not be thought of as any kind of universal rule.
> Did I get this right this time?
I hope that helps to distinguish the different matters that are
confusing you.
--
\“Last year I went fishing with Salvador Dali. He was using a |
`\ dotted line. He caught every other fish.” —Steven Wright |
_o__) |
Ben Finney
--
https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples
Fillmore writes: > So, my original question makes sense. Why was a discontinuation point > introduced by the language designer? Can you describe explicitly what that “discontinuation point” is? I'm not seeing it. -- \ “People are very open-minded about new things, as long as | `\ they're exactly like the old ones.” —Charles F. Kettering | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
On Sun, Apr 10, 2016, at 05:17 PM, Fillmore wrote: > On 04/10/2016 07:30 PM, Stephen Hansen wrote: > > > There's nothing inconsistent or surprising going on besides you doing > > something vaguely weird and not really expressing what you find > > surprising. > > well, I was getting some surprising results for some of my data, so I can > guarantee that I was surprised! The point is you are not saying *what* is surprising. Nothing in your example code looks the least bit surprising to me, but I've been using Python for ages. If you're surprised by something, say *what* surprises you at the very least. But to repeat what I said that you didn't quote: the thing you need to understand is that parentheses do not create tuples, commas do. Parentheses only group things together. --Stephen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]
On Mon, Apr 11, 2016 at 10:33 AM, MRAB wrote: > For example, object are passed into a function thus: > > f(x, y) > > (In reality, it's making a tuple and then passing that in.) Actually that's not the case; certain syntactic constructs allow you to specify multiple of something, without packaging them up into a tuple. Function arguments and parameters are like this; otherwise keyword arguments would have to be some kind of magic syntax in tuples, instead of being a feature of function calls. But there are plenty of situations where what you're describing _is_ the case, such as assigning multiple values to multiple targets: # Package up y and x into a tuple # Then unpack the tuple into two names x, y = y, x ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask])
Stephen Hansen writes: > […] parens don't make tuples, commas do. Chris Angelico writes: > The thing you're confused at is that it's not the parentheses that > create a tuple. Parentheses merely group. MRAB writes: > As has been said already, it's the comma that makes the tuple. The > parentheses are often needed to avoid ambiguity. This is too simplistic, and IMO it's just sowing the seed for future confusion. As MRAB states in the same message: > There _is_ one exception though: (). It's the empty tuple (a 0-element > tuple). It doesn't have a comma and the parentheses are mandatory. > There's no other way to write it. So, let's please stop saying “parens don't create a tuple”. They do, and because of that I've stopped saying that false over-simplification. A pair of tuples as an expression is literal syntax to create a tuple with zero items. Also, there is another obvious way to create an empty tuple: call the ‘tuple’ type directly: >>> foo = tuple() >>> print(type(foo), len(foo)) 0 So the expanation that remains true when you examine it is: People wanted a literal syntax to create a zero-length tuple. A pair of parens is that literal syntax, and it's the parens that create the (empty) tuple. -- \ “It is hard to believe that a man is telling the truth when you | `\ know that you would lie if you were in his place.” —Henry L. | _o__) Mencken | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples
On 04/10/2016 08:31 PM, Ben Finney wrote: Can you describe explicitly what that “discontinuation point” is? I'm not seeing it. Here you go: >>> a = '"string1"' >>> b = '"string1","string2"' >>> c = '"string1","string2","string3"' >>> ea = eval(a) >>> eb = eval(b) >>> ec = eval(c) >>> type(ea) <--- HERE >>> type(eb) >>> type(ec) I can tell you that it exists because it bit me in the butt today... and mind you, I am not saying that this is wrong. I'm just saying that it surprised me. -- https://mail.python.org/mailman/listinfo/python-list
Re: Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask])
On Mon, Apr 11, 2016 at 10:45 AM, Ben Finney wrote: > So the expanation that remains true when you examine it is: People > wanted a literal syntax to create a zero-length tuple. A pair of parens > is that literal syntax, and it's the parens that create the (empty) > tuple. But parens do NOT create a one-element tuple, and that's usually where people trip up. If you show someone this line of code: x = () and ask what x will be, you might get some wrong responses, but you'll get a lot of people correctly deducing that it's a tuple. The problem is that people see this progression: x = () y = (1) z = (1, 2) and assume they're all tuples. A better progression is this: x = () y = (1,) z = (1, 2,) where every element is followed by a comma and every tuple is surrounded by parentheses. In that situation, everything works. There are slightly different rules about which parts are optional (the parens everywhere except the first case, and the last comma everywhere except the second), but this should be the basic form of tuple progression. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples
Fillmore writes: > Here you go: > > >>> a = '"string1"' > >>> b = '"string1","string2"' > >>> c = '"string1","string2","string3"' > >>> ea = eval(a) > >>> eb = eval(b) > >>> ec = eval(c) > >>> type(ea) ><--- HERE > >>> type(eb) > > >>> type(ec) > > > I can tell you that it exists because it bit me in the butt today... > > and mind you, I am not saying that this is wrong. I'm just saying that > it surprised me. What behaviour did you expect instead? That's still unclear. Can you show the fictional session that would result from the behaviour you expect? -- \ “Education is learning what you didn't even know you didn't | `\ know.” —Daniel J. Boorstin, historian, 1914–2004 | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Parens do create a tuple
Chris Angelico writes: > On Mon, Apr 11, 2016 at 10:45 AM, Ben Finney > wrote: > > So the expanation that remains true when you examine it is: People > > wanted a literal syntax to create a zero-length tuple. A pair of parens > > is that literal syntax, and it's the parens that create the (empty) > > tuple. > > But parens do NOT create a one-element tuple, and that's usually where > people trip up. So let's stop saying “parens do not create a tuple”, because that's just wantonly creating *another* stubling block. -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\Brain, but don't you need a swimming pool to play Marco Polo?” | _o__) —_Pinky and The Brain_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Parens do create a tuple
On Mon, Apr 11, 2016 at 10:57 AM, Ben Finney wrote: > Chris Angelico writes: > >> On Mon, Apr 11, 2016 at 10:45 AM, Ben Finney >> wrote: >> > So the expanation that remains true when you examine it is: People >> > wanted a literal syntax to create a zero-length tuple. A pair of parens >> > is that literal syntax, and it's the parens that create the (empty) >> > tuple. >> >> But parens do NOT create a one-element tuple, and that's usually where >> people trip up. > > So let's stop saying “parens do not create a tuple”, because that's just > wantonly creating *another* stubling block. Fair enough. Let's instead say "commas create tuples", which is true in all cases except the singleton empty tuple. Is that near enough that we can avoid the detail? I'd rather be correct on the one-element case and wrong on the empty than the other way around. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples
On Sunday, April 10, 2016 at 8:48:49 PM UTC-4, Fillmore wrote:
> On 04/10/2016 08:31 PM, Ben Finney wrote:
> > Can you describe explicitly what that "discontinuation point" is? I'm
> > not seeing it.
>
> Here you go:
>
> >>> a = '"string1"'
> >>> b = '"string1","string2"'
> >>> c = '"string1","string2","string3"'
> >>> ea = eval(a)
> >>> eb = eval(b)
> >>> ec = eval(c)
> >>> type(ea)
><--- HERE
> >>> type(eb)
>
> >>> type(ec)
>
>
> I can tell you that it exists because it bit me in the butt today...
>
> and mind you, I am not saying that this is wrong. I'm just saying that it
> surprised me.
Perhaps the extra complication of eval is confusing things. This:
>>> a = '"string1"'
>>> ea = eval(a)
>>> type(ea)
is the same as:
>>> type("string1")
Does that surprise you? "string1" sure looks like a plain-old string to
me, I'm not sure why you would think it would be a tuple.
Your three expressions are:
ea = "string1"
eb = "string1","string2"
ec = "string1","string2","string3"
ea is a string, eb is a two-element tuple (both elements are strings),
and ec is a three-element tuple (all elements are strings).
As others have said, commas make tuples. Your first expression has no
commas (and no parens!) so it is not a tuple.
--Ned.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask])
On Sun, Apr 10, 2016, at 05:45 PM, Ben Finney wrote: > So, let's please stop saying “parens don't create a tuple”. They do, and > because of that I've stopped saying that false over-simplification. I stand by "parens don't make a tuple", with the caveat that I should have mentioned the empty tuple exception that proves the rule. The only time you need parens is to resolve ambiguity. To suggest that parens do make tuples confuses the issue, given things like this: >>> a = 1,2,3 >>> b = (1, 2, 3) -- Stephen Hansen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples
On Sun, Apr 10, 2016, at 05:48 PM, Fillmore wrote: > On 04/10/2016 08:31 PM, Ben Finney wrote: > > Can you describe explicitly what that “discontinuation point” is? I'm > > not seeing it. > > Here you go: > > >>> a = '"string1"' Here, "a" is a string that contains a double quoted string. So if you evaluate it, you get a string. > >>> b = '"string1","string2"' Here, "b" is a string that contains two double quoted strings separated by a comma. So if you evaluate it, you get a tuple of two strings. > >>> c = '"string1","string2","string3"' This is as above, but with three items. With that in mind: > >>> ea = eval(a) > >>> eb = eval(b) > >>> ec = eval(c) > >>> type(ea) > > >>> type(eb) > > >>> type(ec) > This should all be expected. The commas, when you evaluate them, are in B&C making tuples. There's only a single string in A, so you get a string. If you wanted a one item tuple, you would have written: >>> a = '"string1",' Note the trailing comma. > I can tell you that it exists because it bit me in the butt today... > > and mind you, I am not saying that this is wrong. I'm just saying that it > surprised me. If the above doesn't explain it, then I still don't understand what you're finding surprising and what you'd expect otherwise. ---Stephen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples
Hello Fillmore, > Here you go: > > >>> a = '"string1"' > >>> b = '"string1","string2"' > >>> c = '"string1","string2","string3"' > >>> ea = eval(a) > >>> eb = eval(b) > >>> ec = eval(c) > >>> type(ea) ><--- HERE > >>> type(eb) > > >>> type(ec) > > > I can tell you that it exists because it bit me in the butt today... > > and mind you, I am not saying that this is wrong. I'm just saying > that it surprised me. Recently in one of these two threads on your question, people have identified why the behaviour is as it is. Below, I will add one question (about eval) and one suggestion about how to circumvent the behaviour you perceive as a language discontinuity. #1: I would not choose eval() except when there is no other solution. If you don't need eval(), it may save you some headache in the future, as well, to find an alternate way. So, can we help you choose something other than eval()? What are you trying to do with that usage? #2: Yes, but, you can outsmart Python here! Simply include a terminal comma in each case, right? In short, you can force the consuming language (Python, because you are calling eval()) to understand the string as a tuple of strings, rather than merely one string. >>> a = '"string1",' >>> ea = eval(a) >>> len(ea), type(ea) (1, ) >>> b = '"string1","string2",' >>> eb = eval(b) >>> len(eb), type(eb) (2, ) >>> c = '"string1","string2","string3",' >>> ec = eval(c) >>> len(ec), type(ec) (3, ) Good luck in your continuing Python explorations, -Martin P.S. Where do your double-quoted strings come from, anyway? -- Martin A. Brown http://linux-ip.net/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Unacceptable behavior
On Sunday, April 10, 2016 at 1:15:18 PM UTC-4, [email protected] wrote: > On Sunday, April 10, 2016 at 2:54:45 PM UTC+1, Jeff Schumaker wrote: > > On Thursday, April 7, 2016 at 2:50:32 AM UTC-4, Ethan Furman wrote: > > > On 04/05/2016 01:05 PM, Thomas 'PointedEars' Lahn wrote: > > > > > > > | >>> from email import ID10T > > > > > > Thomas, as has been pointed out to you in previous threads it is not > > > necessary to be rude to be heard. > > > > > > You are hereby placed in moderation for the Python List mailing list. > > > > > > Every one else: If you see offensive posts from Thomas on the usenet > > > side, please just ignore them. I have no desire to see his posts in > > > your replies. > > > > > > -- > > > ~Ethan~ > > > Python List Owners > > > > Ethan, > > > > As a new member of this group, I am not sure on how to report unacceptable > > behavior. If this is not the correct way, I apologize. > > > > Please check the following thread: > > > > Find the number of robots needed to walk through the rectangular grid > > > > I believe there was some unnecessary rudeness on the part of one of the > > respondants to the original post > > > > Jeff > > I'm been through the entire thread and haven't got the faintest idea what > you're talking about. Or are you in the camp that believes when someone is > too bone idle to do any work for themselves, and turns up here asking for us > to write all of their code for them, we should kill the fatted calf, roll out > the red carpet, and then write the code? Certainly not, but as Random832 says, you can politely say No. I realize there is no minimum requirement for social etiquette to be a good programmer. Or a bad one, for that matter. But if the purpose of this group is to help others with Python, simple courtesy seems to be common sense. Jeff -- https://mail.python.org/mailman/listinfo/python-list
Re: Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask])
On 2016-04-11 10:45, Ben Finney wrote: > Also, there is another obvious way to create an empty tuple: call > the ‘tuple’ type directly: > > >>> foo = tuple() > >>> print(type(foo), len(foo)) > 0 But here the parens make the tuple too: >>> foo = tuple >>> print(type(foo)) >>> len(foo) Traceback (most recent call last): File "", line 1, in TypeError: object of type 'type' has no len() (totally just yanking chains, throwing pebbles in the pond to watch the ripples, and otherwise sewing confusion ;-) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Unacceptable behavior
On Sunday, April 10, 2016 at 9:29:19 PM UTC-4, Jeff Schumaker wrote: > On Sunday, April 10, 2016 at 1:15:18 PM UTC-4, [email protected] wrote: > > On Sunday, April 10, 2016 at 2:54:45 PM UTC+1, Jeff Schumaker wrote: > > > On Thursday, April 7, 2016 at 2:50:32 AM UTC-4, Ethan Furman wrote: > > > > On 04/05/2016 01:05 PM, Thomas 'PointedEars' Lahn wrote: > > > > > > > > > | >>> from email import ID10T > > > > > > > > Thomas, as has been pointed out to you in previous threads it is not > > > > necessary to be rude to be heard. > > > > > > > > You are hereby placed in moderation for the Python List mailing list. > > > > > > > > Every one else: If you see offensive posts from Thomas on the usenet > > > > side, please just ignore them. I have no desire to see his posts in > > > > your replies. > > > > > > > > -- > > > > ~Ethan~ > > > > Python List Owners > > > > > > Ethan, > > > > > > As a new member of this group, I am not sure on how to report > > > unacceptable behavior. If this is not the correct way, I apologize. > > > > > > Please check the following thread: > > > > > > Find the number of robots needed to walk through the rectangular grid > > > > > > I believe there was some unnecessary rudeness on the part of one of the > > > respondants to the original post > > > > > > Jeff > > > > I'm been through the entire thread and haven't got the faintest idea what > > you're talking about. Or are you in the camp that believes when someone is > > too bone idle to do any work for themselves, and turns up here asking for > > us to write all of their code for them, we should kill the fatted calf, > > roll out the red carpet, and then write the code? > > Certainly not, but as Random832 says, you can politely say No. > > I realize there is no minimum requirement for social etiquette to be a good > programmer. Or a bad one, for that matter. But if the purpose of this group > is to help others with Python, simple courtesy seems to be common sense. > > Jeff Jeff, you are right. Mark's behavior has been getting more aggressive, and less like what we encourage and hope for here. He is not representing the ideals of the Python community. We are mostly helpful and nice. :) --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Unacceptable behavior
On Sunday, April 10, 2016 at 10:03:37 AM UTC-4, Chris Angelico wrote: > On Sun, Apr 10, 2016 at 11:54 PM, Jeff Schumaker wrote > > As a new member of this group, I am not sure on how to report unacceptable > > behavior. If this is not the correct way, I apologize. > > > > Please check the following thread: > > > > Find the number of robots needed to walk through the rectangular grid > > > > I believe there was some unnecessary rudeness on the part of one of the > > respondants to the original post > > My guess is you're talking about Mark Lawrence, and yes, I agree; he's > been fairly vitriolic. > > The standard way to report abusive behaviour on mailing lists is to > contact the owner. > > ChrisA No, this was a different poster. And, thanks, Chris, for the email address. I will give it a shot. Jeff -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples
Fillmore writes: > On 04/10/2016 08:31 PM, Ben Finney wrote: > > Can you describe explicitly what that “discontinuation point” is? I'm > > not seeing it. > > Here you go: > > >>> a = '"string1"' > >>> b = '"string1","string2"' > >>> c = '"string1","string2","string3"' > >>> ea = eval(a) > >>> eb = eval(b) > >>> ec = eval(c) > >>> type(ea) ><--- HERE > >>> type(eb) > > >>> type(ec) > While I wait to find out what confuses you about the above, let me ask another question that might get closer to the issue. Would you find the following session confusing? Why? >>> a = "string1" >>> b = "string1", "string2" >>> c = "string1", "string2", "string3" >>> type(a) >>> type(b) >>> type(c) > and mind you, I am not saying that this is wrong. I'm just saying that > it surprised me. If the two examples give you different responses (one surprises you, the other does not), I would really like to know *what the surprise is*. What specifically did you expect, that did not happen? -- \“I knew it was a shocking thing to say, but … no-one has the | `\right to spend their life without being offended.” —Philip | _o__) Pullman, 2010-03-28 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Parens do create a tuple
Chris Angelico writes: > Fair enough. Let's instead say "commas create tuples", which is true > in all cases except the singleton empty tuple. Is that near enough > that we can avoid the detail? It's a fine thing to say, because it's simply true. Commas create tuples. There are some tuples that cannot be created as a literal by comma. That does not make the statement untrue. They are not the *only* thing that creates tuples; parens can also create tuples. So we should avoid false statements on that score. > I'd rather be correct on the one-element case and wrong on the empty > than the other way around. To say “commas create tuples” is to say an unobjectionably true statement about Python syntax. It remains true as one continues to learn Python. To say “parens do not create tuples” is to lay a trap which needs to be de-fused at some point. Better IMO never to lay that trap. -- \ “It’s a great idea to come in unencumbered by dogma but you | `\can’t also be unencumbered by evidence.” —Darren Saunders, | _o__) 2015-12-02 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
On 4/10/2016 8:17 PM, Fillmore wrote: apparently my 'discontinuity' is mappable to the fact that there's no such thing as one-element tuples in Python, and attempts to create one will result in a string (i.e. an object of a different kind!)... Please work through the tutorial before posting wrong information about the basics of Python. >>> t = 1, >>> t (1,) -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Parens do create a tuple
On Mon, Apr 11, 2016 at 11:41 AM, Ben Finney wrote: >> I'd rather be correct on the one-element case and wrong on the empty >> than the other way around. > > To say “commas create tuples” is to say an unobjectionably true > statement about Python syntax. It remains true as one continues to learn > Python. > > To say “parens do not create tuples” is to lay a trap which needs to be > de-fused at some point. Better IMO never to lay that trap. Fair. "Commas create tuples" is correct but incomplete; "parens do not create tuples" is incorrect in a narrow way. Fortunately, technical correctness lines up with the more useful case of helping people understand the one-element case. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
On Mon, 11 Apr 2016 08:51 am, Fillmore wrote: > at which point did the language designers decide to betray the > "path of least surprise" principle and create a 'discontinuity' in the > language? It was March 1996, and I was there. I don't remember the date, I'm afraid. Some of the core Python developers and users had got together in a trendy bar in Los Angeles to discuss the future of the language before the 1.0 release. I don't remember the name of the bar, but you had to go down some steps to get to it from the street (like the one in Cheers), and the barkeeper was this amazingly entertaining black man in his 40s who kept us in stitches with his anecdotes and stories about the various places he had worked before. Anyway, to get back to the question on hand, we were sitting around discussing questions about the language. Remember, this was back in the pre-1.0 days, and there was a *lot* still open for debate: - case sensitive or insensitive? - tabs or spaces or both? - should floats be C singles or doubles? - use '' for strings or ""? among others. I remember Tim Peters, the Timbot, arguing strongly that using doubles was a waste of time, nobody would ever need that much precision for floating point calculations, but the rest of us convinced Guido to ignore him. I don't know who exactly it was that came up with the idea, because I was at the bar ordering a round of drinks, but when I came back I remember Guido's words like it was yesterday: "It's not just enough to betray the principle of least surprise," he said, and banged his fist on the table in emphasis, "any idiot can design a surprising language like C. We have to do it in much more subtle way." Congratulations to Fillmore. It's taken 20 years, but somebody has finally rumbled to the fact that Python is a joke language! Guido made it all up to prank people. I don't think we used the word "troll" back then, but we spent the rest of the afternoon deciding how we could best troll people with a language which *seemed* consistent, with a single, coherent programming model, but was actually a hodge-podge of competing paradigms, inconsistencies and surprises for the unwary. I mean, come on guys, in hindsight it should be obvious. Python is a language that supports three inconsistent language paradigms: - object oriented - functional - procedural I thought that was too obvious and would give the game away, but Guido was right. Programmers aren't that bright. My own contribution to the gag was mutable default function arguments. I'm really proud of that, because I came up with what seems like a perfectly sensible and logical explanation for the behaviour, and a name for it, "early binding", that makes it seem kinda technical and "computer sciency", but we really added it just to be dicks and annoy folks. Fillmore, you should feel very pleased with yourself. All the tens of thousands of Python programmers, and millions of lines of code written in the language, but nobody until now was able to see what you alone had the intelligence and clarity of thought to spot. Well done! -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: QWERTY was not designed to intentionally slow typists down (was: Unicode normalisation [was Re: [beginner] What's wrong?])
Ian Kelly on Sun, 10 Apr 2016 07:43:13 -0600 typed in comp.lang.python the following: >On Sat, Apr 9, 2016 at 9:09 PM, pyotr filipivich wrote: >> ASINTOER are the top eight English letters (not in any order, it >> is just that "A Sin To Err" is easy to remember. > >What's so hard to remember about ETA OIN SHRDLU? Plus that even gives >you the top twelve. :-) Depends on what you're looking for, I suppose. In this case, those eight get encoded differently than the other 20 characters. -- pyotr filipivich The fears of one class of men are not the measure of the rights of another. -- George Bancroft -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]
On Mon, 11 Apr 2016 01:33:10 +0100, MRAB wrote: > There _is_ one exception though: (). It's the empty tuple (a 0-element > tuple). It doesn't have a comma and the parentheses are mandatory. > There's no other way to write it. The other way to write it is: tuple() -- https://mail.python.org/mailman/listinfo/python-list
Re: Parens do create a tuple
On Mon, 11 Apr 2016 11:41 am, Ben Finney wrote: > Chris Angelico writes: > >> Fair enough. Let's instead say "commas create tuples", which is true >> in all cases except the singleton empty tuple. Is that near enough >> that we can avoid the detail? > > It's a fine thing to say, because it's simply true. Commas create > tuples. def func(arg1, arg2, arg3): pass func(1, 2, 3) does not create a tuple (1, 2, 3) anywhere in its execution. So there are commas that don't create a tuple. Including these: import math, sys, time # Python 2 print "This", "is", "not", "a", "tuple." # Also Python 2 try: ... except Exception, err: ... # Any Python del fe, fi, fo, fum Live by pedantry, die by pedantry. :-) > To say “commas create tuples” is to say an unobjectionably true > statement about Python syntax. It remains true as one continues to learn > Python. Really not. > To say “parens do not create tuples” is to lay a trap which needs to be > de-fused at some point. Better IMO never to lay that trap. If one wishes to be both pedantic and correct, as well as long-winded and verbose, one needs to say something like this: In the statement mytuple = (1, 2, 3, 4, 5) it is not the parentheses or round brackets which creates the tuple, it is the commas, so this will work equally well: mytuple = 1, 2, 3, 4, 5 In general, you create tuples in an expression by separating the values with commas, not by surrounding them in parentheses. Parens act to group expressions, so they're useful for ambiguous cases such as nested tuples: mytuple = 1, 2, 3, (10, 20, 30), 5 or to overrule the default precedence rules: lambda x, y: x+1, y+2 # a tuple of (lambda, y+2) lambda x, y: (x+1, y+2) # a function that returns a tuple (x+1, y+2) or just to make the expression look nicer. As a consequence, a single item tuple can be created with a trailing comma, with or without parens: mytuple = 1, mytuple = (1,) The zero-element tuple is a special case. You can't have a comma on its own, so the zero-element tuple has its own special syntax: mytuple = () -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]
On Mon, Apr 11, 2016 at 12:22 PM, Dan Sommers wrote: > On Mon, 11 Apr 2016 01:33:10 +0100, MRAB wrote: > >> There _is_ one exception though: (). It's the empty tuple (a 0-element >> tuple). It doesn't have a comma and the parentheses are mandatory. >> There's no other way to write it. > > The other way to write it is: > > tuple() There are lots of ways to construct an empty tuple, but only one spelling for its literal. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
funny, but it seems to me that you are taking it personally... thank god i even apologized in advance for what was most probably a stupid question.. On 04/10/2016 09:50 PM, Steven D'Aprano wrote: Fillmore, you should feel very pleased with yourself. All the tens of thousands of Python programmers, and millions of lines of code written in the language, but nobody until now was able to see what you alone had the intelligence and clarity of thought to spot. Well done! -- https://mail.python.org/mailman/listinfo/python-list
Re: Parens do create a tuple
On Sun, Apr 10, 2016, at 22:32, Steven D'Aprano wrote: > def func(arg1, arg2, arg3): > pass > > func(1, 2, 3) > > does not create a tuple (1, 2, 3) anywhere in its execution. Well, the second argument to PyObject_Call and function_call is a tuple, which had to come from somewhere. That may be a CPython implementation detail, but what else could __call__'s prototype be but (self, *args, **kwargs)? > Live by pedantry, die by pedantry. -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples
On 04/10/2016 09:36 PM, Ben Finney wrote: If the two examples give you different responses (one surprises you, the other does not), I would really like to know*what the surprise is*. What specifically did you expect, that did not happen? now that I get the role of commas it's not surprising anymore... thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: Parens do create a tuple
On Mon, 11 Apr 2016 11:51 am, Chris Angelico wrote:
> On Mon, Apr 11, 2016 at 11:41 AM, Ben Finney
> wrote:
>>> I'd rather be correct on the one-element case and wrong on the empty
>>> than the other way around.
>>
>> To say “commas create tuples” is to say an unobjectionably true
>> statement about Python syntax. It remains true as one continues to learn
>> Python.
>>
>> To say “parens do not create tuples” is to lay a trap which needs to be
>> de-fused at some point. Better IMO never to lay that trap.
>
> Fair. "Commas create tuples" is correct but incomplete;
It's incorrect as well as incomplete. Not every comma is part of a tuple.
It's not even correct if you limit yourself to expressions, rather than all
Python statements. There are two commas in both the following expressions:
(lambda a, b: a+2*b)(1, 2)
"abc,def".split(",")
and yet no tuples are involved.
Yes, I'm being pedantic. I'm being more pedantic than Ben, and that's a
scary thing :-)
> "parens do not create tuples" is incorrect in a narrow way.
It's only incorrect if you neglect to follow up by saying "with the
exception of the empty tuple". Which makes it incomplete rather than
incorrect. It is *certainly true* that in the expression:
(1, 2, 3, 4)
the parens do not create the tuple, they are only used for grouping. So it
is misleading to say that '"parens do not create tuples" is incorrect'.
> Fortunately, technical
> correctness lines up with the more useful case of helping people
> understand the one-element case.
You know, I've never come across anyone who has failed to understand the
one-element case from an explanation similar to this:
"Parentheses or round brackets don't create tuples, they are used for
grouping. It is the commas, not the brackets, that creates the tuple. The
only exception is the empty tuple, which is written as ()."
*especially* if you give an example of a one-element tuple to reinforce the
lesson.
Short, snappy, memorable statements like "parens don't create tuples" don't
have to be pedantically correct in all the technical details to be useful.
It is allowed to follow them with a more detailed explanation, including
any exceptions to the rule.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Parens do create a tuple
On Mon, Apr 11, 2016 at 12:51 PM, Random832 wrote: > On Sun, Apr 10, 2016, at 22:32, Steven D'Aprano wrote: >> def func(arg1, arg2, arg3): >> pass >> >> func(1, 2, 3) >> >> does not create a tuple (1, 2, 3) anywhere in its execution. > > Well, the second argument to PyObject_Call and function_call is a tuple, > which had to come from somewhere. That may be a CPython implementation > detail, but what else could __call__'s prototype be but (self, *args, > **kwargs)? On the arrivals side, sure, *args. But on the departures side, you can use any sequence, and there's the whole thing of positional and keyword arguments to look at. So ultimately, all you can possibly be seeing is an implementation detail - there's no requirement that a tuple ever be built. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples
Thank you for trying to help, Martin. So:
On 04/10/2016 09:08 PM, Martin A. Brown wrote:
#1: I would not choose eval() except when there is no other
solution. If you don't need eval(), it may save you some
headache in the future, as well, to find an alternate way.
So, can we help you choose something other than eval()?
What are you trying to do with that usage?
so, I do not quite control the format of the file I am trying to parse.
it has the format:
"str1","str2",,"strN" => more stuff
:
in some cases there is just one "str" which is what created me problem.
The first "str1" has special meaning and, at times, it can be alone.
The way I handle this is:
parts = line.strip().split(" => ")
tokens = eval(parts[0])
if type(tokens) == str: #Handle case that there's only one token
columns.add(tokens)
rowTokenString = "__Empty__"
rows.add(rowTokenString)
value = parts[1][:2]
addCell(table, rowTokenString, tokens, value)
else:
columns.add(tokens[0])
rowTokenString = '"'+'","'.join(tokens[1:]) + '"'
rows.add(rowTokenString)
value = parts[1][:2]
addCell(table, rowTokenString, tokens[0],value)
which admittedly is not very elegant. If you have suggestions on how to avoid
the use
of eval() and still achieve the same, I would be delighted to hear them
--
https://mail.python.org/mailman/listinfo/python-list
Re: Moderation and Usenet
hmmm...He made an extremely kind comment a couple of days ago. It called my attention because is the first one ever (coming from) ... Now I'm thinking he might have just been sarcastic. And BTW I myself have given a couple of sour responses every now and then. I guess we all have our bad days or moments. It's just that Mark's are much too often. -- https://mail.python.org/mailman/listinfo/python-list
Re: Unacceptable behavior
On Sunday, April 10, 2016 at 9:33:47 PM UTC-4, Jeff Schumaker wrote: > On Sunday, April 10, 2016 at 10:03:37 AM UTC-4, Chris Angelico wrote: > > On Sun, Apr 10, 2016 at 11:54 PM, Jeff Schumaker wrote > > > > As a new member of this group, I am not sure on how to report > > > unacceptable behavior. If this is not the correct way, I apologize. > > > > > > Please check the following thread: > > > > > > Find the number of robots needed to walk through the rectangular grid > > > > > > I believe there was some unnecessary rudeness on the part of one of the > > > respondants to the original post > > > > My guess is you're talking about Mark Lawrence, and yes, I agree; he's > > been fairly vitriolic. > > > > The standard way to report abusive behaviour on mailing lists is to > > contact the owner. > > > > ChrisA > > No, this was a different poster. And, thanks, Chris, for the email address. I > will give it a shot. > > Jeff I reread the thread. It was Mark. I mixed him up with the Thomas that was the person mentioned at the beginning of this thread. Jeff -- https://mail.python.org/mailman/listinfo/python-list
Re: Moderation and Usenet
On Sunday, April 10, 2016 at 2:01:00 PM UTC-4, Terry Reedy wrote: > On 4/10/2016 1:05 PM, Ethan Furman wrote: > > > If you see offensive posts from him on the Usenet side please do not > > respond. > > Just a reminder for those who, like me, prefer a newsgroup interface for > python-list: gmane.comp.python.general at news.gmane.org mirrors the > moderated output of python-list. (Gmane does the same for 1000s of > tecnhical lists.) I believe that posts submitted from gmane are sent to > the list *first*, and never appear on the gmane mirror until they appear > on the list. Thus one will not see and cannot accidentally respond to a > post that did not appear on the list. One gets the benefits of list > moderation without a flooded mailbox. > > -- > Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
On Mon, 11 Apr 2016 12:48 pm, Fillmore wrote: > > funny, but it seems to me that you are taking it personally... thank god i > even apologized in advance for what was most probably a stupid question.. I hope you did get a laugh out of it, because it wasn't meant to be nasty. But it was meant to get you to think about statements about betraying principles and other inflammatory remarks. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
On 04/10/2016 11:54 PM, Steven D'Aprano wrote: On Mon, 11 Apr 2016 12:48 pm, Fillmore wrote: funny, but it seems to me that you are taking it personally... thank god i even apologized in advance for what was most probably a stupid question.. I hope you did get a laugh out of it, because it wasn't meant to be nasty. But it was meant to get you to think about statements about betraying principles and other inflammatory remarks. I did have a laugh. I don't think I talked about betraying principles. I just mentioned that in my newbie mind, I experienced what I perceived as a discontinuity. My limited understanding of what builds tuples and the (almost always to be avoided) use of eval() were the origin of my perplexities. I'll make sure I approach the temple of pythonistas bare-footed and with greater humility next time -- https://mail.python.org/mailman/listinfo/python-list
Re: Parens do create a tuple
Steven D'Aprano writes: > On Mon, 11 Apr 2016 11:41 am, Ben Finney wrote: > > > Chris Angelico writes: > > > >> Fair enough. Let's instead say "commas create tuples", which is true > >> in all cases except the singleton empty tuple. Is that near enough > >> that we can avoid the detail? > > > > It's a fine thing to say, because it's simply true. Commas create > > tuples. > > […] there are commas that don't create a tuple. Of course. That doesn't make the above statement false. Commas create tuples. Also, commas do other things. -- \ “Faith, n. Belief without evidence in what is told by one who | `\ speaks without knowledge, of things without parallel.” —Ambrose | _o__) Bierce, _The Devil's Dictionary_, 1906 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Parens do create a tuple
On Mon, 11 Apr 2016 12:51 pm, Random832 wrote: > On Sun, Apr 10, 2016, at 22:32, Steven D'Aprano wrote: >> def func(arg1, arg2, arg3): >> pass >> >> func(1, 2, 3) >> >> does not create a tuple (1, 2, 3) anywhere in its execution. > > Well, the second argument to PyObject_Call and function_call is a tuple, > which had to come from somewhere. It didn't come from any Python language feature. It is a purely internal implementation detail. Let me put it this way: a Python expression like 3/x-1 may be parsed into a abstract syntax tree which might look something like this: (OPERATOR, -, (OPERATOR, /, (CONSTANT, 3, None, None), (NAME, 'x', None, None)), (CONSTANT, 1, None, None) ) Should we say that the / and - operators therefore create tuples? I don't think so. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples
Fillmore writes: > On 04/10/2016 09:36 PM, Ben Finney wrote: > > If the two examples give you different responses (one surprises you, the > > other does not), I would really like to know*what the surprise is*. > > What specifically did you expect, that did not happen? > > now that I get the role of commas it's not surprising anymore... So, will we never get your statement of what surprised you between those examples? Clearly there is something of interest here. I'd like to know what the facts of the matter were; “beginner's mind” is a precious resource, not to be squandered. -- \ “My business is to teach my aspirations to conform themselves | `\ to fact, not to try and make facts harmonise with my | _o__) aspirations.“ —Thomas Henry Huxley, 1860-09-23 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples
On 04/11/2016 12:10 AM, Ben Finney wrote: So, will we never get your statement of what surprised you between those examples? Clearly there is something of interest here. I'd like to know what the facts of the matter were; “beginner's mind” is a precious resource, not to be squandered. I thought I had made the point clear with the REPL session below. I had (what seemed to me like) a list of strings getting turned into a tuple. I was surprised that a single string wasn't turned into a single-element tuple. Now that I know that commas create tuples, but lack of commas don't, I'm not surprised anymore. >>> a = '"string1"' >>> b = '"string1","string2"' >>> c = '"string1","string2","string3"' >>> ea = eval(a) >>> eb = eval(b) >>> ec = eval(c) >>> type(ea) >>> type(eb) >>> type(ec) -- https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
On Sun, Apr 10, 2016, at 09:03 PM, Fillmore wrote: > and the (almost always to be avoided) use of eval() FWIW, there's ast.literal_eval which is safe and there's no reason to avoid it. You'll still have to deal with the fact that a single string on a line will return a string while multiples will return a tuple, but how you're doing that (checking the type of the result) is fine. --Stephen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples
On Sun, Apr 10, 2016, at 09:43 PM, Fillmore wrote: > I thought I had made the point clear with the REPL session below. Considering how many people expressed repeatedly they didn't know what was surprising, it wasn't clear at all. In general you need to explain these things with your words: code is good, show code, don't get me wrong, but you need to express your expectations and how the difference between what happened and what you expected surprised you. Both parts, the code and the expression of your thoughts, are really important to getting help around here :) --- Stephen Hansen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples
On Monday, April 11, 2016 at 9:45:20 AM UTC+5:30, Ben Finney wrote: > Clearly there is something of interest here. I'd like to know what the > facts of the matter were; "beginner's mind" is a precious resource, not > to be squandered. That's one sensible statement in a more than usually messed up thread -- https://mail.python.org/mailman/listinfo/python-list
Re: Moderation and Usenet
On 11/04/2016 04:32, Mario R. Osorio wrote: hmmm...He made an extremely kind comment a couple of days ago. It called my attention because is the first one ever (coming from) ... Now I'm thinking he might have just been sarcastic. Give him the benefit of the doubt. And BTW I myself have given a couple of sour responses every now and then. I guess we all have our bad days or moments. It's just that Mark's are much too often. I'm not going to discuss any individual's behaviour here. But to reiterate what I said either earlier in this thread or elsewhere: we're not interested in jumping down someone's throat because they lost their cool for a moment. Or because they once said something in a way which someone else considered too forceful. We're more concerned with the overall effect a series of postings has on other list/newsgroup members. If the list/newsgroup becomes an unpleasant or uncomfortable place because one person is aggressive or rude often enough, then we need to step in. Of course, other members of the list/community are free to do so, as they sometimes do, and point out to a poster where something was unnecessarily blunt or even outright offensive. Thus giving that person the opportunity to retract or apologise if they wish. TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
On Monday, April 11, 2016 at 10:17:13 AM UTC+5:30, Stephen Hansen wrote:
> On Sun, Apr 10, 2016, at 09:03 PM, Fillmore wrote:
> > and the (almost always to be avoided) use of eval()
>
> FWIW, there's ast.literal_eval which is safe and there's no reason to
> avoid it.
Its error reporting is clunky:
>>> from ast import literal_eval as le
>>> le("(1)")
1
>>> le("(1,)")
(1,)
>>> le("1")
1
>>> le("{1:x}")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/ast.py", line 80, in literal_eval
return _convert(node_or_string)
File "/usr/lib/python2.7/ast.py", line 63, in _convert
in zip(node.keys, node.values))
File "/usr/lib/python2.7/ast.py", line 62, in
return dict((_convert(k), _convert(v)) for k, v
File "/usr/lib/python2.7/ast.py", line 79, in _convert
raise ValueError('malformed string')
ValueError: malformed string
> You'll still have to deal with the fact that a single string
> on a line will return a string while multiples will return a tuple, but
> how you're doing that (checking the type of the result) is fine.
Yes...
0 and 1 length tuples are special cases even if we argue till we are blue in
the face
To Fillmore:
Go via lists and the special cases can be obviated:
>>> def br(s): return "[" + s + "]"
>>> s0=""
>>> s1="1"
>>> s2="1,2"
>>> le(br(s0))
[]
>>> le(br(s1))
[1]
>>> le(br(s2))
[1,2]
Then tuplify (if you so wish)
>>> tuple(le(br(s0)))
()
>>> tuple(le(br(s1)))
(1,)
>>> tuple(le(br(s2)))
(1, 2)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Parens do create a tuple
On Mon, Apr 11, 2016, at 00:08, Steven D'Aprano wrote: > Should we say that the / and - operators therefore create tuples? I don't > think so. But I am talking about the tuple that is passed to FunctionType.__call__ at runtime, not a tuple created within some parser stage. -- https://mail.python.org/mailman/listinfo/python-list
Re: one-element tuples
Fillmore writes: > I thought I had made the point clear with the REPL session below. I > had (what seemed to me like) a list of strings getting turned into a > tuple. I was surprised that a single string wasn't turned into a > single-element tuple. Sure. What about the corresponding one from my example: >>> a = "string1" >>> b = "string1", "string2" >>> c = "string1", "string2", "string3" >>> type(a) >>> type(b) >>> type(c) Isn't that just as surprising as the same expressions evaluated with ‘eval’? If not, that's what is confusing me. I can't see how one would be expected, but the other would be surprising. -- \ “It is well to remember that the entire universe, with one | `\ trifling exception, is composed of others.” —John Andrew Holmes | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
On Sun, Apr 10, 2016, at 10:18 PM, Rustom Mody wrote:
> On Monday, April 11, 2016 at 10:17:13 AM UTC+5:30, Stephen Hansen wrote:
> > On Sun, Apr 10, 2016, at 09:03 PM, Fillmore wrote:
> > > and the (almost always to be avoided) use of eval()
> >
> > FWIW, there's ast.literal_eval which is safe and there's no reason to
> > avoid it.
>
> Its error reporting is clunky:
>
> >>> from ast import literal_eval as le
> >>> le("(1)")
> 1
> >>> le("(1,)")
> (1,)
> >>> le("1")
> 1
> >>> le("{1:x}")
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python2.7/ast.py", line 80, in literal_eval
> return _convert(node_or_string)
> File "/usr/lib/python2.7/ast.py", line 63, in _convert
> in zip(node.keys, node.values))
> File "/usr/lib/python2.7/ast.py", line 62, in
> return dict((_convert(k), _convert(v)) for k, v
> File "/usr/lib/python2.7/ast.py", line 79, in _convert
> raise ValueError('malformed string')
> ValueError: malformed string
So? Worst case scenario, someone puts invalid data into the file and it
throws an exception. Could it be more specific? Maybe, but I don't see
why it needs to be. If your input isn't reliably formatted, catch
ValueError and log it and fix (either what wrote it or change how you
read it).
--S
--
https://mail.python.org/mailman/listinfo/python-list
Re: Most probably a stupid question, but I still want to ask
Terry Reedy : > On 4/10/2016 8:17 PM, Fillmore wrote: > >> apparently my 'discontinuity' is mappable to the fact that there's no >> such thing as one-element tuples in Python, and attempts to create >> one will result in a string (i.e. an object of a different kind!)... > > Please work through the tutorial before posting wrong information > about the basics of Python. > t = 1, t > (1,) However, in some languages, one-dimensional vectors/tuples and scalars are treated as equivalent (at least APL and Scheme). Marko -- https://mail.python.org/mailman/listinfo/python-list
