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 o
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
orde
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
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:python-list-bounces+joseph.lee22590=gmail@python.org] On Behalf
Of Laura Creighton
Sent: Saturday, July 18, 2015 5:16 AM
To:
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 per
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
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 bu
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
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
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 advanc
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:
> retur
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
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
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
> 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 itsel
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 ca
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
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 so
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 re
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
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 re
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 singl
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
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 b
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
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 rel
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
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 performan
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
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
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 I
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
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
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 fra
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
>
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
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,
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
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.
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
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
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 lite
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 report
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 Comput
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 th
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
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. Pytho
47 matches
Mail list logo
