EuroPython 2015: More attendee tips
Some more last-minute news and tips for attendees. Be sure to check our attendee tips page for more information. Bilbao tram service on strike - Just like in Berlin last year, there will be some inconvenience due to strikes in Bilbao. The Bilbao tram service has been on strike since July 15th and it may well last until the end of Summer. The tram services will stop from 11:55 - 14.00 and 17:55 - 20.00 CEST each day and only maintain minimum service at other times. See “Paralizado el servicio de tranvía en Bilbao por huelga de sus trabajadores” for more details (in Spanish): http://www.elmundo.es/pais-vasco/2015/07/15/55a66b6aca47414f298b457e.html We had originally wanted to provide free public transport for attendees, but given the strikes during conference rush hours, we decided to drop this. Note that buses and the metro will still operate as usual. Great weather - You will not only benefit from excellent talks, but also receive lots of Vitamin D in Bilbao. The weather forecast for the week is excellent: *lots of sunshine* and between 28°-30° Celsius: http://www.bbc.com/weather/3128026 So while the tram is on strike, you can walk and get an ice cream instead of a tram ticket. Speaker preparations If you are a speaker, please read the nice guide written by Harry Percival: Tips for speakers https://ep2015.europython.eu/en/speakers/tips/ In particular, please check your talk time. The session chairs will have to make sure that all speakers only use the assigned talk time, so that the tracks don’t run out of sync. There are also some important technical things to prepare your talk at the conference: * *test your notebook* with the projector in the room where you will be holding your talk * make sure you have the right VGA adapters with you * make sure the projector resolution is supported by your notebook It’s best to do all of the above a few hours or a day before your talk. In case of problems, you can then try to find alternative solutions, e.g. borrow someone’s notebook for the talk. Enjoy, -- EuroPython 2015 Team http://ep2015.europython.eu/ http://www.europython-society.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Need assistance
Am 18.07.2015 um 02:40 schrieb Denis McMahon:
On Thu, 16 Jul 2015 19:15:38 -0700, craig.sirna wrote:
The assignment wants us to take a users first, middle and last name in a
single input ( name=('enter your full name: )).
Then we must display the full name rearranged in Last, First Middle
order.
To generate a list of words from a string, split the string up on the
spaces between words. See the split method of strings.
Having a list of words, get a copy of the list in reverse order. See the
reversed function (and maybe the list function).
That won't really help, because the desired order is, with the example
the OP used: Sirna Daniel Craig. So here indexing is necessary, but
indexing of the list elements, not of the characters in the string.
(Necessary is too strong, because this could be done with rpartition.
But I doubt that's the right answer for a beginner course.)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Need assistance
You don't have to index them. You can unpack them into a tuple of first, middle, last Laura (who is trying not to do somebody's homework for them, since I'm not the person who needs to learn this). -- https://mail.python.org/mailman/listinfo/python-list
RE: Need assistance
Hi Laura, There are edge cases where this may fail (and let's see if Craig catches this on his own). Cheers, Joseph -Original Message- From: Python-list [mailto:[email protected]] On Behalf Of Laura Creighton Sent: Saturday, July 18, 2015 5:16 AM To: Sibylle Koczian Cc: [email protected]; [email protected] Subject: Re: Need assistance You don't have to index them. You can unpack them into a tuple of first, middle, last Laura (who is trying not to do somebody's homework for them, since I'm not the person who needs to learn this). -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Need assistance
On 18/07/2015 17:18, Dennis Lee Bieber wrote:
On Sat, 18 Jul 2015 14:16:11 +0200, Laura Creighton
declaimed the following:
You don't have to index them. You can unpack them into a tuple
of first, middle, last
Laura (who is trying not to do somebody's homework for them, since
I'm not the person who needs to learn this).
That only works if the input IS three names (My Birth Certificate reads
"Dennis Lee James Bieber"; and I often used to include my confirmation name
into the thing; I've grown out of that phase but do still sometimes use
dljjb as initials).
This https://www.python.org/dev/peps/pep-3132/ might be handy in this case.
Simple .split() and a {HP calculator} roll operation should get the
desired order.
What is an {HP calculator} roll operation?
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
Re: Need assistance
On 18/07/2015 18:34, Mark Lawrence wrote:
What is an {HP calculator} roll operation?
HP calculators were proper in that they used RPN entry.
i.e. 2 enter 2 + would show 4 instead of 2 + 2 =
Gawd it's so long but ISTR there were 3 stack registers and the display.
So you could press
1 enter
2 enter
3 enter
4
and Z = 1, Y = 2, X = 3 and display = 4. Roll would rotate the entries
through the display register.
ROLL and Z = 2, Y = 3, X = 4 and display = 1
and so on. There was an INV ROLL to go the other way.
The 3 level stack was equivalent to nesting parentheses three times. I
only had a TI-59 as it was half the price of an HP67. The TI had more
memories and program steps and was faster. But it didn't say HP on the
front!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Need assistance
On Sat, Jul 18, 2015 at 2:51 PM, mm0fmf via Python-list
wrote:
> On 18/07/2015 18:34, Mark Lawrence wrote:
>>
>>
>> What is an {HP calculator} roll operation?
>
>
> HP calculators were proper in that they used RPN entry.
>
> i.e. 2 enter 2 + would show 4 instead of 2 + 2 =
>
> Gawd it's so long but ISTR there were 3 stack registers and the display. So
> you could press
>
> 1 enter
> 2 enter
> 3 enter
> 4
>
> and Z = 1, Y = 2, X = 3 and display = 4. Roll would rotate the entries
> through the display register.
>
> ROLL and Z = 2, Y = 3, X = 4 and display = 1
>
> and so on. There was an INV ROLL to go the other way.
>
> The 3 level stack was equivalent to nesting parentheses three times. I only
> had a TI-59 as it was half the price of an HP67. The TI had more memories
> and program steps and was faster. But it didn't say HP on the front!
>
I have an hp35. But to be 'really' cool you have to have an hp35 that
just says hp. Those were the very first ones
--
Joel Goldstick
http://joelgoldstick.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: Need assistance
On 18/07/2015 20:10, Joel Goldstick wrote:
On Sat, Jul 18, 2015 at 2:51 PM, mm0fmf via Python-list
wrote:
On 18/07/2015 18:34, Mark Lawrence wrote:
What is an {HP calculator} roll operation?
HP calculators were proper in that they used RPN entry.
i.e. 2 enter 2 + would show 4 instead of 2 + 2 =
Gawd it's so long but ISTR there were 3 stack registers and the display. So
you could press
1 enter
2 enter
3 enter
4
and Z = 1, Y = 2, X = 3 and display = 4. Roll would rotate the entries
through the display register.
ROLL and Z = 2, Y = 3, X = 4 and display = 1
and so on. There was an INV ROLL to go the other way.
The 3 level stack was equivalent to nesting parentheses three times. I only
had a TI-59 as it was half the price of an HP67. The TI had more memories
and program steps and was faster. But it didn't say HP on the front!
I have an hp35. But to be 'really' cool you have to have an hp35 that
just says hp. Those were the very first ones
I want a real HP16C and have been tempted to buy one from eBay.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Noob in Python. Problem with fairly simple test case
On Friday, July 17, 2015 at 3:39:02 PM UTC-5, Laura Creighton wrote: > I think kivy is doing a very nice job of python-on-the-mobile. > Have you looked? Please do not rant at me, just tell me what you > think. Hello Laura, I'm not sure if you're replying to me (as there is no quoted context) but since you mentioned "rant" i "suppose" that you could be referring be me? I mean, i don't know what gave you the impression that i would rant at anyone? But don't worry dear, i've always self-censored my rants when females are listening -- oops, gonna get some flac for that comment! O:-) First off. I don't remember seeing you here before. So allow me to say that having a female presence in this group is quite refreshing. I hope you continue to participate! Also, I have a lot to say on this subject, and most of what i say below is intended as a "general response", so please don't take any of my words as a personal attack. Thanks. Regarding Kivy I was not aware of this project until you mentioned it. However, i'm skeptical because: (1) it will suffer from latency issues, especially on the mobile platforms, and (2) but even if not, i feel projects like this are only encouraging the stagnation of our evolution towards multi-device compatibility. The road to enlightenment is paved with introspection For the last few decades we have been consumed with the task of bringing multi-platform-ism to every language or API or software or whatever. And this was a noble pursuit indeed! HOWEVER, We are now moving into a new age. Not of cross-platform-ism (where we want to write code *ONCE* and have it run on Linux, Windows, and Mac) but were we want to write code *ONCE* and have it run on a desktop, or a notebook, or a phone, or a watch, or a refrigerator, or even a HUD in our spaceship! I believe it's high time that we move away from religious ideologies codified in "selfish syntaxes" and "selfish interfaces". Because, we seek out these segregating policies just so we can say "hey, we're different", when in reality, we're all the same underneath. For example: printing to stdout is printing to stdout -> no matter what syntax you choose to use. Likewise, iterating over a collection of items, or creating an object that implements the OOP paradigm, or writing a stream into a storage medium -> the fundamentals of these concepts do not change simply by plastering them with selfish identities. Neither is the concept of a GUI window any different if that window was created in Windows, Linux, or Mac. I could provide example after example (ad nauseum) of how we're creating these selfish syntaxes and selfish interface, but i think you get the point. This "need to fulfill" the underlying selfish desires that we, as humans harbor, is preventing us (as programmers, software engineers, hardware producers, and most importantly -> end users) from reaching computing Nirvana. No programmer should ever need to re-write the same code numerous times so that it can run on multiple devices. We, are injecting needless superfluity into this system. And for no more reason than our need to fulfill selfish desires! Why are we *NOT* working together to create a single, linear, and scaleable system of producing software, A system that compiles all the best ideas, and throws the remainder into the refuse bin of history. The only system i've seen that has made *ANY* attempt (as feeble as it may be) is DHTML. But even with it's modern look and feel, it lacks the necessary hooks into the diverse platforms to get any "real work" done. However, utilizing the Trojan horse of "browser ubiquity", and expanding on it, may be much less work than rebuilding the entire system from the ground up (something to ponder...) Most of what we're doing, in the programming language design field, is fighting over who's version of "superficial CSS" is going to be the official version. Our partisan efforts are merely adolescent accessorizing. But we lack the introspective ability to notice the vanity and futility of our efforts. If you want to know why i rant so much, it's because i'm both saddened and angry that we waste our time on these petty battles. When, in fact, we could achieve greatness by working towards a common goal. Utopia's eventually fail Rick! I'm aware of that! I'm aware that "conflict" is the invisible force that breathes life into the cogs of evolution. But your superficial understanding of my proposal is not a failure of my proposal. ON THE CONTRARY! For example. We can *ALL* remember how every cell phone manufacture had their own selfish implementation of a charging
Re: A new module for performing tail-call elimination
Terry Reedy wrote: Problems with branching recursion (multiple recursive calls per call) are rare except for very deep trees and graphs. And if your recursion is branching, tail calls won't help you, except in certain special cases (such as the quicksort example) where you can predict in advance which branches are safe to recurse down. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A new module for performing tail-call elimination
Marko Rauhamaa wrote: At any rate, it demonstrates how the idiom has its place in Python. Perhaps it does, but I think I'd still prefer it to be explicit. The call in Marko's example is not actually a tail call as written. To make it a tail call, a return would need to be added: > return child.setvalue(keyseq, value, offset + 1) To someone reading the code, it's not obvious why the return is there. It looks redundant, and is likely to get removed by someone who thinks it's a mistake. Using a dedicated keyword would make it clear that tail call behaviour is being relied upon, and avoid looking like a spurious return. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A new module for performing tail-call elimination
Marko Rauhamaa wrote: I don't know how recursion makes a difference It makes a difference because people don't expect frames to disappear from tracebacks when they're not consciously doing recursion. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
Antoon Pardon wrote: It seems a bit strange that with the immense value that is given to stack frames, that these wouldn't be available somehow. There was discussion recently about the idea of providing access to the frame of a suspended generator, so that debuggers can inspect the stack of an asyncio task that's not currently running. The same mechanism ought to allow the state of an arbitrary generator to be examined. You'd need to explicitly ask for it, though -- it wouldn't appear in stack traces automatically. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Noob in Python. Problem with fairly simple test case
On Friday, July 17, 2015 at 5:46:01 PM UTC-5, Terry Reedy wrote: > But these relative numbers are, as near as I can tell, > restricted to the english-speaking world, perhaps extended > to the latin-1 based world. Anyone who wants unicode > identifiers must use Python 3 (or a translated Python like > ChinesePython). Anyone seriously working with Unicode > will find 3.3+ more pleasant, if not required (especially > on Windows). I'll have to admit you make a good point here. Although the argument is diminished by observing that Ruby is far more popular in Asia than Python. Python seems to be mainly a Scandinavian, European, and American toy. For the most part anyway. There are always exceptions to any rule. I mean, think about it: who besides Xah Lee has an Asian name here? And it's been years since we've heard from him! O:-D > On Amazon, the first hit for 'Japanese Python' is Dive > into Python 3 (Japanese edition). As near as I can tell, > there is no Japanese edition for the original Dive into > Python (2). As I remember, half the Python books I saw in > Japan *3 years ago* were for Python 3. > > Overall, I suspect that Python 3 penetration is greater in > Asia. I would agree with that assessment, simply because of the Unicode factor. But i don't believe it's a "large audience". And don't get me wrong, i'm not wishing for the numbers to go one way or another. I just simply want to find the truth. > Rick, I only care about porting of public libraries. > Leave your private code in Python 2. Continue writing new > code in Python 2 if you wish. I only object to those who > pressure others to not port to or writes in Python 3. I don't want to pressure anyone in either direction. We, as the greater python community, did not vote to break backwards compatibility, it was dropped on us like an Acme anvil. But what we _can_ choose, is the version that suits our needs best. I have chosen to remain with 2.x. I encourage others to decide for themselves. I don't think pushing 3.x is any less evil than pushing 2.x -- unless the programmer is a python neophyte. In that case, go with 3.x. > If you want to help 2.7 become better, we need people test > and backport patches to 2.7. Since 2.x bugs me as much as > 3.x seems to bug you, I am considering not backporting > until someone volunteers to help. What do you need help with? Can you be more specific? Of course, a few people on this list are under the impression that i cannot write Python code unless Tkinter is imported first. I guess they think Tkinter is some sort of "magic module" that endows it's importer with mad skills (such as those i posses). Or, it could be that they're unwilling to give me any credit. Who knows? I never did participate in office politics anyway. I'm always too busy getting things done! > Now my question for you or anyone else: If the vast > majority of Python programmers are focused on 2.7, why are > volunteers to help fix 2.7 bugs so scarce? Does they all > consider it perfect (or sufficient) as is? Should the core > developers who do not personally use 2.7 stop backporting, > because no one cares if they do? My guess is that most have become disenfranchised. Perhaps some have moved to other languages. Perhaps some are surviving on old code annuities and don't need to work anymore. The number of programmers in this world is very small, and Python programmers represent a very small subset of _that_ small subset. Which means, small numerical losses can result in extreme damage to the "intellectual fortitude" of a community like ours. The days when the Python community could spare a few minds is over, -- as we have entered an era of Pythonic depression. Perhaps one day we'll look back on these tough times and tell fabulously exaggerated stories of how rugged individualism, and a pinch of community spirit, freed the world from the dark clutches of evil. HISTORY IS DEFINED BY THE WINNERS Let me know where i can be of assistance. It's always a great pleasure to make utter fools of my rivals. >:-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Need assistance
> On Jul 18, 2015, at 1:34 PM, Mark Lawrence wrote:
>
>
[byte]
> What is an {HP calculator} roll operation?
>
The original Hewlett Packard “Scientific” calculators (HP-35, 45, 65, etc) that
used Polish notation (operand, operand, operation; with no “=“ sign) had a
stack. That stack itself could be manipulated (e.g., interchange X and Y). One
of the stack manipulation commands was “Roll” which moved the top entry into X
and pushed remaining elements up one. Later versions had both Roll-up and
Roll-down, Roll-down moved the X entry to the top of the stack and dropped the
other elements.
Bill (Who still uses an HP-45 emulator on his iPhone)
> --
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
>
> Mark Lawrence
>
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
Chris Angelico wrote:
Possible alternate syntax:
transfer func[, (arg1, arg2, arg3)[, {'kw1': val1, 'kw2': val2}]]
This makes it very clear that this is NOT accepting an arbitrary
expression, but MUST be used with a single function and its arguments.
Downside: It doesn't look like a function call any more. Upside: It's
easy to parse.
Personally I'd be fine with your initial syntax, but
something else might be needed to get it past Guido.
He didn't like my 'cocall f()' construct in PEP 3152,
which is syntactically isomorphic to 'transfer f()'.
Is there anything that I've missed out in speccing this up? I've a
suspicion that this might turn out to be as complicated as 'yield
from' in all its handling of edge cases.
Presumably it would only work on functions implemented
in Python? It's no use discarding the Python stack frame
unless the C recursion in the ceval loop can be avoided
as well.
Current candidates:
"transfer", "goto", "recurse", and anything else you suggest.
Another possibility is "chain", which I've seen in some
contexts for an sh exec-like operation.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Should non-security 2.7 bugs be fixed?
I asked the following as an off-topic aside in a reply on another thread. I got one response which presented a point I had not considered. I would like more viewpoints from 2.7 users. Background: each x.y.0 release normally gets up to 2 years of bugfixes, until x.(y+1).0 is released. For 2.7, released summer 2010, the bugfix period was initially extended to 5 years, ending about now. At the spring pycon last year, the period was extended to 10 years, with an emphasis on security and build fixed. My general question is what other fixes should be made? Some specific forms of this question are the following. If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce? Does they all consider it perfect (or sufficient) as is? Should the core developers who do not personally use 2.7 stop backporting, because no one cares if they do? -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
Considering CPython is officially accepting performance improvements to 2.7, surely bug fixes are also allowed? I have contributed both performance improvements and bug fixes to 2.7. In my experience, the problem is not the lack of contributors, it's the lack of code reviewers. I think this is something everyone should care about. The really great thing about working on a project like Python is that not only do you help the programmers who use Python, but also the users who use the software that those programmers create. Python 2.7 is important in the software ecosystem of the world. Fixing bugs and making performance improvements can sometimes significantly help the >1B people who use the software written in Python 2.7. -- Devin On Sat, Jul 18, 2015 at 4:36 PM, Terry Reedy wrote: > I asked the following as an off-topic aside in a reply on another thread. I > got one response which presented a point I had not considered. I would like > more viewpoints from 2.7 users. > > Background: each x.y.0 release normally gets up to 2 years of bugfixes, > until x.(y+1).0 is released. For 2.7, released summer 2010, the bugfix > period was initially extended to 5 years, ending about now. At the spring > pycon last year, the period was extended to 10 years, with an emphasis on > security and build fixed. My general question is what other fixes should be > made? Some specific forms of this question are the following. > > If the vast majority of Python programmers are focused on 2.7, why are > volunteers to help fix 2.7 bugs so scarce? > > Does they all consider it perfect (or sufficient) as is? > > Should the core developers who do not personally use 2.7 stop backporting, > because no one cares if they do? > > -- > Terry Jan Reedy > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: A new module for performing tail-call elimination
On 18/07/2015 23:39, Gregory Ewing wrote: Marko Rauhamaa wrote: At any rate, it demonstrates how the idiom has its place in Python. Perhaps it does, but I think I'd still prefer it to be explicit. The call in Marko's example is not actually a tail call as written. To make it a tail call, a return would need to be added: > return child.setvalue(keyseq, value, offset + 1) To someone reading the code, it's not obvious why the return is there. It looks redundant, and is likely to get removed by someone who thinks it's a mistake. A time to use perhaps the most abused part of any programming language, a comment? Using a dedicated keyword would make it clear that tail call behaviour is being relied upon, and avoid looking like a spurious return. +1 -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Need assistance
On 2015-07-18 19:28, William Ray Wing wrote:
On Jul 18, 2015, at 1:34 PM, Mark Lawrence wrote:
[byte]
What is an {HP calculator} roll operation?
The original Hewlett Packard “Scientific” calculators (HP-35, 45, 65, etc) that
used Polish notation (operand, operand, operation; with no “=“ sign) had a
stack.
FYI, Polish Notation is a prefix notation; the operation comes first.
What you're talking about is Reverse Polish Notation, where the
operation comes last.
> That stack itself could be manipulated (e.g., interchange X and Y).
One of the stack manipulation commands was “Roll” which moved the top
entry into X and pushed remaining elements up one. Later versions had
both Roll-up and Roll-down, Roll-down moved the X entry to the top of
the stack and dropped the other elements.
Bill (Who still uses an HP-45 emulator on his iPhone)
--
https://mail.python.org/mailman/listinfo/python-list
Re: A new module for performing tail-call elimination
On 2015-07-18 23:39, Gregory Ewing wrote: Marko Rauhamaa wrote: At any rate, it demonstrates how the idiom has its place in Python. Perhaps it does, but I think I'd still prefer it to be explicit. The call in Marko's example is not actually a tail call as written. To make it a tail call, a return would need to be added: > return child.setvalue(keyseq, value, offset + 1) To someone reading the code, it's not obvious why the return is there. It looks redundant, and is likely to get removed by someone who thinks it's a mistake. Using a dedicated keyword would make it clear that tail call behaviour is being relied upon, and avoid looking like a spurious return. Of the current reserved words, the choice is between 'continue' and 'pass'. How clear is: continue child.setvalue(keyseq, value, offset + 1) ? I think the problem is that it reads like it's something to do with co-routines. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On Sun, Jul 19, 2015 at 9:32 AM, Gregory Ewing
wrote:
> Chris Angelico wrote:
>>
>> Possible alternate syntax:
>>
>> transfer func[, (arg1, arg2, arg3)[, {'kw1': val1, 'kw2': val2}]]
>>
>> This makes it very clear that this is NOT accepting an arbitrary
>> expression, but MUST be used with a single function and its arguments.
>> Downside: It doesn't look like a function call any more. Upside: It's
>> easy to parse.
>
>
> Personally I'd be fine with your initial syntax, but
> something else might be needed to get it past Guido.
> He didn't like my 'cocall f()' construct in PEP 3152,
> which is syntactically isomorphic to 'transfer f()'.
Maybe it should get written up and rejected, then, to be something to
point to any time anyone advocates TCO.
>> Is there anything that I've missed out in speccing this up? I've a
>> suspicion that this might turn out to be as complicated as 'yield
>> from' in all its handling of edge cases.
>
>
> Presumably it would only work on functions implemented
> in Python? It's no use discarding the Python stack frame
> unless the C recursion in the ceval loop can be avoided
> as well.
Hmm. Conceptually, I'd like it to work like this:
def f(x):
return from g(x+1)
x = f(3)
# absolutely identical to
x = g(4)
Is it possible to strip away the current Python stack frame and
replace it with a C stack frame? That would be the most logical, if
it's viable. It'd also mean that other Python implementations are all
looking at things on the same footing. Obviously 'return from' (or
whatever keyword is used) would be valid only from a Python function,
but ideally it could chain to a function written in any form.
>> Current candidates:
>> "transfer", "goto", "recurse", and anything else you suggest.
>
>
> Another possibility is "chain", which I've seen in some
> contexts for an sh exec-like operation.
Hah, that brings me back! "Chaining was attempted from a REXX batch
file". I never understood why typing the name of a batch file would do
a one-way chain/exec rather than a more logical call. Unix has that
much better.
Downside: The name "chain" is highly likely to exist in people's code.
I'm liking "return from", as it's currently illegal, uses existing
keywords, and parallels with "yield from". But as a term for
describing what happens, "chain" works well.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 19/07/2015 00:36, Terry Reedy wrote: I asked the following as an off-topic aside in a reply on another thread. I got one response which presented a point I had not considered. I would like more viewpoints from 2.7 users. Background: each x.y.0 release normally gets up to 2 years of bugfixes, until x.(y+1).0 is released. For 2.7, released summer 2010, the bugfix period was initially extended to 5 years, ending about now. At the spring pycon last year, the period was extended to 10 years, with an emphasis on security and build fixed. My general question is what other fixes should be made? Some specific forms of this question are the following. If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce? Does they all consider it perfect (or sufficient) as is? Should the core developers who do not personally use 2.7 stop backporting, because no one cares if they do? Programmers don't much like doing maintainance work when they're paid to do it, so why would they volunteer to do it? Then even if you do the work to fix *ANY* bug there is no guarantee that it gets committed. The last "Summary of Python tracker Issues" over on python-dev giving 4947 open issues of which 2260 have patches speaks for itself. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sun, Jul 19, 2015 at 9:36 AM, Terry Reedy wrote: > If the vast majority of Python programmers are focused on 2.7, why are > volunteers to help fix 2.7 bugs so scarce? > > Does they all consider it perfect (or sufficient) as is? > > Should the core developers who do not personally use 2.7 stop backporting, > because no one cares if they do? I use Linux on all my computers, but I wouldn't be volunteering to help fix kernel bugs, because I'm not competent to. I also compile C code now and then, but don't offer to fix GCC bugs. There may well be huge numbers of people who write Python code who don't feel they can contribute in that way (whether or not that's strictly true - after all, half of Python is written in Python anyway). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Need assistance
On Sat, 18 Jul 2015 12:35:10 +0200, Sibylle Koczian wrote: > Am 18.07.2015 um 02:40 schrieb Denis McMahon: >> Having a list of words, get a copy of the list in reverse order. See >> the reversed function (and maybe the list function). > That won't really help, because the desired order is, with the example > the OP used: Sirna Daniel Craig. So here indexing is necessary, but > indexing of the list elements, not of the characters in the string. Oh, then it's even easier, yes, it's mainly a case of list indexing. 1) Split the original string into a list of words (string.split() method) 2) create a sublist (s1) of the last element 3) create another sublist (s2) of the first to penultimate elements 4) combine the two sublists 5) use the string.join() method to combine the sublist elements into a single string I think most pythonistas would probably combine steps 2 through 4 in a single line of code, possibly even steps 2 through 5. -- Denis McMahon, [email protected] -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 7/18/2015 8:27 PM, Mark Lawrence wrote: On 19/07/2015 00:36, Terry Reedy wrote: I asked the following as an off-topic aside in a reply on another thread. I got one response which presented a point I had not considered. I would like more viewpoints from 2.7 users. Background: each x.y.0 release normally gets up to 2 years of bugfixes, until x.(y+1).0 is released. For 2.7, released summer 2010, the bugfix period was initially extended to 5 years, ending about now. At the spring pycon last year, the period was extended to 10 years, with an emphasis on security and build fixed. My general question is what other fixes should be made? Some specific forms of this question are the following. If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce? Does they all consider it perfect (or sufficient) as is? Should the core developers who do not personally use 2.7 stop backporting, because no one cares if they do? Programmers don't much like doing maintainance work when they're paid to do it, so why would they volunteer to do it? Right. So I am asking: if a 3.x user volunteers a 3.x patch and a 3.x core developer reviews and edits the patch until it is ready to commit, why should either of them volunteer to do a 2.7 backport that they will not use? I am suggesting that if there are 10x as many 2.7only programmers as 3.xonly programmers, and none of the 2.7 programmers is willing to do the backport *of an already accepted patch*, then maybe it should not be done at all. Then even if you do the work to fix *ANY* bug there is no guarantee that it gets committed. I am discussing the situation where there *is* a near guarantee (if the backport works and does not break anything and has not been so heavily revised as to require a separate review). -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Saturday, July 18, 2015 at 6:37:41 PM UTC-5, Terry Reedy wrote: > If the vast majority of Python programmers are focused on > 2.7, why are volunteers to help fix 2.7 bugs so scarce? Because newer code is always more buggy than older code (when both get significant attention that is). There were quite a few growing pains after Py3 was released. All of this required massive attention. This explains the "hype" for Py3. > Does they all consider it perfect (or sufficient) as is? No, but it works, and it works without bug-fixing old repos. > Should the core developers who do not personally use 2.7 stop > backporting, because no one cares if they do? I think that would be an awful mistake. The last thing you want is rumors spreading that Python is buggy. Even if only Python2 becomes buggy, it's bugginess with affect Python3's reputation. TEAMLEADER: Should we use Python for project X? MEMBER1: I don't know, i heard Python was buggy??? MEMBER2: *AND* the community is fractured! Member3: Which begs the question: Which version is going be around in few years? MEMBER4: And what if his "holiness" decides to break compatibility again? MEMBER5: Perhaps this time he'll make print a method of some new stdout object! TEAMLEADER: Yup. Let's make this easy and go with Ruby. A bad reputation can ruin a language. I would warn against allowing any version of Python to become buggy. Security or otherwise. The future of Python is literally hanging by a thread. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 7/18/2015 7:50 PM, Devin Jeanpierre wrote: Considering CPython is officially accepting performance improvements I was not exactly aware of that. to 2.7, surely bug fixes are also allowed? Of course, allowed. But should they be made, and if so, by who? I have contributed both performance improvements and bug fixes to 2.7. In my experience, the problem is not the lack of contributors, it's the lack of code reviewers. I understand the general problem quite well. But feeling that one would have to do a 2.7 backport after writing, editing, or reviewing a 3.x patch can discourage doing a review in the first place. I am at that point now with respect to Idle patches. I think this is something everyone should care about. The really great thing about working on a project like Python is that not only do you help the programmers who use Python, but also the users who use the software that those programmers create. Python 2.7 is important in the software ecosystem of the world. Fixing bugs and making performance improvements can sometimes significantly help the >1B people who use the software written in Python 2.7. -- Devin On Sat, Jul 18, 2015 at 4:36 PM, Terry Reedy wrote: I asked the following as an off-topic aside in a reply on another thread. I got one response which presented a point I had not considered. I would like more viewpoints from 2.7 users. Background: each x.y.0 release normally gets up to 2 years of bugfixes, until x.(y+1).0 is released. For 2.7, released summer 2010, the bugfix period was initially extended to 5 years, ending about now. At the spring pycon last year, the period was extended to 10 years, with an emphasis on security and build fixed. My general question is what other fixes should be made? Some specific forms of this question are the following. If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce? Does they all consider it perfect (or sufficient) as is? Should the core developers who do not personally use 2.7 stop backporting, because no one cares if they do? -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sat, Jul 18, 2015 at 6:34 PM, Terry Reedy wrote: > On 7/18/2015 8:27 PM, Mark Lawrence wrote: >> On 19/07/2015 00:36, Terry Reedy wrote: >> Programmers don't much like doing maintainance work when they're paid to >> do it, so why would they volunteer to do it? > > Right. So I am asking: if a 3.x user volunteers a 3.x patch and a 3.x core > developer reviews and edits the patch until it is ready to commit, why > should either of them volunteer to do a 2.7 backport that they will not use? Because it helps even more people. The reason people make upstream contributions is so that the world benefits. If you only wanted to help yourself, you'd just patch CPython locally, and not bother contributing anything upstream. > I am suggesting that if there are 10x as many 2.7only programmers as 3.xonly > programmers, and none of the 2.7 programmers is willing to do the backport > *of an already accepted patch*, then maybe it should not be done at all. That just isn't true. I have backported 3.x patches. Other people have backported entire modules. It gets really boring submitting 2.7-specific patches, though, when they aren't accepted, and the committers have such a hostile attitude towards it. I was told by core devs that, instead of fixing bugs in Python 2, I should just rewrite my app in Python 3. It has even been implied that bugs in Python 2 are *good*, because that might help with Python 3 adoption. >> Then even if you do the >> work to fix *ANY* bug there is no guarantee that it gets committed. > > I am discussing the situation where there *is* a near guarantee (if the > backport works and does not break anything and has not been so heavily > revised as to require a separate review). That is not how I have experienced contribution to CPython. No, the patches are *not* guaranteed, and in my experience they are not likely to be accepted. If the issue was closed as fixed before I contributed the backported patch, does anyone even see it? -- Devin -- https://mail.python.org/mailman/listinfo/python-list
Re: Need assistance
On 07/18/2015 03:44 PM, Dennis Lee Bieber wrote: > The new units (HP28, 48, 49, 50, etc.) no longer use the 4-register > stack; the stack is whatever is available in memory. As a result, the Roll > instructions now need an argument for how many stack entries are in play. > > The HP50g has a bit of a sluggish response compared to the 48sx [which > is not equivalent to a 48g]. Might be since the 48sx is still a SATURN > hardware processor. The 50g is an underclocked (for battery life) ARM, > running a SATURN emulator, with the emulator running the RPL/RPN user > interface (there are packages that let one program in SYSRPL [which > bypasses all the user level data checks, so if one knows the data on the > stack is good, one can speed up subsequent operations], SATURN assembly, > AND ARM assembly). > > For $20 or so one can get the HP Prime as an Android app. My list of must-have android apps on my phone and tablet include Droid48, which is an android port of X48. Runs the original firmware and everything. Works very well for me. Of course I also use my real HP 48 on regular basis. The poor thing is 20 years old now but still the most useful calculator I've ever owned. I get lost on calculators without a stack and RPN. Had a debate with m boss over RPN though. He claimed it was just HP's engineers being lazy. For me RPN on a stack is faster for me than a normal calculator because it's closer to how my brain does math--you have to manually do order of operations on paper. Just the other day I learned how to implement custom units on my hp 48 and have them automatically convert to other units. Very cool. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sat, Jul 18, 2015 at 9:13 PM, Terry Reedy wrote: > I understand the general problem quite well. But feeling that one would > have to do a 2.7 backport after writing, editing, or reviewing a 3.x patch > can discourage doing a review in the first place. I am at that point now > with respect to Idle patches. I wonder if it would be worth the significant one-time effort to port IDLE to 2/3, so that future bugfixes/improvements don't require any extra effort than testing them with all versions. -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Saturday, July 18, 2015 at 9:34:20 PM UTC-5, Devin Jeanpierre wrote: > It has even been implied that bugs in Python 2 are *good*, > because that might help with Python 3 adoption. So now we're implementing coercion, Microsoft style? What's next, paid subscriptions to superficial, and backwards incompatible, upgrades every two years? Perhaps after that, we can roll our own security vulnerabilities and inject them into the deprecated source downloads! You'll pay 2x users! You'll pay! And your little repos too! -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On Saturday, July 18, 2015 at 9:18:32 AM UTC+5:30, Serhiy Storchaka wrote: > On 17.07.15 02:46, Chris Angelico wrote: > > Out of the lengthy thread on tail call optimization has come one broad > > theory that might be of interest, so I'm spinning it off into its own > > thread. > > > > The concept is like the Unix exec[vlpe] family of functions: replace > > the current stack frame with a new one. This can be used for explicit > > tail recursion without repeated stack frames, or for a pre-check that > > then disappears out of the stack. Like any other feature, it can be > > misused to make debugging difficult, but among consenting adults, > > hopefully it can be used sensibly. > > I think there is no chance that this proposition will be accepted by > Guido, because it makes debugging harder. I personally thought Chris was being tongue-in-cheek with this suggestion. Taking it more seriously, here are some thoughts. Given: 1. A new keyword is a more deep change than a new optimzation flag 2. The tail-call site is (arguably!) more crucial than the tail-call So why not have a tco decorator such that @tco def foo(...): body will have tail-calls in body optimized? My guess is that someone who knows enough of python's code generator may even be able to do it in pure python; ie with no change to the language in foo.__code__.co_code, replace code of the form "... call; ret..." with "...goto..." -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
Terry Reedy writes: > I am suggesting that if there are 10x as many 2.7only programmers as > 3.xonly programmers, and none of the 2.7 programmers is willing to do > the backport *of an already accepted patch*, then maybe it should not > be done at all. The patch acceptance/approval process is frankly daunting. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday, July 19, 2015 at 8:04:20 AM UTC+5:30, Devin Jeanpierre wrote: > On Sat, Jul 18, 2015 at 6:34 PM, Terry Reedy wrote: > > On 7/18/2015 8:27 PM, Mark Lawrence wrote: > >> On 19/07/2015 00:36, Terry Reedy wrote: > >> Programmers don't much like doing maintainance work when they're paid to > >> do it, so why would they volunteer to do it? > > > > Right. So I am asking: if a 3.x user volunteers a 3.x patch and a 3.x core > > developer reviews and edits the patch until it is ready to commit, why > > should either of them volunteer to do a 2.7 backport that they will not use? > > Because it helps even more people. The reason people make upstream > contributions is so that the world benefits. If you only wanted to > help yourself, you'd just patch CPython locally, and not bother > contributing anything upstream. > > > I am suggesting that if there are 10x as many 2.7only programmers as 3.xonly > > programmers, and none of the 2.7 programmers is willing to do the backport > > *of an already accepted patch*, then maybe it should not be done at all. > > That just isn't true. I have backported 3.x patches. Other people have > backported entire modules. > > It gets really boring submitting 2.7-specific patches, though, when > they aren't accepted, and the committers have such a hostile attitude > towards it. I was told by core devs that, instead of fixing bugs in > Python 2, I should just rewrite my app in Python 3. It has even been > implied that bugs in Python 2 are *good*, because that might help with > Python 3 adoption. > > >> Then even if you do the > >> work to fix *ANY* bug there is no guarantee that it gets committed. > > > > I am discussing the situation where there *is* a near guarantee (if the > > backport works and does not break anything and has not been so heavily > > revised as to require a separate review). > > That is not how I have experienced contribution to CPython. No, the > patches are *not* guaranteed, and in my experience they are not likely > to be accepted. > > If the issue was closed as fixed before I contributed the backported > patch, does anyone even see it? Not to mention actively hostile attitude to discussions that could at the moment be tangential to current CPython. See (and whole thread) https://mail.python.org/pipermail/python-ideas/2015-May/033708.html JFTR: My kids (um... students) have just managed to add devanagari numerals to python. ie we can now do >>> १ + २ 3 [The devanagari equivalent of "12334567890" is "१२३४५६७८९०" And also for those who may not be familiar, devanagari is the script for sanskrit, hindi and a slew of (north) Indian languages ] Regarding this as a fork of python is technically (legalistically) correct but pragmatically ridiculous [unless my students spell as 'Linus Torvalds' or somethin...]. Note that while I dont regard that specific answer as representative of the python-community at large, it is also true that a little help -- even brusque RTFM answers¹ -- would have seen us farther than "If this is what you are up to, get out of here" tl;dr: Not so much a complaint but a indicator that people who could potentially contribute are being prevented from entering -- ¹ For me, RTFM is always welcome if accompanied by which FM -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday, July 19, 2015 at 9:16:08 AM UTC+5:30, Paul Rubin wrote: > Terry Reedy writes: > > I am suggesting that if there are 10x as many 2.7only programmers as > > 3.xonly programmers, and none of the 2.7 programmers is willing to do > > the backport *of an already accepted patch*, then maybe it should not > > be done at all. > > The patch acceptance/approval process is frankly daunting. And it should be. Ive used python for some 15 years now and more than any particular language aspect or feature, the aspect that keeps it in my core tool box is its reliability: Mostly it does what I expect, and allowing a teacher to open the interpreter in a class and hack real-time on coding depends on a certain stability that I personally find very valuable. So I would like to make a distinction between *approvals* being daunting and *discussions* (for patches) being tolerated though (mostly) not being accepted. Of course I accept that this can be unrealistic: Having to email: "Sorry -- Unacceptable" can itself get out of hand if/when the number of well-meaning ignoramus suggestions crosses a threshold -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Saturday, July 18, 2015 at 10:52:51 PM UTC-5, Rustom Mody wrote: > tl;dr: Not so much a complaint but a indicator that people > who could potentially contribute are being prevented from > entering EXACTLY! If this community fails, it won't be due to old members walking out of the back door, no, it will be because the front door was slammed shut and nails were driven into the frame, preventing new members from entering! We are not in a freaking zombie movie people! We're in a freaking community! And communities require doors to be unlocked during business hours. Communities require welcome mats. But mostly of all, communities require hospitality. -- https://mail.python.org/mailman/listinfo/python-list
Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]
On Sun, 19 Jul 2015 01:52 pm, Rustom Mody wrote:
> Not to mention actively hostile attitude to discussions that could at the
> moment be tangential to current CPython. See (and whole thread)
> https://mail.python.org/pipermail/python-ideas/2015-May/033708.html
I stand by my comments there. I have no disagreement with your aim to build
a specialised language for teaching functional programming. I don't believe
that should be Python.
> JFTR: My kids (um... students) have just managed to add devanagari
> numerals to python.
> ie we can now do
>
१ + २
> 3
That is actually quite awesome, and I would support a new feature that set
the numeric characters to a particular script, e.g. Latin, Arabic,
Devanagari, whatever, and printed them in that same script. It seems
unfortunate that १ + २ prints as 3 rather than ३.
Python already, and has for many years, supported non-ASCII digits in string
conversions. This is in Python 2.4:
py> int(u'१२')
12
py> float(u'.१२')
0.12
so the feature goes back a long time.
I think that Python should allow int and float literals using any sequences
of digits from the same language, e.g. 12 or १२ but not १2. One might have
an interpreter hook which displayed ints and floats using non-ASCII digits,
or one might even build that function into the intepreter, e.g. have a
global setting which tells ints and floats what digits to use, e.g.:
sys.setdigits('Devanagari')
I would support this, or something like this, as a language feature. If we
can write Python using Hindi identifiers, why not Hindi numerals?
> Regarding this as a fork of python is technically (legalistically) correct
> but pragmatically ridiculous [unless my students spell as 'Linus Torvalds'
> or somethin...].
There's a grey area between a fork and a local patch. Ever fork begins as a
local patch. It only becomes a fork if you go public with it, give it a new
name, etc. Forks can be highly respected, e.g. Stackless is a fork of
CPython.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sun, 19 Jul 2015 12:33 pm, Devin Jeanpierre wrote: [...] > Because it helps even more people. The reason people make upstream > contributions is so that the world benefits. If you only wanted to > help yourself, you'd just patch CPython locally, and not bother > contributing anything upstream. And have your patch disappear when you upgrade Python? No thanks. [...] > It gets really boring submitting 2.7-specific patches, though, when > they aren't accepted, and the committers have such a hostile attitude > towards it. I was told by core devs that, instead of fixing bugs in > Python 2, I should just rewrite my app in Python 3. Really? Can you point us to this discussion? If you are right, and that was an official pronouncement, then it seems that non-security bug fixes to 2.7 are forbidden. I suspect though that it's not quite that black and white. Perhaps there was some doubt about whether or not the patch in question was fixing a bug or adding a feature (a behavioural change). Or the core dev in question was speaking for themselves, not for all. > It has even been > implied that bugs in Python 2 are *good*, because that might help with > Python 3 adoption. Really? Can you point us to this discussion? As they say on Wikipedia, Citation Needed. I would like to see the context before taking that at face value. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]
On Sun, Jul 19, 2015 at 2:45 PM, Steven D'Aprano wrote:
> I think that Python should allow int and float literals using any sequences
> of digits from the same language, e.g. 12 or १२ but not १2.
I would agree with this. Actually, given that int("१२") works just
fine, I was surprised that it didn't already work in syntax.
> One might have
> an interpreter hook which displayed ints and floats using non-ASCII digits,
> or one might even build that function into the intepreter, e.g. have a
> global setting which tells ints and floats what digits to use, e.g.:
>
> sys.setdigits('Devanagari')
Easiest way to play with this would be a sys.displayhook, I think; I
suspect it would be problematic to change int.__str__ or int.__repr__.
But for interactive work, yep, definitely, it should be easy enough to
make int and float display appropriately.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Integers with leading zeroes
In Python 2, integer literals with leading zeroes are treated as octal, so 09 is a syntax error and 010 is 8. This is confusing to those not raised on C-style octal literals, so in Python 3 leading zeroes are prohibited in int literals. Octal is instead written using the prefix 0o, similar to hex 0x and binary 0b. Consequently Python 3 makes both 09 and 010 a syntax error. However there is one exception: zero itself is allowed any number of leading zeroes, so 0 is a legal way to write zero as a base-10 int literal. Does anyone use that (mis)feature? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Integers with leading zeroes
On Sat, Jul 18, 2015 at 11:39 PM, Steven D'Aprano wrote: > In Python 2, integer literals with leading zeroes are treated as octal, so > 09 is a syntax error and 010 is 8. > > This is confusing to those not raised on C-style octal literals, so in > Python 3 leading zeroes are prohibited in int literals. Octal is instead > written using the prefix 0o, similar to hex 0x and binary 0b. > > Consequently Python 3 makes both 09 and 010 a syntax error. > > However there is one exception: zero itself is allowed any number of leading > zeroes, so 0 is a legal way to write zero as a base-10 int literal. It's obviously a base-8 literal, not a base-10 literal. :-P > Does anyone use that (mis)feature? I don't, but why should it matter? -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
Mark Lawrence writes: > ... >> If the vast majority of Python programmers are focused on 2.7, why are >> volunteers to help fix 2.7 bugs so scarce? I have not done much work related to Python bug fixing. But, I had bad experience with other open source projects: many of my patches (and bug reports) have been ignored over decades. This caused me to change my attitude: I now report bugs (sometimes with patches) and publish a potential solution in a separate package (--> "dm.zopepatches.*", "dm.zodbpatches.*"). This way, affected people can use a solution even if the core developpers don't care. >From my point of view: if you want help with fixing bugs, you must ensure that there is a high probability that those contributions really find their way into the main development lines. As I understand from other messages in this thread, this is also a problem with Python bug fixing. >> Does they all consider it perfect (or sufficient) as is? I have not much blame for Python 2.7. I see a few minor points * "pdb" is quite weak - but I could fix some (but by far not all) aspects in "dm.pdb". * "https" has been weakly handled in earlier versions, but someone has done the Python 3 backport work in an external package before the backport finally arrived in Python 2.7. >> Should the core developers who do not personally use 2.7 stop >> backporting, because no one cares if they do? I am grateful that the above mentioned "https" backport was finally integrated into Python 2.7 -- even though I find it acceptable to use an external package to get it. Thus, there are people who care. Of course, I will not tell core developers that they must do backporting. If they don't more external packages will come into existence which contain (unofficial) backports. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 07/18/2015 04:36 PM, Terry Reedy wrote: I would like more viewpoints from 2.7 users. I read that (incorrectly of course) and just had to ask: How do you intend to extract a viewpoint from that last 7/10 of a user? With apologies, Gary Herron -- Dr. Gary Herron Department of Computer Science DigiPen Institute of Technology (425) 895-4418 -- https://mail.python.org/mailman/listinfo/python-list
Re: A new module for performing tail-call elimination
Gregory Ewing : > Marko Rauhamaa wrote: >> At any rate, it demonstrates how the idiom has its place in Python. > > Perhaps it does, but I think I'd still prefer it to be explicit. Don't get me wrong. The method doesn't depend on tail call elimination. It couldn't because its sibling method has the same recursion depth without the possibility of tail call elimination. I was just showing an example of an iteration expressed idiomatically through a tail call. > The call in Marko's example is not actually a tail call as written. To > make it a tail call, a return would need to be added: > >> return child.setvalue(keyseq, value, offset + 1) Adding the return statement there would be bad because it would suggest to the maintainer of the code that the method has a meaningful return value, which it doesn't. > To someone reading the code, it's not obvious why the return is there. > It looks redundant, and is likely to get removed by someone who thinks > it's a mistake. Exactly. That's why I said also that it is unfortunate for Python to promise to return None implicitly. That stipulation of the language specification is against the de-facto semantics of procedures (your sentence above) and effectively prevents automatic tail call optimizations. > Using a dedicated keyword would make it clear that tail call behaviour > is being relied upon, and avoid looking like a spurious return. A dedicated keyword would indeed work as advertised. However, I'm not too keen on the idea. My position is: Python probably should have made tail call elimination a matter of course, but since it doesn't, oh well. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]
On Sunday, July 19, 2015 at 10:15:37 AM UTC+5:30, Steven D'Aprano wrote:
> On Sun, 19 Jul 2015 01:52 pm, Rustom Mody wrote:
>
> > Not to mention actively hostile attitude to discussions that could at the
> > moment be tangential to current CPython. See (and whole thread)
> > https://mail.python.org/pipermail/python-ideas/2015-May/033708.html
>
> I stand by my comments there. I have no disagreement with your aim to build
> a specialised language for teaching functional programming. I don't believe
> that should be Python.
>
>
> > JFTR: My kids (um... students) have just managed to add devanagari
> > numerals to python.
> > ie we can now do
> >
> १ + २
> > 3
>
> That is actually quite awesome, and I would support a new feature that set
> the numeric characters to a particular script, e.g. Latin, Arabic,
> Devanagari, whatever, and printed them in that same script. It seems
> unfortunate that १ + २ prints as 3 rather than ३.
Thanks. [I am part of this team]
>
> Python already, and has for many years, supported non-ASCII digits in string
> conversions. This is in Python 2.4:
>
> py> int(u'१२')
> 12
> py> float(u'.१२')
> 0.12
>
Very useful to know!
>
> so the feature goes back a long time.
>
> I think that Python should allow int and float literals using any sequences
> of digits from the same language, e.g. 12 or १२ but not १2. One might have
> an interpreter hook which displayed ints and floats using non-ASCII digits,
> or one might even build that function into the intepreter, e.g. have a
> global setting which tells ints and floats what digits to use, e.g.:
>
> sys.setdigits('Devanagari')
>
Currently our code works with UTF-8 byte sequences not unicode codepoints
because thats how tokenizer.c is structured: messy and not generalizable
(easily) to things beyond devanagari. How far this can be improved (without
too deep surgery) is not quite clear yet.
In other words, this generality is nice to talk about but easier said than done
at the moment.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 7/18/2015 11:52 PM, Rustom Mody wrote: Not to mention actively hostile attitude to discussions that could at the moment be tangential to current CPython. See (and whole thread) https://mail.python.org/pipermail/python-ideas/2015-May/033708.html Rustom, I think this is grossly unfair. Python-ideas was started by Guido as a forum for ideas about *future* versions of Python. Your post was about teaching Python,which is something different, as are lost of other Python-related topics. It would have fit either this list or edu-sig better. Your post https://mail.python.org/pipermail/python-ideas/2015-May/033661.html started a thread with nearly 40 responses, which is far more than average. Thou doth protest too much. This https://mail.python.org/pipermail/python-ideas/2015-May/thread.html#33672 is the list for May; there might be a few more in June. To the extent that you were (vaguely) proposing a change to core python itself, by splitting it up into 'teachpacks' (whatever those are) and 'concentric rings', the idea was quickly rejected. It is too specialized, being aimed as one use, and impractically complicated for a mostly volunteer development group. It is the sort of thing one might do with a $5 million grant. Beyond that, the thread veered ogf onto topics that even you labelled off-topic. Yes, we are hostile to prolonged off-topic discussions. They detract from the purpose of the list. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
