On 17Mar2015 07:36, Steven D'Aprano
wrote:
I must admit that the Linux filesystem layout strikes me as awfully pedantic
and fussy. We're happy to use our home directory as an undifferentiated bag
with no structure, dumping binaries, scripts, documents, data files, config
files and everything el
"Ian Kelly" wrote in message
news:CALwzid=u19ymkfjbhblzi1qh2u9uk4ohy5wco1zo-i3t5at...@mail.gmail.com...
> On Mon, Mar 16, 2015 at 3:01 AM, Frank Millman wrote:
>> C:\>python -m timeit -s "x = range(65, 91); y = (chr(z) for z in x)"
>> "dict(zip(x, y))"
>> 10 loops, best of 3: 11.9 usec per
Warning: I'm only going to answer half of your questions :)
I haven't built any GTK2/3 app in a while, but hopefully others here can
address your other questions (although you might have better luck on the
Python/GTK mailing list when it comes to finding a good tutorial, etc.)
On 17 March 2015 at
On 17/03/2015 04:26, Mario Figueiredo wrote:
On Tue, 17 Mar 2015 14:49:36 +1100, Chris Angelico
wrote:
The simpler you can make those instructions, the easier it is for
people to use your program. So on Windows, that probably means you
have to bundle everything into a big fat .exe or .msi ins
On Tue, 17 Mar 2015 14:42:42 +1100, Ben Finney
wrote:
>Mario Figueiredo writes:
>
>> On Tue, 17 Mar 2015 09:02:38 +1100, Chris Angelico
>> wrote:
>> >
>> >Imagine you need a PostgreSQL database for your Python application -
>> >which also means you need psycopg2, of course. How do you go about
On Tue, 17 Mar 2015 14:49:36 +1100, Chris Angelico
wrote:
>
>The simpler you can make those instructions, the easier it is for
>people to use your program. So on Windows, that probably means you
>have to bundle everything into a big fat .exe or .msi installer, which
>is what leads to DLL Hell whe
On Tue, Mar 17, 2015 at 2:32 PM, Michael Torrie wrote:
> A meta package manager could, in theory, interact with all these systems
> in a unified way. That's certainly one approach.
http://xkcd.com/927/
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
On 17/03/2015 03:32, Michael Torrie wrote:
On 03/16/2015 09:09 PM, Rustom Mody wrote:
OTOH many large-scale systems have sprouted their own packaging-systems
And indeed PIP and CPAN are both forms of package managers to fit the
special needs of those languages' developers. Sometimes that works
On 17/03/2015 03:33, Rustom Mody wrote:
On Tuesday, March 17, 2015 at 8:55:27 AM UTC+5:30, Mark Lawrence wrote:
On 17/03/2015 03:18, Rustom Mody wrote:
On Tuesday, March 17, 2015 at 8:37:25 AM UTC+5:30, Mark Lawrence wrote:
Ok Let me throw out a suggestion:
- potato is a generator
- t
On Tue, Mar 17, 2015 at 2:04 PM, Mario Figueiredo wrote:
> On Tue, 17 Mar 2015 09:02:38 +1100, Chris Angelico
> wrote:
>>
>>Imagine you need a
>>PostgreSQL database for your Python application - which also means you
>>need psycopg2, of course. How do you go about writing installation
>>instructio
Hi all,
Surely you did not look at the package manager and package assortment of
OpenBSD.
It is actually a really good example of how package repository can be both
reliable, easy to use and up to date.
Also, what sort of quality can be expected from a piece of software, whose
author is unable t
Mario Figueiredo writes:
> On Tue, 17 Mar 2015 09:02:38 +1100, Chris Angelico
> wrote:
> >
> >Imagine you need a PostgreSQL database for your Python application -
> >which also means you need psycopg2, of course. How do you go about
> >writing installation instructions?
> >
> >* WINDOWS *
> >1)
On Tuesday, March 17, 2015 at 8:55:27 AM UTC+5:30, Mark Lawrence wrote:
> On 17/03/2015 03:18, Rustom Mody wrote:
> > On Tuesday, March 17, 2015 at 8:37:25 AM UTC+5:30, Mark Lawrence wrote:
> >>>
> >>> Ok Let me throw out a suggestion:
> >>>- potato is a generator
> >>>- tomato is a cursor.
On 03/16/2015 09:04 PM, Mario Figueiredo wrote:
> Are you saying this is a problem for any developer? Especially
> considering this is a one-time operation...
>
> Or maybe you mean lazy developers. But lazy developers are an edge
> case not worth being catered for.
I guess I'm saying the package
On 03/16/2015 09:09 PM, Rustom Mody wrote:
> OTOH many large-scale systems have sprouted their own packaging-systems
And indeed PIP and CPAN are both forms of package managers to fit the
special needs of those languages' developers. Sometimes that works well
with the OS package manager, sometimes
On 17/03/2015 03:18, Rustom Mody wrote:
On Tuesday, March 17, 2015 at 8:37:25 AM UTC+5:30, Mark Lawrence wrote:
Ok Let me throw out a suggestion:
- potato is a generator
- tomato is a cursor.
Acceptable?
No. In Python potato is a generator function, tomato is a generator.
Why complica
On Mon, 16 Mar 2015 19:52:59 -0700 (PDT), Rustom Mody
wrote:
>
>When we go from 'simple-generators' to coroutine-generators there seem to be
>bigger conceptual problems and implementation-gaffes.
>Quite frankly I hardly understand this part.
There's a line after which terminology just becomes pe
On Tuesday, March 17, 2015 at 8:37:25 AM UTC+5:30, Mark Lawrence wrote:
> >
> > Ok Let me throw out a suggestion:
> > - potato is a generator
> > - tomato is a cursor.
> > Acceptable?
> >
>
> No. In Python potato is a generator function, tomato is a generator.
> Why complicate something that
On 17/03/2015 03:05, Michael Torrie wrote:
On 03/16/2015 09:01 PM, Mark Lawrence wrote:
Reading this makes me realise how lucky I am not having to worry about
such issues.
How so?
I don't work due to ill health. I use Python at home on Windows purely
for my own needs which pip now covers,
On Mon, 16 Mar 2015 21:05:03 -0600, Michael Torrie
wrote:
>On 03/16/2015 09:01 PM, Mark Lawrence wrote:
>> Reading this makes me realise how lucky I am not having to worry about
>> such issues.
>
>How so?
Speaking for myself (I know you didn't ask me) what you call the
"dismal world of windows"
On 17/03/2015 02:52, Rustom Mody wrote:
On Monday, March 16, 2015 at 11:50:33 PM UTC+5:30, Mark Lawrence wrote:
On 16/03/2015 14:37, Rustom Mody wrote:
On Monday, March 16, 2015 at 7:57:08 PM UTC+5:30, Mark Lawrence wrote:
On 16/03/2015 14:19, Rustom Mody wrote:
==
Anyways
On Tuesday, March 17, 2015 at 8:10:16 AM UTC+5:30, Ben Finney wrote:
> Thanks for discussing this, Michael.
>
> Michael Torrie writes:
>
> > For developers things are even more grim. Package managers certainly
> > don't work so well for third-party apps like VirtualBox, LibreOffice,
> > Firefox,
On 03/16/2015 08:45 PM, Paul Rubin wrote:
> Chris Angelico writes:
>> On Tue, Mar 17, 2015 at 12:46 PM, Michael Torrie wrote:
>>> But after 20 years, the package manager idea certain has revealed many
>>> shortcomings (in short, it sucks in many ways). ...
>> The hardest part is managing library
On 03/16/2015 09:01 PM, Mark Lawrence wrote:
> Reading this makes me realise how lucky I am not having to worry about
> such issues.
How so?
--
https://mail.python.org/mailman/listinfo/python-list
On Tue, 17 Mar 2015 09:02:38 +1100, Chris Angelico
wrote:
>
>Imagine you need a
>PostgreSQL database for your Python application - which also means you
>need psycopg2, of course. How do you go about writing installation
>instructions?
>
>* WINDOWS *
>1) Install the latest Python 3 from https://www
On 17/03/2015 02:51, Michael Torrie wrote:
On 03/16/2015 08:40 PM, Ben Finney wrote:
Thanks again. This is an important and difficult problem, with competing
forces at play, and I am not at all satisfied with the current state of
packaging.
I agree. Though I like the concept of package manage
On Monday, March 16, 2015 at 11:50:33 PM UTC+5:30, Mark Lawrence wrote:
> On 16/03/2015 14:37, Rustom Mody wrote:
> > On Monday, March 16, 2015 at 7:57:08 PM UTC+5:30, Mark Lawrence wrote:
> >> On 16/03/2015 14:19, Rustom Mody wrote:
> >>> ==
> >>> Anyways...
> >>>
> >>> Yes 15
On 03/16/2015 08:40 PM, Ben Finney wrote:
> Thanks again. This is an important and difficult problem, with competing
> forces at play, and I am not at all satisfied with the current state of
> packaging.
I agree. Though I like the concept of package managers and curated
repos, compared to the dis
Chris Angelico writes:
> On Tue, Mar 17, 2015 at 12:46 PM, Michael Torrie wrote:
>> But after 20 years, the package manager idea certain has revealed many
>> shortcomings (in short, it sucks in many ways). ...
> The hardest part is managing library versions, and that's always going
> to be a prob
Thanks for discussing this, Michael.
Michael Torrie writes:
> For developers things are even more grim. Package managers certainly
> don't work so well for third-party apps like VirtualBox, LibreOffice,
> Firefox, etc. Part of the issue is the multiple moving targets distros
> present in terms o
On 3/16/2015 6:36 PM, Paul Rubin wrote:
Do you know if any of the big Python shops (Google maybe?) are using
Python 3 these days?
LibreOffice uses Python3.3 (or later, don't know) both for internal
scripting and the Python bridge. The FSR unicode that works everywhere
for all codepoints had
On 16/03/2015 22:02, Chris Angelico wrote:
On Tue, Mar 17, 2015 at 4:20 AM, Michael Torrie wrote:
A bit off topic here, but all of this highlights major weaknesses in the
Linux software distribution model. While we Linux nerds like to poke fun
at Windows for not even having a proper package man
On 03/16/2015 02:36 PM, Steven D'Aprano wrote:
> I'm sorry, that makes no sense to me. What does it matter whether Python3 is
> installed to /opt or /usr or /bin or /who/the/feck/cares, so long as your
> application runs when you run it? It's just another dependency, and no more
> than one call to
On 03/16/2015 07:57 PM, Chris Angelico wrote:
> But the solution isn't necessarily to throw out the packaging system.
> All you need is to expand it.
Yes. And of course that's exactly what Poettering is talking about in
his paper. Despite what many think of him, he's a deep thinker and it's
wor
On Tue, Mar 17, 2015 at 12:46 PM, Michael Torrie wrote:
> But after 20 years, the package manager idea certain has revealed many
> shortcomings (in short, it sucks in many ways). Package managers work
> great for setting up the core distro, and also if the packages you need
> are in the repos. D
Since Python 3's adoption is directly impacted by package managers and
curated repos (or lack thereof), I feel justified in continuing this
thread just a bit farther.
On 03/16/2015 04:02 PM, Chris Angelico wrote:
> It most assuredly does NOT suck for end users. Apart from issues of
> naming (grab
Might be just you...
monte@machin-shin:~$ python
Python 3.4.3 |Continuum Analytics, Inc.| (default, Mar 6 2015, 12:03:53)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
>>> tkinter.Tk()
>>>
Just for the
I am not sure it is just me or there is a bug in anaconda. I installed
miniconda from http://conda.pydata.org/miniconda.html, then several
python3.4.3 packages. Then created virtual environment. When I switch to
that environment I can not create tk root window. Here is the traceback:
(venv-3.4
Ian Kelly writes:
> Since the setup code is only run once, the generator expression used
> for y is only iterated over once.
Ah, thanks, I'd been wondering what was going on with Frank's example
but hadn't gotten around to trying to analyze it.
--
https://mail.python.org/mailman/listinfo/python
Steven D'Aprano writes:
>> Why did the changes have to be introduced at all?
> For the same reason any improvement and functional update is
> introduced. To make a better language.
There comes a point when you decide that maintaining existing code is
important enough that you have to stop breakin
On Tue, Mar 17, 2015 at 4:20 AM, Michael Torrie wrote:
> A bit off topic here, but all of this highlights major weaknesses in the
> Linux software distribution model. While we Linux nerds like to poke fun
> at Windows for not even having a proper package manager until Windows
> 10, in fact the pac
On Tue, 17 Mar 2015 04:20 am, Michael Torrie wrote:
> On 03/16/2015 03:13 AM, INADA Naoki wrote:
>> I think application developers should use *only* Python 3 from this year.
>> If we start moving, more library developers will be able to start
>> writing Python 3 only code from next year.
>
> An a
On Tue, Mar 17, 2015 at 2:47 AM, Terry Reedy wrote:
> On 3/16/2015 5:13 AM, INADA Naoki wrote:
>
>> Another experience is porting Flask application in my company from
>> Python 2 to Python 3.
>> It has 26k lines of code and 7.6k lines of tests.
>>
>> Since we don't need to support both of PY2 and
On 16/03/2015 14:37, Rustom Mody wrote:
On Monday, March 16, 2015 at 7:57:08 PM UTC+5:30, Mark Lawrence wrote:
On 16/03/2015 14:19, Rustom Mody wrote:
==
Anyways...
Yes 15 years are past.
I dont expect the def can be revoked now.
[As far as I am concerned its a minor wart]
On 16/03/2015 17:47, Terry Reedy wrote:
On 3/16/2015 5:13 AM, INADA Naoki wrote:
Another experience is porting Flask application in my company from
Python 2 to Python 3.
It has 26k lines of code and 7.6k lines of tests.
Since we don't need to support both of PY2 and PY3, we used 2to3.
2to3 cha
On 3/16/2015 4:31 AM, Paul Rubin wrote:
sure why numpy couldn't go in the stdlib: does it change all that fast?
First there was Numerical Python, the first killer app (though a
library) for Python. Then there was was NumArray by a competing group,
with some not-quite forward compatible chan
On 3/16/2015 5:13 AM, INADA Naoki wrote:
Another experience is porting Flask application in my company from
Python 2 to Python 3.
It has 26k lines of code and 7.6k lines of tests.
Since we don't need to support both of PY2 and PY3, we used 2to3.
2to3 changes 740 lines.
That is less than 3% of
On 03/16/2015 03:13 AM, INADA Naoki wrote:
> I think application developers should use *only* Python 3 from this year.
> If we start moving, more library developers will be able to start
> writing Python 3 only code from next year.
An admirable sentiment, but I'm currently running the latest RHEL
On Mon, Mar 16, 2015 at 10:40 AM, Chris Angelico wrote:
> Looks to me like it's just doing the normal tab-completion of globals,
> rather than having a special case for the 'import' statement. So what
> you're talking about here is a feature request:
>
> When the input begins "import ", please can
On 16.03.2015 17:40, Chris Angelico wrote:
> This is a very plausible feature request, but be aware that it will
> involve a very costly disk search. Figuring out what modules could be
> imported means going through the entire Python module search path,
> enumerating .py (and other) files, and that
On Tue, Mar 17, 2015 at 3:23 AM, candide wrote:
> Python 3.4 provides auto-completion facility within a Python console embedded
> in a command line terminal.
>
>
> But apparently this facility doesn't allow the user to complete with standard
> module name. For instance, editing the following :
>
Python 3.4 provides auto-completion facility within a Python console embedded
in a command line terminal.
But apparently this facility doesn't allow the user to complete with standard
module name. For instance, editing the following :
>>> import ma
and hitting the TAB key doesn't generate
In the past, I've used Visual-C++ for creating dialog-based interfaces for
controlling equipment and displaying data, and I'm looking for something
of similar ease-of-use in Python since that's now my preferred language.
A web-search told me that Glade seems to be most peoples choice (over
QT-Desig
Ian Kelly :
> Or inversely I write a normal utility function that is called from
> coroutines, then later add a "yield from" to it, and now I have to go
> back and revise every place where it's called to make those use "yield
> from" as well.
That is actually quite awkward. Smooth interlocking of
On Mon, Mar 16, 2015 at 3:01 AM, Frank Millman wrote:
> C:\>python -m timeit -s "x = range(65, 91); y = (chr(z) for z in x)"
> "dict(zip(x, y))"
> 10 loops, best of 3: 11.9 usec per loop
>
> C:\>python -m timeit -s "x = range(65, 91); y = (chr(z) for z in x)" "{a: b
> for a, b in zip(x, y)}"
>
On Mon, Mar 16, 2015 at 9:09 AM, Marko Rauhamaa wrote:
> Ian Kelly :
>
>> For generators, the descriptive keyword ("yield") could be buried
>> *anywhere* in that block. One can glance at a generator function and
>> fail to notice that it is a generator function. This is the one that
>> really bugs
Ian Kelly :
> For generators, the descriptive keyword ("yield") could be buried
> *anywhere* in that block. One can glance at a generator function and
> fail to notice that it is a generator function. This is the one that
> really bugs me about reuse of "def", although you are correct that
> this
On Monday, March 16, 2015 at 8:07:22 PM UTC+5:30, Rustom Mody wrote:
> I would gladly do that if it was a minor correction here and there.
> But the problem is a bit deeper even though it can be kept mostly¹ in the docs
> and not modify any syntax/semantics of python.
>
> In particular for:
>
> d
On Mon, Mar 16, 2015 at 7:39 AM, Steven D'Aprano
wrote:
> On Mon, 16 Mar 2015 11:51 pm, Rustom Mody wrote:
>
>> It may help to read this 15 year old thread starting
>> https://mail.python.org/pipermail/python-dev/2001-June/015478.html
>> to see how many python stalwarts dont like the current state
On Mon, Mar 16, 2015 at 8:32 AM, Steven D'Aprano
wrote:
> On Tue, 17 Mar 2015 12:13 am, Marko Rauhamaa wrote:
>
>> If I get an iterator from a black box source, I don't know if I'm
>> allowed/supposed to call close() on it.
>
> In no particular order:
>
> #1
> if hasattr(some_iterator, 'close'):
>
On Monday, March 16, 2015 at 7:57:08 PM UTC+5:30, Mark Lawrence wrote:
> On 16/03/2015 14:19, Rustom Mody wrote:
> > ==
> > Anyways...
> >
> > Yes 15 years are past.
> > I dont expect the def can be revoked now.
> > [As far as I am concerned its a minor wart]
> > But the mess ar
On Tue, 17 Mar 2015 01:35 am, Steven D'Aprano wrote:
> On Tue, 17 Mar 2015 01:19 am, Rustom Mody wrote:
>
>> On Monday, March 16, 2015 at 7:10:03 PM UTC+5:30, Steven D'Aprano wrote:
>>> And of course, from a comp science theoretic perspective,
>>> generators are a kind of subroutine, not a kind o
On Tue, 17 Mar 2015 01:19 am, Rustom Mody wrote:
> On Monday, March 16, 2015 at 7:10:03 PM UTC+5:30, Steven D'Aprano wrote:
>> And of course, from a comp science theoretic perspective,
>> generators are a kind of subroutine, not a kind of type.
>
> You just showed Marko a few posts back, that
> A
On 16/03/2015 14:19, Rustom Mody wrote:
On Monday, March 16, 2015 at 7:10:03 PM UTC+5:30, Steven D'Aprano wrote:
And of course, from a comp science theoretic perspective,
generators are a kind of subroutine, not a kind of type.
You just showed Marko a few posts back, that
A generator is a spec
On Tue, 17 Mar 2015 12:13 am, Marko Rauhamaa wrote:
> If I get an iterator from a black box source, I don't know if I'm
> allowed/supposed to call close() on it.
In no particular order:
#1
if hasattr(some_iterator, 'close'):
some_iterator.close()
#2
close = getattr(some_iterator, 'close',
On Mon, 16 Mar 2015 07:25 pm, Paul Rubin wrote:
> Steven D'Aprano writes:
>> It may, or may not, turn out that in hindsight there might have been
>> better ways to manage the Python2-3 transaction. Let's be honest, a lot
>> of the changes could have been introduced incrementally...
>
> Why did t
On Monday, March 16, 2015 at 7:10:03 PM UTC+5:30, Steven D'Aprano wrote:
> And of course, from a comp science theoretic perspective,
> generators are a kind of subroutine, not a kind of type.
You just showed Marko a few posts back, that
A generator is a special case of an iterator.
And you wrote t
On Mon, 16 Mar 2015 11:51 pm, Rustom Mody wrote:
> It may help to read this 15 year old thread starting
> https://mail.python.org/pipermail/python-dev/2001-June/015478.html
> to see how many python stalwarts dont like the current state of affairs
/s/dont/didn't/
That's a fifteen year old thread,
On Tue, Mar 17, 2015 at 12:05 AM, Steven D'Aprano
wrote:
> Of course, "problem" seems to be relative. PHP culture seems to accept that
> code will break when you do a minor upgrade, and it's no big deal to do a
> search-and-replace and rename your functions. The same thing would be
> considered un
On Mon, Mar 16, 2015 at 7:10 AM, Wolfgang Maier <
wolfgang.ma...@biologie.uni-freiburg.de> wrote:
> On 03/16/2015 12:53 AM, Jason Friedman wrote:
>
>> Hello,
>>
>> This is Python 3.3.2 on Linux.
>> I downloaded Setuptools
>> (https://pypi.python.org/packages/source/s/setuptools/
>> setuptools-14.3
On Mon, Mar 16, 2015 at 10:51 PM, Steven D'Aprano
wrote:
> Chris Angelico wrote:
> Just for the record, it's not just name bindings that make a generator
> behave as a coroutine. E.g.:
>
> py> def co():
> ... print( (yield 1) + 2 )
> ...
> py> a = co()
> py> next(a)
> 1
> py> a.send(98)
> 100
Rustom Mody :
> On Monday, March 16, 2015 at 6:02:48 PM UTC+5:30, Marko Rauhamaa wrote:
>> So what we have now is:
>> (1) plain iterators
>> (2) generator iterators
>> (3) coroutine generator iterators
>
>> (1) and (2) are not unified, which I don't like.
>
> Can you expand on that a bit?
(
On 03/16/2015 12:53 AM, Jason Friedman wrote:
Hello,
This is Python 3.3.2 on Linux.
I downloaded Setuptools
(https://pypi.python.org/packages/source/s/setuptools/setuptools-14.3.tar.gz),
exploded the tarball, and I get:
python setup.py build
Traceback (most recent call last):
File "", line 1
On Mon, 16 Mar 2015 07:31 pm, Paul Rubin wrote:
> Steven D'Aprano writes:
>> The std lib is *batteries* included. If you need a nuclear reactor, you
>> turn to third-party frameworks and libraries like Twisted, Zope, numpy,
>> PLY, etc.
>
> I always thought twisted and zope were monstrosities.
On Monday, March 16, 2015 at 6:02:48 PM UTC+5:30, Marko Rauhamaa wrote:
> So what we have now is:
>
> (1) plain iterators
>
> (2) generator iterators
>
> (3) coroutine generator iterators
>
> (1) and (2) are not unified, which I don't like.
Can you expand on that a bit?
It may help to
On 16.03.2015 13:02, Steven D'Aprano wrote:
> (To be honest, I'm not even sure what the use-case for close() on coroutines
> is in the first place. If you don't want to send any more items into it,
> just don't send any more items into it.)
Just like with file-likes, it is useful to clean up resou
Steven D'Aprano :
> (To be honest, I'm not even sure what the use-case for close() on
> coroutines is in the first place. If you don't want to send any more
> items into it, just don't send any more items into it.)
Without close(), you might leave resources hanging. See PEP 325:
Rejected in
Steven D'Aprano :
> If I .send() into either of the generators above, its a conceptual
> mistake and I should get an error. The fact that I don't is an
> implementation detail, and one which hopefully will be fixed.
So what we have now is:
(1) plain iterators
(2) generator iterators
(3)
Marko Rauhamaa wrote:
> Anyway, calling close() on an iterator can be a necessary requirement
> even in ordinary generator usage. Only now they have to know if the
> underlying iterator was sired by a generator or some other constructor.
Can you give an actual example of that?
(To be honest, I'm
Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Mon, Mar 16, 2015 at 6:12 PM, Marko Rauhamaa wrote:
>>>
>>> I was actually referring to the offered API. It still seems to me like
>>> all iterators could offer close(), send() and throw(). Why? To make all
>>> iterators drop-in replacements of ea
INADA Naoki wrote:
> I think application developers should use only Python 3 from this year.
> If we start moving, more library developers will be able to start
> writing Python 3 only code from next year.
Where this is possible, that is an excellent idea.
Alas, too many (Linux) developers insis
Chris Angelico wrote:
> On Mon, Mar 16, 2015 at 7:36 PM, Steven D'Aprano
> wrote:
>> I expect that the interpreter can tell the difference between
>>
>> yield spam
>>
>> and
>>
>> x = yield spam
>>
>> and only allow send(), close() and throw() on generators which include
>> the second for
On Monday 16 March 2015 02:17:44 Ben Finney wrote:
> Cameron Simpson writes:
> > To quote Graham Dumpleton:
> >
> > For years have seen people make vague grumbles about something not
> > working with mod_wsgi. Not one ever reported bug or described
> > problem.
>
> Hmm. How easy is it for someo
Terry Reedy writes:
> Every change potentially breaks something. (How would you have
> changed 1/2 from 0 to .5 without breaking anything?)
I would not have changed that. It was an ill-advised change that broke
things unnecessarily.
--
https://mail.python.org/mailman/listinfo/python-list
google-api-client has ported from PY2 to PY2/3 recently.
https://github.com/google/google-api-python-client
It has 4000 lines of code and 3200 lines of tests. It is legacy
library. It is indented by 2 spaces
since it was created before Google changes their coding style.
There are two major pull
"Paul Rubin" wrote in message
news:87wq2hfibu@jester.gateway.sonic.net...
> "Frank Millman" writes:
>> dict((a, b) for a, b in zip(x, y))
>> 10 loops, best of 3: 16.1 usec per loop
>> {a: b for a, b in zip(x, y)}"
>> 10 loops, best of 3: 6.38 usec per loop
>
> Hmm, I bet the differe
On Mon, Mar 16, 2015 at 7:36 PM, Steven D'Aprano
wrote:
> I expect that the interpreter can tell the difference between
>
> yield spam
>
> and
>
> x = yield spam
>
> and only allow send(), close() and throw() on generators which include the
> second form. If it can't, then that's a limitat
On 3/16/2015 1:07 AM, Paul Rubin wrote:
I saved a quote from Hacker News a while back (I don't know who the
author is):
"You know why I'm not running python 3?
> Because it doesn't solve a single problem I have.
Quite possibly true.
>It doesn't solve anyone's problems. It
"Terry Reedy" wrote in message
news:me644f$bqj$1...@ger.gmane.org...
>
> Given that list comprehensions are mentioned in the library reference, I
> agree that set and dict comprehensions should be also. Open an issue on
> the tracker pointing to the list entry.
>
>
http://bugs.python.org/iss
On Mon, Mar 16, 2015 at 6:56 PM, Steven D'Aprano
wrote:
> [ a whole lot of stuff that I agree with, and then ... ]
> Module renames could be handled via stub modules. Even Unicode strings could
> hypothetically have been added via a __future__ import.
This part I don't agree with. The problem wit
On Monday 16 March 2015 18:12, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> Marko Rauhamaa wrote:
>>> What features do generator iterators provide on top of generic
>>> iterators?
>>
>> The biggest difference is syntactic. Here's an iterator which returns a
>> never-ending sequence of squared n
"Frank Millman" writes:
> dict((a, b) for a, b in zip(x, y))
> 10 loops, best of 3: 16.1 usec per loop
> {a: b for a, b in zip(x, y)}"
> 10 loops, best of 3: 6.38 usec per loop
Hmm, I bet the difference is from the (a,b) consing all those tuples.
Can you try just dict(zip(x,y)) ?
--
ht
Steven D'Aprano writes:
> The std lib is *batteries* included. If you need a nuclear reactor, you turn
> to third-party frameworks and libraries like Twisted, Zope, numpy, PLY, etc.
I always thought twisted and zope were monstrosities. I've used threads
instead of twisted and various other pos
Steven D'Aprano writes:
> It may, or may not, turn out that in hindsight there might have been better
> ways to manage the Python2-3 transaction. Let's be honest, a lot of the
> changes could have been introduced incrementally...
Why did the changes have to be introduced at all?
> I suspect th
"Paul Rubin" wrote in message
news:87fv95fom0@jester.gateway.sonic.net...
> "Frank Millman" writes:
>> I like dict comprehensions, but I don't use them very often, so when I do
>> I
>> need to look up the format.
>
> I never felt a need for them. Do they generate better code than
>
> d
I believe we push towards accepting new paradigms like python 3. If bugs were
found on libraries used in older context were probably because there wasn't a
need of particular feature. & that is how eventually a software becomes a
legacy. There are times when we might want to re-use this library
On 3/16/2015 2:45 AM, Frank Millman wrote:
"Ian Kelly" wrote in message
news:CALwzidnTUifj_L=DSH_8s+z0L44pxVvdpG1+pfz1Tzm=ect...@mail.gmail.com...
On Sun, Mar 15, 2015 at 11:25 PM, Frank Millman
wrote:
Hi all
I like dict comprehensions, but I don't use them very often, so when I do
I
need t
I believe we push towards accepting new paradigms like python 3. If bugs
were found on libraries used in older context were probably because there
wasn't a need of particular feature. & that is how eventually a software
becomes a legacy. There are times when we might want to re-use this library
or
Hello Guys,
I want to get involved to Python Open source organisation.
I'm an undergrad student & also a full-time dev. My portfolio lives here,
http://kishanthobhani.com.
I would like to get involved in community building or related projects. My
interests groups ranges from education to hu
On Monday 16 March 2015 17:17, Paul Rubin wrote:
> Chris Angelico writes:
>> Ah but it isn't Py3 that's all about being first - it's the latest
>> version of some third-party module.
>
> You know, one of the attractions of Python used to be that it came with
> a powerful enough standard library
1 - 100 of 111 matches
Mail list logo
