On 19 April 2014 12:17, Nick Coghlan wrote:
> That may help clarify the tricky warts and edge cases that can arise when
> moving from the current relatively straightforward and consistent method
> based approach to a more complicated combination of dedicated syntax and
> helper functions.
OK, I'v
Tres Seaver writes:
> Re-adding features to make the strategy that works less painful is
> just acknowledging that fact.
Whether the strategy that works was anticipated is irrelevant, and the
fact that pain *would* be involved was acknowledged all the way back
to the days when "Python 3000" was
On 20Apr2014 20:12, Devin Jeanpierre wrote:
On Sun, Apr 20, 2014 at 8:01 PM, Cameron Simpson wrote:
Me too. I'm against iteritems and friends coming back.
I've been burned in the past with the burden of writing a mapping class with
the many methods such a thing must support; both items() and i
On Sun, Apr 20, 2014 at 8:01 PM, Cameron Simpson wrote:
> On 20Apr2014 14:32, Mark Lawrence wrote:
>>
>> On 20/04/2014 06:31, Ethan Furman wrote:
>>>
>>> Thank you for taking the time to write this up, Nick.
>>>
>>> However, I am -1 on it. One of the allures of Python 3 is the increase
>>> in si
On 20Apr2014 14:32, Mark Lawrence wrote:
On 20/04/2014 06:31, Ethan Furman wrote:
Thank you for taking the time to write this up, Nick.
However, I am -1 on it. One of the allures of Python 3 is the increase
in simplicity and elegance. Restoring cruft does not help with that.
Python 2 idioms
On 4/20/2014 8:25 PM, Ken Chan wrote:
Please send this instead to python-list, where you might find other
raspian users. Pydev is for development of future version of python, not
use of current versions.
--
Terry Jan Reedy
___
Python-Dev mailing lis
On Sun, Apr 20, 2014 at 07:27:08PM +, Kristján Valur Jónsson wrote:
> Well, "for i in x" and other iteration constructs already call "iter
> ()" on their iterable. That's the point. Unless you want to manually
> iterate using "next ()" then the distinction between an iterable and
> an itera
Dear sir,
I am working on WebIOPi where library of python-dev is needed,
so I use "sudo apt-get install python-dev" to install it.
Then returned message of: fail to fetch
http://mirrordirector.raspbian.org/raspbian/ wheezy..
details of error message:
Found Python 2.7.3rc2...
On 18.04.2014 23:03, Ezio Melotti wrote:
> Hi,
>
> On Thu, Apr 17, 2014 at 9:09 PM, Brett Cannon wrote:
>>
>>
>> On Thu Apr 17 2014 at 1:34:23 PM, Jurko Gospodnetić
>> wrote:
>>>
>>>Hi.
>>>
>>> On 14.4.2014. 23:51, Brett Cannon wrote:
Now the question is whether the maintenance cost of
On Sun, Apr 20, 2014 at 2:42 AM, Antoine Pitrou wrote:
> On Sat, 19 Apr 2014 19:02:42 -0700
> David Aguilar wrote:
>>
>> On python3, this still works for normal platforms, but on windows we
>> can't pass a list of byte strings. We have to pass a list of unicode
>> strings.
>
> Windows native APIs
On Thu, Apr 10, 2014 at 2:24 PM, Kushal Das wrote:
> Glyph wants a PSF fund to a usability study on Python. There were a
> few other suggestion on PSF support for tooling development.
+2 on initiative
--
anatoly t.
___
Python-Dev mailing list
Python-D
On Sun, Apr 20, 2014 at 12:27 PM, Kristján Valur Jónsson
wrote:
> Well, "for i in x" and other iteration constructs already call "iter ()" on
> their iterable. That's the point. Unless you want to manually iterate using
> "next ()" then the distinction between an iterable and an iterator is
> acad
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Steven
> On Sat, Apr 19, 2014 at 11:41:35AM +, Kristján Valur Jónsson wrote:
> > Wouldn't "iterkeys" simply be an alias for "keys" and so on?
> > I'm +1 on that.
>
> N
Well, "for i in x" and other iteration constructs already call "iter ()" on
their iterable. That's the point. Unless you want to manually iterate using
"next ()" then the distinction between an iterable and an iterator is academic.
Sent from the æther.
Original message
From:
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Eric Snow
> Sent: 19. apríl 2014 23:15
> To: Barry Warsaw
> Cc: Python-Dev
> Subject: Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items()
> methods
> > I agree.
On Sun, Apr 20, 2014 at 03:07:39PM +, Kristján Valur Jónsson wrote:
> Does one ever use iteritems() et al without first invoking iter() on
> it?
I can't speak for others, but I never invoke iteritems *with* iter().
What would be the point? iteritems is documented as returning an
interato
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/20/2014 07:37 AM, Paul Moore wrote:
> Ultimately, every time we add *any* sort of compatibility feature to
> Python 3 (Unicode literals, bytes interpolation, this) we are sending
> the message that we made a mistake in the design of Python 3.
On 20 Apr 2014 08:14, "Markus Unterwaditzer"
wrote:
>
> Also, that's why people demanded a Python 2.8... so that you don't have to
> pollute Python 3 instead.
It doesn't actually solve the problem in the library and framework cases
though - most folks that are straddling 2/3 want to keep compatib
On 20/04/2014 06:31, Ethan Furman wrote:
Thank you for taking the time to write this up, Nick.
However, I am -1 on it. One of the allures of Python 3 is the increase
in simplicity and elegance. Restoring cruft does not help with that.
Python 2 idioms that get restored to Python 3 must have rea
On Sat, Apr 19, 2014 at 02:25:53PM +1000, Steven D'Aprano wrote:
> In my experience, writing polyglot 2+3 code can be easily handled with a
> few helper functions, which is not the case with unicode string
> literals. (Non-polygot code of course can just use the methods
> directly.) I don't see
On 20 April 2014 03:49, Steven D'Aprano wrote:
> I don't believe that will happen, the line *will* be drawn somewhere,
> before Python 3 dies a death of a thousand cuts. I think that the right
> place to draw the line is *here*, not the next time, or the time after
> that. I think that the decisio
On Sat, 19 Apr 2014 19:02:42 -0700
David Aguilar wrote:
>
> On python3, this still works for normal platforms, but on windows we
> can't pass a list of byte strings. We have to pass a list of unicode
> strings.
Windows native APIs are unicode-based. It is actually necessary to pass
*unicode* str
On Python 3, you can use Unicode on all platforms. On UNIX, there is no
need to encode explicitly.
Victor
Le 20 avr. 2014 04:17, "David Aguilar" a écrit :
> Hi,
>
> I just joined python-dev because I found the need to add some code to
> paper over python3's subprocess API, and I'm wondering whet
23 matches
Mail list logo
