Re: Transfer a file to httpserver via POST command from curl
On 2019-12-23 04:24:22 +1100, Chris Angelico wrote: > On Mon, Dec 23, 2019 at 4:20 AM wrote: > > On Wed, 18 Dec 2019 04:52:33 +1100 > > Chris Angelico wrote: > > > > > On Wed, Dec 18, 2019 at 4:45 AM wrote: > > > > BTW, the canonical way to upload files via http is PUT, not POST. > > > > You might want to look into that, but here it is off-topic. > > > > > > Citation needed. > > > > https://tools.ietf.org/html/rfc2616#page-55 > > Yes, that's the definition of PUT - but what does that mean in terms > of file uploads? POST is also valid. Look at its example usages. ACK. Also the first sentence reads: | The PUT method requests that the enclosed entity be stored under the | supplied Request-URI. I understand this to mean that when I send a PUT https://example.com/foo/bar request and receive a 201 or 204 response, a subsequent GET https://example.com/foo/bar will return the body I sent in the PUT request. This is fine if the client can determine the URI of the response. Quite often this not what you want. You want the client to supply the data but let the server determine what to do with it. For example, the server might just number the uploaded files (or use a timestamp or a hash). Or the uploaded file may not be available under any URL at all, but is used to modify other resources and then discarded. In these cases PUT is inappropriate and POST is appropriate. And sometimes the uploaded file is only part of the data (think of HTML forms with a file input field). Then POST is also the correct choice. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | [email protected] |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Transfer a file to httpserver via POST command from curl
On Tue, Dec 24, 2019 at 2:44 AM Peter J. Holzer wrote: > > On 2019-12-23 04:24:22 +1100, Chris Angelico wrote: > > On Mon, Dec 23, 2019 at 4:20 AM wrote: > > > On Wed, 18 Dec 2019 04:52:33 +1100 > > > Chris Angelico wrote: > > > > > > > On Wed, Dec 18, 2019 at 4:45 AM wrote: > > > > > BTW, the canonical way to upload files via http is PUT, not POST. > > > > > You might want to look into that, but here it is off-topic. > > > > > > > > Citation needed. > > > > > > https://tools.ietf.org/html/rfc2616#page-55 > > > > Yes, that's the definition of PUT - but what does that mean in terms > > of file uploads? POST is also valid. Look at its example usages. > > ACK. Also the first sentence reads: > > | The PUT method requests that the enclosed entity be stored under the > | supplied Request-URI. > > I understand this to mean that when I send a > > PUT https://example.com/foo/bar > > request and receive a 201 or 204 response, a subsequent > > GET https://example.com/foo/bar > > will return the body I sent in the PUT request. > > This is fine if the client can determine the URI of the response. > > Quite often this not what you want. You want the client to supply the > data but let the server determine what to do with it. For example, the > server might just number the uploaded files (or use a timestamp or a > hash). Or the uploaded file may not be available under any URL at all, > but is used to modify other resources and then discarded. > > In these cases PUT is inappropriate and POST is appropriate. Your understanding is exactly correct. PUT is appropriate when you already know the URI, POST is appropriate when you want to create a brand new item. The latter is actually far more common. > And sometimes the uploaded file is only part of the data (think of HTML > forms with a file input field). Then POST is also the correct choice. Right, although APIs will often work differently from forms. For instance, the Twitch video uploading protocol starts with a simple POST request with some metadata to create a video, followed by a series of PUT requests to submit each section of the file, and finally a POST to complete the upload. But that only works because all the PUT requests use a predictable URI based on an upload token (created by the initial POST request), which isn't a normal way to build a file upload. (Twitch's video upload can take some pretty ginormous files. You don't want a simple connection glitch to force you to reupload the entire thing from scratch.) But your analysis of POST vs PUT is absolutely correct. File uploads can be done either way, but only use PUT if you know the URI that the object is to live at, which usually means that you can subsequently GET that and retrieve your original file. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Most elegant way to do something N times
> > I encounter with cases like doing a function 6 time with no argument, or > same arguments over and over or doing some structral thing N times and I > dont know how elegant I can express that to the code. > ??? Excuse me, but why you needed to call the same function SIX times? This seems to me not elegant in primis. Can you give us a practical example? On Sun, 22 Dec 2019 at 21:38, Batuhan Taskaya wrote: > I encounter with cases like doing a function 6 time with no argument, or > same arguments over and over or doing some structral thing N times and I > dont know how elegant I can express that to the code. I dont know why but I > dont like this for _ in range(n): do() thing. Any suggestions? > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Most elegant way to do something N times
On Tue, Dec 24, 2019 at 10:45 AM Marco Sulla wrote: > > > > > I encounter with cases like doing a function 6 time with no argument, or > > same arguments over and over or doing some structral thing N times and I > > dont know how elegant I can express that to the code. > > > > ??? Excuse me, but why you needed to call the same function SIX times? This > seems to me not elegant in primis. > > Can you give us a practical example? > File parsing. You read a section header and want to ignore that section, so you ignore the next 15 lines. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Most elegant way to do something N times
It depends on what's elegant, and beauty is in the eye of the beholder.. def recurse(n): print(”do be do be do”) if n>0: recurse(n-1) Regards, Morten søn. 22. des. 2019, 21:37 skrev Batuhan Taskaya : > I encounter with cases like doing a function 6 time with no argument, or > same arguments over and over or doing some structral thing N times and I > dont know how elegant I can express that to the code. I dont know why but I > dont like this for _ in range(n): do() thing. Any suggestions? > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Most elegant way to do something N times
On 24/12/19 1:04 PM, Chris Angelico wrote: On Tue, Dec 24, 2019 at 10:45 AM Marco Sulla wrote: I encounter with cases like doing a function 6 time with no argument, or same arguments over and over or doing some structral thing N times and I dont know how elegant I can express that to the code. ??? Excuse me, but why you needed to call the same function SIX times? This seems to me not elegant in primis. Can you give us a practical example? Taking the top/bottom six from a sorted list of occurrences. eg in Accounts Payable, a clerk might be given the task of 'chasing' the six largest debtors (people who owe us money), as today's work assignment/priority. File parsing. You read a section header and want to ignore that section, so you ignore the next 15 lines. (just to be cheeky to @Chris) Perhaps better as a Finite State Machine, with one state being 'seeking section header'. 1 can we guarantee that the 'magic constant' of 15 will always apply? 2 presumably the total routine will involve more than identifying a single header and skipping (only) that section. -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Most elegant way to do something N times
On Tue, Dec 24, 2019 at 11:34 AM DL Neil via Python-list wrote: > > On 24/12/19 1:04 PM, Chris Angelico wrote: > > File parsing. You read a section header and want to ignore that > > section, so you ignore the next 15 lines. > > (just to be cheeky to @Chris) > > Perhaps better as a Finite State Machine, with one state being 'seeking > section header'. > 1 can we guarantee that the 'magic constant' of 15 will always apply? That number came from the header itself. Okay, so more commonly this kind of thing is a *byte* count, but I have known some that count lines, or entries, or something else that you'd have a function to grab one of. > 2 presumably the total routine will involve more than identifying a > single header and skipping (only) that section. Of course. But after skipping that section (by ignoring X lines), you go do something else. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Lists And Missing Commas
If I do this: foo = [ "bar", "baz" "slop", "crud" ] Python silently accepts that and makes the middle term "bazslop". BUT, if I do this: foo = [ "bar", "baz" 1, "crud" ] or this: foo = [ "bar", 2 1, "crud" ] The interpreter throws a syntax error. This is more of an intellectual curiosity than anything else, but why do strings silently concatenate like that, while all other case blow up with an error. i.e., What is about the language the promotes this behavior. At first blush, it seems inconsistent, but what do I know ... -- https://mail.python.org/mailman/listinfo/python-list
Re: Lists And Missing Commas
On Tuesday, 24 December 2019, Tim Daneliuk wrote: > If I do this: > > foo = [ "bar", "baz" "slop", "crud" ] > > Python silently accepts that and makes the middle term "bazslop". Strings concatinate over line endings so this case is only sensible really. > > BUT, if I do this: > > foo = [ "bar", "baz" 1, "crud" ] > > or this: > > foo = [ "bar", 2 1, "crud" ] > > The interpreter throws a syntax error. > > This is more of an intellectual curiosity than anything else, but why do > strings silently > concatenate like that, while all other case blow up with an error. i.e., > What is about > the language the promotes this behavior. At first blush, it seems > inconsistent, but what > do I know ... > > > > > -- > https://mail.python.org/mailman/listinfo/python-list > -- Independent Software Engineer and amateur Computer Scientist -- https://mail.python.org/mailman/listinfo/python-list
RE: Most elegant way to do something N times
I would like some examples of how one does what is requested in some other programming languages. I doubt there is much need of a shorter way to do anything N times and throw away any return values. Python has many ways to do just about anything. It has some features which suggest a particular way that many accept as pythonic. If there was a need to do something like: repeat_n( times=6, funct=fun, moreargs=whatever) then someone probably would have included it. So, yes, a fairly short and often clear method is: for _ in range(6): ... And others have shown multiple ways to get something similar to what you want. Want real clarity for exactly six times? # Do this six times: whatever() whatever() whatever() whatever() whatever() whatever() Heck, the above may even run faster without loop overhead. Like Marco, it would be interesting to hear actual examples where it makes sense to repeat something the same way N times. Many such examples do have ways to do it trivially. I mean if you want to line up text and need N copies of say an asterisk or space, you can often use something like "*" * 5 And the techniques to repeat some function call N times with the arguments varying each time, can be handled many other ways too including map functions and comprehensions. I am left wondering if this is not about the real world but simply an academic exercise. -Original Message- From: Python-list On Behalf Of Marco Sulla Sent: Monday, December 23, 2019 6:12 PM To: Batuhan Taskaya Cc: Ian Kelly ian.g.kelly-at-gmail.com |[email protected]| Subject: Re: Most elegant way to do something N times > > I encounter with cases like doing a function 6 time with no argument, > or same arguments over and over or doing some structral thing N times > and I dont know how elegant I can express that to the code. > ??? Excuse me, but why you needed to call the same function SIX times? This seems to me not elegant in primis. Can you give us a practical example? On Sun, 22 Dec 2019 at 21:38, Batuhan Taskaya wrote: > I encounter with cases like doing a function 6 time with no argument, > or same arguments over and over or doing some structral thing N times > and I dont know how elegant I can express that to the code. I dont > know why but I dont like this for _ in range(n): do() thing. Any suggestions? > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Lists And Missing Commas
On 24/12/19 1:48 PM, Tim Daneliuk wrote:
If I do this:
foo = [ "bar", "baz" "slop", "crud" ]
Python silently accepts that and makes the middle term "bazslop".
BUT, if I do this:
foo = [ "bar", "baz" 1, "crud" ]
or this:
foo = [ "bar", 2 1, "crud" ]
The interpreter throws a syntax error.
This is more of an intellectual curiosity than anything else, but why do
strings silently
concatenate like that, while all other case blow up with an error. i.e., What
is about
the language the promotes this behavior. At first blush, it seems
inconsistent, but what
do I know ...
Restricting our conversation to numbers/integers and strings,
"concatenate" only ever seems to apply to string objects.
(there are meanings of "concatenate" for matrices, for example)
For fun, try:
help( str ) # and
help( int )
They both mention __add__(self, value, /) In both cases such is defined
as "self+value" - but remember that the "+" operator is "over-loaded".
Thus (and I'm telling you nothing new here) when dealing with strings we
read "+" as "concatenate"; whereas with integers it is plainly "add".
Two quite different operators/operations!
However, your point involves the fact that whereas:
1 + 2 # 3 is *clearly* addition, and
"a" + "b" # "ab" is *clearly* concatenation
"a" "b" # also evaluates to "ab"
and is thus, concatenation without any explicit infix operator! Just one
cotton-picking minute - what's going on here?
The answer to all your dreams (um, maybe...) lies in "The Python
Language Reference" docs, particularly Section 2 "Lexical Analysis" (the
process of taking "tokens" and making sense of how they go-together!).
<<<
2.4.2. String literal concatenation
Multiple adjacent string or bytes literals (delimited by whitespace),
possibly using different quoting conventions, are allowed, and their
meaning is the same as their concatenation. Thus, "hello" 'world' is
equivalent to "helloworld". This feature can be used to reduce the
number of backslashes needed, to split long strings conveniently across
long lines, or even to add comments to parts of strings, for example:
re.compile("[A-Za-z_]" # letter or underscore
"[A-Za-z0-9_]*" # letter, digit or underscore
)
Note that this feature is defined at the syntactical level, but
implemented at compile time. The ‘+’ operator must be used to
concatenate string expressions at run time. Also note that literal
concatenation can use different quoting styles for each component (even
mixing raw strings and triple quoted strings), and formatted string
literals may be concatenated with plain string literals.
>>>
Thus, the adjacency of two literals explicitly only implies
concatenation for strings. There is no equivalent/similar mention for
numbers.
WebRef: https://docs.python.org/3/reference/lexical_analysis.html
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
RE: Most elegant way to do something N times
What others have answered is tangential. Nobody doubts there are places
where you want to repeat something N times. Just to add an example, if you
are parsing something nested by parentheses or perhaps HTML, and you reach a
point where you have seen N opening symbols and start seeing a closing
symbols, you might want to swallow the next N-1 such symbols before moving
on to whatever comes next. Yes, I know that can be more complex.
But in many such cases, people do not just count lines or whatever, but
actively examine each line. This is especially true where it is valid to
have say a comment embedded or other things that make the count uncertain.
Again, what language does something simpler?
Example, in R, is this much better?
for(n_times in 1:6) {print("hi")}
[1] "hi"
[1] "hi"
[1] "hi"
[1] "hi"
[1] "hi"
[1] "hi"
Using R, again, you can make a repeat function that calls your designated
function with a fizxed argument N times:
repetito = function(n, func, arg) {
for (i in 1:n) {
func(arg)
}
}
repetito(6, print, "hi")
[1] "hi"
[1] "hi"
[1] "hi"
[1] "hi"
[1] "hi"
[1] "hi"
Python allows similar ways:
>>> def repetito(n, func, args) :
for _ in range(n):
func(args)
>>> repetito(6, print, "hi")
hi
hi
hi
hi
hi
hi
You can modify these ideas to having no arguments or multiple arguments or
even varying numbers of arguments with varying numbers of positional and
keyword arguments. You need to be careful at times to make sure that the
calls are not evaluated once but each time.
I suspect the request boils down to wanting yet another keyword or two added
to a language that does not need more bloat.
-Original Message-
From: Python-list On
Behalf Of DL Neil via Python-list
Sent: Monday, December 23, 2019 7:27 PM
To: Python
Subject: Re: Most elegant way to do something N times
On 24/12/19 1:04 PM, Chris Angelico wrote:
> On Tue, Dec 24, 2019 at 10:45 AM Marco Sulla wrote:
>>
>>>
>>> I encounter with cases like doing a function 6 time with no
>>> argument, or same arguments over and over or doing some structral
>>> thing N times and I dont know how elegant I can express that to the
code.
>>>
>>
>> ??? Excuse me, but why you needed to call the same function SIX
>> times? This seems to me not elegant in primis.
>>
>> Can you give us a practical example?
Taking the top/bottom six from a sorted list of occurrences.
eg in Accounts Payable, a clerk might be given the task of 'chasing' the six
largest debtors (people who owe us money), as today's work
assignment/priority.
> File parsing. You read a section header and want to ignore that
> section, so you ignore the next 15 lines.
(just to be cheeky to @Chris)
Perhaps better as a Finite State Machine, with one state being 'seeking
section header'.
1 can we guarantee that the 'magic constant' of 15 will always apply?
2 presumably the total routine will involve more than identifying a single
header and skipping (only) that section.
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Lists And Missing Commas
On Tue, Dec 24, 2019 at 12:56 PM DL Neil via Python-list wrote: > However, your point involves the fact that whereas: > > 1 + 2 # 3 is *clearly* addition, and > "a" + "b" # "ab" is *clearly* concatenation > > "a" "b" # also evaluates to "ab" > > and is thus, concatenation without any explicit infix operator! Just one > cotton-picking minute - what's going on here? 1_2# Clearly concatenation. Right? 0_0# Clearly an emoticon Just another cotton-picking minute.. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Lists And Missing Commas
On 24/12/19 3:35 PM, Chris Angelico wrote: On Tue, Dec 24, 2019 at 12:56 PM DL Neil via Python-list wrote: However, your point involves the fact that whereas: 1 + 2 # 3 is *clearly* addition, and "a" + "b" # "ab" is *clearly* concatenation "a" "b" # also evaluates to "ab" and is thus, concatenation without any explicit infix operator! Just one cotton-picking minute - what's going on here? 1_2# Clearly concatenation. Right? 0_0# Clearly an emoticon Just another cotton-picking minute.. Shows what you know: 1_2 is marching orders - and here are yours... -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Lists And Missing Commas
On 12/23/19 7:52 PM, DL Neil wrote: > > WebRef: https://docs.python.org/3/reference/lexical_analysis.html Yep, that explains it, but it still feels non-regular to me. From a pointy headed academic POV, I'd like to see behavior consistent across types. Again ... what do I know? -- https://mail.python.org/mailman/listinfo/python-list
Re: Lists And Missing Commas
On 12/23/19 8:35 PM, Chris Angelico wrote: > On Tue, Dec 24, 2019 at 12:56 PM DL Neil via Python-list > wrote: >> However, your point involves the fact that whereas: >> >> 1 + 2 # 3 is *clearly* addition, and >> "a" + "b" # "ab" is *clearly* concatenation >> >> "a" "b" # also evaluates to "ab" >> >> and is thus, concatenation without any explicit infix operator! Just one >> cotton-picking minute - what's going on here? > > 1_2# Clearly concatenation. Right? > 0_0# Clearly an emoticon > > Just another cotton-picking minute.. > > ChrisA > You are excused and required to do 30 days penance writing .NET. -- https://mail.python.org/mailman/listinfo/python-list
Re: Lists And Missing Commas
On 2019-12-24 6:20 AM, Tim Daneliuk wrote:
On 12/23/19 7:52 PM, DL Neil wrote:
WebRef: https://docs.python.org/3/reference/lexical_analysis.html
Yep, that explains it, but it still feels non-regular to me. From a pointy
headed academic
POV, I'd like to see behavior consistent across types. Again ... what do I know?
From the Zen, 'Practicality beats purity'.
From the docs -
"""
String literals that are part of a single expression and have only
whitespace between them will be implicitly converted to a single string
literal. That is, ("spam " "eggs") == "spam eggs".
"""
I do not see it as 'concatenation', rather as a way of constructing a
single string from a number of smaller chunks. The docs talk about
'whitespace', but I would guess that the use of a single space is
uncommon. More likely is the use of a newline.
I use this from time to time when constructing long string literals -
long_string = (
"this is the first chunk "
"this is the second chunk "
"etc etc"
)
My 0.02c
Frank Millman
--
https://mail.python.org/mailman/listinfo/python-list
Re: Lists And Missing Commas
On 24/12/19 5:20 PM, Tim Daneliuk wrote: On 12/23/19 7:52 PM, DL Neil wrote: WebRef: https://docs.python.org/3/reference/lexical_analysis.html Yep, that explains it, but it still feels non-regular to me. From a pointy headed academic POV, I'd like to see behavior consistent across types. Again ... what do I know? I thought it was 'the boss' who has the "pointy head'? (so that any 'difficult' idea will not land, but simply slide-off to one side or the other?) It is an interesting lateral-thinking enquiry, and we should not simply accept 'stuff', but question how it best works/we can best use it. That said, on the surface, I might agree. Venturing into compiler-writing/lexical analysis, and comparing with other languages, we rapidly realise that it is 'odd' (or special). However, keep reading (the above web.ref) and find the section where "white space" is described. Combine that with the idea/nuisance-value of splitting long strings over multiple lines. Rather than puzzling-over an 'only/special/weird concatenation' allowance, perhaps we should see a 'convenience factor'? -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
