Re: Grouping code by indentation - feature or ******?
"Tim Tyler" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > What do you guys think about Python's grouping of code via indentation? > > Is it good - perhaps because it saves space and eliminates keypresses? > > Or is it bad - perhaps because it makes program flow dependent on > invisible, and unpronouncable characters - and results in more > manual alignment issues by preventing code formatters from managing > indentation? I particularly hate it, but Python has lots of good things which compesate that (another annoying point of Python are slices -- mine are always off by 1). I always write explicitly ends as #end, so that I can reorganice the code easily if necessary. Maybe in the future, when Ruby matures, I could change my mind, but currently Python is still my favourite scripting language (as formerly was Tcl). Javier _______ Javier Bezos| TeX y tipografía jbezos at wanadoo dot es| http://perso.wanadoo.es/jbezos |... CervanTeX (Spanish TUG) | http://www.cervantex.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Grouping code by indentation - feature or ******?
"Jacob Lee" <[EMAIL PROTECTED]> escribió en el mensaje >> things which compesate that (another annoying point >> of Python are slices -- mine are always off by 1). >About slices: Thank you, but I knew the motivations for this odd behaviour, which can be found as well in, for example, MetaFont. However, I disagree. > satisfy some handy properties, the first of which being: > l[:n] + l[n:] = l I don't think l[:5] + l[5:] = l is a handy property and to me is clearly counterintuitive. Further, I don't understand why l[a:b] has a behaviour which does't depend on its own logic but on that of certain constructs containing slices but which aren't the slices themselves. If you have to add or substract 1 in an expression containing slices (or contained in a slice), this belongs to the logic of the expression, not to the slices syntax. MetaFont explains this by saying that the index doesn't refer to a character but to a position between characters, which when traslated to Python would mean: s t r i n g ^ ^ ^ ^ ^ ^ ^ 0 1 2 3 4 5 6 so that [1:2] is "t". Javier ___ Javier Bezos| TeX y tipografía jbezos at wanadoo dot es| http://perso.wanadoo.es/jbezos |... CervanTeX (Spanish TUG) | http://www.cervantex.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Grouping code by indentation - feature or ******?
"Reinhold Birkenfeld" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] >>s t r i n g >> ^ ^ ^ ^ ^ ^ ^ >> 0 1 2 3 4 5 6 >> >> so that [1:2] is "t". > > Incidentally, the Python Tutorial tells us exactly the same... Ah! I've just forgotten that... Javier _______ Javier Bezos | Mem. A multilingual system for LaTeX jbezos at wanadoo dot es | http://mem-latex.sourceforge.net .|: -- http://mail.python.org/mailman/listinfo/python-list
Re: Grouping code by indentation - feature or ******?
"Dennis Lee Bieber" <[EMAIL PROTECTED]> escribió en el mensaje
news:[EMAIL PROTECTED]
> > I don't think l[:5] + l[5:] = l is a handy property
> > and to me is clearly counterintuitive. Further,
[snipped in the reply]
Please, don't remove parts of my post which are
relevant to the discussion. I said:
>Further,
>I don't understand why l[a:b] has a behaviour which
>does't depend on its own logic but on that of certain
>constructs containing slices but which aren't the
>slices themselves.
You give a counterexample:
> st = "This i a string with typo, for example"
> pos = st.find("i ") + 1 # "+ 1" to get the space after "i"
> new_st = st[:pos] + "s" + st[pos:]
but that shows clearly what I was saying --
this tricky syntax means that you have not
to write st[:pos-1] in this particular code
(but you still have to "write" it in your
mind since it forms part of the logic of the
problem). These kind of hacks look perlish
to me.
Of course, the danger of being off-by-one would
be still present, but I would like to note that
if you change the syntax to avoid it in some
expressions you will find problems in another
expressions where otherwise it wouldn't be
present (counting from the end with negatives
values is particularly funny). The same applies
if the first element is 1 instead of 0, for
example.
Then, why not to leave that to the logic of
the problem and not to tricky syntaxes? A pity,
given that Python has a quite straighforward
syntax.
Javier
--
http://mail.python.org/mailman/listinfo/python-list
Re: Grouping code by indentation - feature or ******?
"Myles Strous" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] >>> satisfy some handy properties, the first of which being: >>> l[:n] + l[n:] = l >> >> I don't think l[:5] + l[5:] = l is a handy property >> and to me is clearly counterintuitive. Further, > > It can be quite useful for inserting something into a list (or string), > after finding the position where you wish to insert it. > improvedList = l[:n] + [new stuff] + l[n:] As I answered in another post this is not more useful than writing l[:n-1]. Of course, I'm aware of the case where n=0, but this would require only a bit of extra code (and, after all, I'm just saying that half-open ranges are not a panacea and that I don't like their side effects). > I vaguely remember hearing at one stage that the > sequence[position:position+length] notation is also potentially useful > for indexing into large strings or buffers. Right, to some extent it's useful, but at the cost of introducing tricky syntaxes for very specific cases, like this one, and unexpected off-by-one errors in other cases, which is my point. For example, recently I had to get a value from a list preceded by the two previous values: lst[n-2:n+1] and not the more logical (at last to my eyes) lst[n-2:n]. Instead of giving further examples I would like to cite three cases: 1) You have a starting point (s) and a length (t): lst[s:s+t]. 2) You have an ending point (e) and a length: lst[e-t+1:e+1]. 3) You have a starting point and an ending point: lst[s:e+1]. What's odd is that Python applies the syntax of case 3 to the logic of case 1. While something like lst[s:s+t-1] for the first case could be explained in simple mathematical terms (in other words, it's an integral part of the algorithms), I cannot find a way to explain the e+1 in cases 2 and 3 (and the inconsistency with e-t+1 in case 2 vs. s+t in case 1) except the Python syntax. Javier ___ Javier Bezos | Mem. A multilingual system for LaTeX jbezos at wanadoo dot es | http://mem-latex.sourceforge.net .| -- http://mail.python.org/mailman/listinfo/python-list
Re: Grouping code by indentation - feature or ******?
"Steve Holden" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] [Discussion on Python slices and the off-by-one issue deleted] > While this may be an interesting philosophical (or should that be > philological) discussion, since Python has worked this way for donkey's > years, and since a change would break 30% of the existing codebase, you > clearly can't be advocating change. > > So, what's the point of this thread now? None. In fact, I sent my last post a couple of days ago, so I don't see the point of your message. This thread began when some people thought that I had to be convinced about how wonderful slices are, after I said _incidentally_ I didn't like Python slices (and then I had to explain in turn why I don't like them). Perhaps you should ask those people, not me. Javier _______ Javier Bezos | Mem. A multilingual system for LaTeX jbezos at wanadoo dot es | http://mem-latex.sourceforge.net .| -- http://mail.python.org/mailman/listinfo/python-list
Re: Why Python does *SLICING* the way it does??
<[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > Many people I know ask why Python does slicing the way it does. > > Can anyone /please/ give me a good defense/justification??? > > I'm referring to why mystring[:4] gives me > elements 0, 1, 2 and 3 but *NOT* mystring[4] (5th element). > > Many people don't like idea that 5th element is not invited. > > (BTW, yes I'm aware of the explanation where slicing > is shown to involve slices _between_ elements. This > doesn't explain why this is *best* way to do it.) Recently there was a short (sub)thread about that. One of my messages (against half-open slices) is, for example http://groups-beta.google.com/group/comp.lang.python/msg/5532dd50b57853b1 Javier ___ Javier Bezos| TeX y tipografía jbezos at wanadoo dot es| http://perso.wanadoo.es/jbezos |... CervanTeX (Spanish TUG) | http://www.cervantex.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Why Python does *SLICING* the way it does??
"James Stroud" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > I like this, it works for any integer. > >>> str="asdfjkl;" > >>> i=-400 > >>> print str[:i]+str[i:] > asdfjkl; > >>> i = 65534214 > >>> print str[:i]+str[i:] > asdfjkl; Actually, this has no relation with the half-open slices but with the fact that if i goes beyond the limit of the string then Python, wisely, doesn't raise an error but instead return the string until the end. When people say that half-open slices work for every i, they are tinking in the case i=0. Javier ___ Javier Bezos| TeX y tipografía jbezos at wanadoo dot es| http://perso.wanadoo.es/jbezos |... CervanTeX (Spanish TUG) | http://www.cervantex.org -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3131: Supporting Non-ASCII Identifiers
"René Fleschenberg" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > This is a very weak argument, IMHO. How do you want to use Python > without learning at least enough English to grasp a somewhat decent > understanding of the standard library? By heart. I know a few _very good_ programmers who are unable to understand an English text. Knowing English helps, of course, but is not required at all. Of course, they don't know how to name identifiers in English, but it happens they _cannot_ give them proper Spanish names, either (I'm from Spain). +1 for the PEP, definitely. > But having, for example, things like open() from the stdlib in your code > and then öffnen() as a name for functions/methods written by yourself is > just plain silly. It makes the code inconsistent and ugly without > significantly improving the readability for someone who speaks German > but not English. Agreed. I always use English names (more or less :-)), but this is not the PEP is about. Javier -- http://www.texytipografia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3131: Supporting Non-ASCII Identifiers
"Eric Brunel" <[EMAIL PROTECTED]> escribió en el mensaje > Funny you talk about Japanese, a language I'm a bit familiar with and for > which I actually know some input methods. The thing is, these only work if > you know the transcription to the latin alphabet of the word you want to > type, which closely match its pronunciation. So if you don't know that ?? > ? is pronounced "uriba" for example, you have absolutely no way of > entering the word. Actually, you can draw the character (in XP, at least) entirely or in part and the system shows a list of them with similar shapes. IIRC, there is a similar tool on Macs. Of course, I'm not saying this allows to enter kanji in a easy and fast way, but certainly it's not impossible at all, even if you don't know the pronunciation. Javier --- http://www.texytipografia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3131: Supporting Non-ASCII Identifiers
"Istvan Albert" <[EMAIL PROTECTED]> escribió: > How about debugging this (I wonder will it even make it through?) : > > class 6??? > 6?? = 0 > 6? ?? ?=10 This question is more or less what a Korean who doesn't speak English would ask if he had to debug a program written in English. > (I don't know what it means, just copied over some words > from a japanese news site, A Japanese speaking Korean, it seems. :-) Javier -- http://www.texytipografia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3131: Supporting Non-ASCII Identifiers
>> This question is more or less what a Korean who doesn't >> speak English would ask if he had to debug a program >> written in English. > > Perhaps, but the treatment by your mail/news software plus the > delightful Google Groups of the original text (which seemed intact in > the original, although I don't have the fonts for the content) would > suggest that not just social or cultural issues would be involved. The fact my Outlook changed the text is irrelevant for something related to Python. And just remember how Google mangled the intentation of Python code some time ago. This was a technical issue which has been solved, and no doubt my laziness (I didn't switch to Unicode) won't prevent non-ASCII identifiers be properly showed in general. Javier - http://www.texytipografia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3131: Supporting Non-ASCII Identifiers
<@yahoo.com> escribió: >> > Perhaps, but the treatment by your mail/news software plus the >> > delightful Google Groups of the original text (which seemed intact in >> > the original, although I don't have the fonts for the content) would >> > suggest that not just social or cultural issues would be involved. >> >> The fact my Outlook changed the text is irrelevant >> for something related to Python. > > On the contrary, it cuts to the heart of the problem. There are > hundreds of tools out there that programmers use, and mailing lists > are certainly an incredibly valuable tool--introducing a change that > makes code more likely to be silently mangled seems like a negative. In such a case, the Python indentation should be rejected (quite interesting you removed from my post the part mentioning it). I can promise there are Korean groups and there are no problems at all in using Hangul (the Korean writing). Javier - http://www.texytipografia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Feature Request: Allow changing base of member indices to 1
> Here is a document giving good reasons for indexing to start at
> zero, as in Python.
> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html
> The author has done a bit:
> http://en.wikipedia.org/wiki/Dijkstra
Dijkstra's argument is obsolete, as it is based on
how array length was computed many years ago -- if
we have an array a = b..e, then the lenght of a
is e-b (half open range). Good at low level
programming.
But a quarter of a century after we know concepts
are much better than low level programming and
explicit computations -- if we have an array
a = b..e, then the length of a should be a.length()
(or a.length(b,e)), and it is independent of
arbitrary ranges, index bases, or even steps
(eg, {-4, -2, 0, 2, 4}).
Of course, the index base should be always the
same _by default_ (individual lists could require
another index base, and that's fine). Otherwise
it would a mess, as you said.
Javier
-
http://www.texytipografia.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Feature Request: Allow changing base of member indices to 1
Paddy, >> Dijkstra's argument is obsolete, as it is based on >> how array length was computed many years ago -- if >> we have an array a = b..e, then the lenght of a >> is e-b (half open range). Good at low level >> programming. >> >> But a quarter of a century after we know concepts >> are much better than low level programming and >> explicit computations -- if we have an array >> a = b..e, then the length of a should be a.length() >> (or a.length(b,e)), and it is independent of > Hi Javier, > You seem to have missed out array *indexing* > in your argument, or is array indexing obsolete? Of course, it isn't, but it has evolved over the past 25 years. When Djikstra wrote that, many people (including me) was using a Spectrum--- Now we have OO programming to deal with concepts and a more generic programming. So, to me it's clear his _argument_ is very outdated and cannot be applied directly and withot reservations to modern languages like Python. Javier - http://www.texytipografia.com -- http://mail.python.org/mailman/listinfo/python-list
Connecting Google News
Google News used to fail with the high level functions provided by httplib
and the like. However, I found this piece of code somewhere:
def gopen():
http = httplib.HTTPSConnection('news.google.com')
http.request("GET","/news?ned=es_MX" ,
headers =
{"User-Agent":"Mozilla/5.0 (X11; U; Linux i686; es-MX)
AppleWebKit/532.8 (KHTML, like Gecko) Chrome/4.0.277.0 Safari/532.8",
"Host":'news.google.com',
"Accept": "*/*"})
return http.getresponse()
A few days ago, Google News has been revamped and it doesn't work any more
(2.6/Win7, 2.7/OSX and, with minimal changes, 3.6/Win7), because the page
contents is empty. The code itself doesn't raise any errors. Which is the
proper way to do it now? I must stick to the standard libraries.
The returned headers are:
--
[('Content-Type', 'application/binary'),
('Cache-Control', 'no-cache, no-store, max-age=0, must-revalidate'),
('Pragma', 'no-cache'),
('Expires', 'Mon, 01 Jan 1990 00:00:00 GMT'),
('Date', 'Thu, 13 Jul 2017 16:37:48 GMT'),
('Location', 'https://news.google.com/news/?ned=es_mx&hl=es'),
('Strict-Transport-Security', 'max-age=10886400'),
('P3P',
'CP="This is not a P3P policy! See '
'https://support.google.com/accounts/answer/151657?hl=en for more
info."'),
('Server', 'ESF'),
('Content-Length', '0'),
('X-XSS-Protection', '1; mode=block'),
('X-Frame-Options', 'SAMEORIGIN'),
('X-Content-Type-Options', 'nosniff'),
('Set-Cookie',
'NID=107=qwH7N2hB12zVGfFzrAC2CZZNhrnNAVLEmTvDvuSzzw6mSlta9D2RDZVP9t5gEcq_WJjZQjDSWklJ7LElSnAZnHsiF4CXOwvGDs2tjrXfP41LE-6LafdA86GO3sWYnfWs;Domain=.google.com;Path=/;Expires=Fri,
'
'12-Jan-2018 16:37:48 GMT;HttpOnly'),
('Alt-Svc', 'quic=":443"; ma=2592000; v="39,38,37,36,35"')]
---
`read()` is empty string ('' or b''). `status` is 302. `reason` is `Found`.
Javier
--
https://mail.python.org/mailman/listinfo/python-list
Re: Connecting Google News
Chris,
(Also, please upgrade your Windows box to run Python 2.7.)
It's not /my/ Windows box. I'm allowed to run my script, that's
all. My Windows box is actually that with 3.6.
http = httplib.HTTPSConnection('news.google.com')
http.request("GET","/news?ned=es_MX" ,
('Location', 'https://news.google.com/news/?ned=es_mx&hl=es'),
...
See that Location header? The web server wants to redirect you
somewhere. Your low-level HTTP library does not handle redirects
automatically, so you’d need to take care of that yourself.
I didn't notice the bar just before ?ned ! I don't know how many
times I've compared the URLs without realizing it was added. Silly
me!
Thank you
Javier
--
https://mail.python.org/mailman/listinfo/python-list
Re: Connecting Google News
Peter,
http.request("GET","/news/headlines?ned=es_mx&hl=es" ,
Thank you. It works, too.
Javier
--
https://mail.python.org/mailman/listinfo/python-list
