"Frank Millman" writes:
> If you did not know about dict comprehensions, there is nothing to tell you
> that they even exist. I feel that it should be mentioned.
Yeah, the library reference should treat list and dict comprehensions
the same way. I would have thought neither of them belongs in t
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 numbers 1, 4, 9, 16, ...
>
> class Squares:
> def __init__(se
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 each other.
>
> Then, you could also stop wondering what t
in 737966 20150315 161218 MRAB wrote:
>On 2015-03-15 07:26, Dave Farrance wrote:
>> Mark Lawrence wrote:
>>
>>>http://pyfound.blogspot.co.uk/2015/03/bbc-launches-microbit.html may be
>>>of interest to some of you.
>>
>> "Python is one of the three languages that work with the device."
>>
>> That'
On 03/15/2015 03:09 PM, jonas.thornv...@gmail.com wrote:
Den söndag 15 mars 2015 kl. 20:01:36 UTC+1 skrev Paul Rubin:
jonas.thornv...@gmail.com writes:
I though it would be interesting doing comparissons in timing adding
massive digits in different bases. Especially in Python.
Python has buil
On Mon, Mar 16, 2015 at 6:32 PM, Dave Angel wrote:
> Assuming Python 3.x of course. if you're in Python 2, you'd use "long"
> rather than int.
Not sure you need to bother. Even in Py2, you can use the int
constructor to get a long.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Mar 16, 2015 at 1:12 AM, 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 each other.
The purpose of close, send and throw is to impl
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 each other.
>
> [...]
>
> That jus
On 03/16/2015 03:36 AM, Chris Angelico wrote:
On Mon, Mar 16, 2015 at 6:32 PM, Dave Angel wrote:
Assuming Python 3.x of course. if you're in Python 2, you'd use "long"
rather than int.
Not sure you need to bother. Even in Py2, you can use the int
constructor to get a long.
Actually I was
Ian Kelly :
> If on the other hand these methods were to be added to the iterator
> protocol, it would just create unnecessary implementation overhead for
> the 99.99% of non-generator iterators that are under no illusions
> about the fact that they aren't coroutines.
Why should
(x for x in [
On Monday 16 March 2015 16:39, Chris Angelico wrote:
> On Mon, Mar 16, 2015 at 4:07 PM, Paul Rubin
> wrote:
>> Python 2 is by now pretty solid and its users don't feel like beta
>> testers any more. If you're saying using Python 3 by contrast means
>> "being first" and "reporting bugs", that bas
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
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
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
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
"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
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
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
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
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
"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 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
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
"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
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
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
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
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
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
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
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
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)
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
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
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 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 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
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 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
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 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, 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 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 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 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 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 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 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 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 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 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 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
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 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
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)}"
>
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
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
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
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 :
>
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 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 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 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 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 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 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 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 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 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
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
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
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
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
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
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
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 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 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 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
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
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
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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.
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)
1 - 100 of 111 matches
Mail list logo
