Steven D'Aprano writes:
> I'm now at the point where I wish to backport this module to support
> versions of Python back to 3.1 at least and possibly 2.7, and put it
> up on PyPI.
Ned Batchelder has managed something at least as ambitious (supporting
Python versions 2.4 through 3.3), which shoul
Op 24-10-13 06:54, Steven D'Aprano schreef:
> As some of you are aware, I have a module accepted into the standard
> library:
>
> http://docs.python.org/3.4/library/statistics.html
>
> I'm now at the point where I wish to backport this module to support
> versions of Python back to 3.1 at least
Chris The Angel said :
"I won't flame you, but I will disagree with you :)"
good, that's why I'm here ;)
" but there are plenty of things you won't get - and the gap will widen with
very Python release."
Yes I skimmed that laundry list before deciding. I still think I made the right
decision.
On Thu, Oct 24, 2013 at 4:22 PM, Paul Pittlerson wrote:
> msg = cipher.encrypt(txt)
>
'|s\x08\xf2\x12\xde\x8cD\xe7u*'
>
> msg = cipher.encrypt(txt)
>
'\xa1\xed7\xb8h
> # etc
Is this strictly the code you're using? AES is a stream cipher; what
you've effectively done is encrypt the text
On Thu, Oct 24, 2013 at 6:01 PM, Peter Cacioppi
wrote:
> I'd like to think my project (which looks like it is getting funding,
> hooray!) will advance the glory of Pythonistan simply by doing cool stuff
> with 2.7. I'll port it someday (unless it flops, which won't happen, because
> I won't let
On 24.10.2013 09:07, Chris Angelico wrote:
> On Thu, Oct 24, 2013 at 4:22 PM, Paul Pittlerson
> wrote:
>> msg = cipher.encrypt(txt)
>>
> '|s\x08\xf2\x12\xde\x8cD\xe7u*'
>>
>> msg = cipher.encrypt(txt)
>>
> '\xa1\xed7\xb8h>
>> # etc
>
AES is a stream cipher;
No, it is definitely not! It'
On 24.10.2013 07:22, Paul Pittlerson wrote:
> What am I doing wrong?
You're not reinitializing the internal state of the crypto engine. When
you recreate "cipher" with the same IV every time, it will work.
Best regards,
Joe
--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindes
On 10/23/2013 09:57 PM, Peter Cacioppi wrote:
Moreover, you get a lot of the good stuff with 2.7.
And the "good stuff" in 2.7 makes it easier to take that last step to 3.x when
the time comes to do so.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 24.10.2013 09:33, Johannes Bauer wrote:
> On 24.10.2013 07:22, Paul Pittlerson wrote:
>
>> What am I doing wrong?
>
> You're not reinitializing the internal state of the crypto engine. When
> you recreate "cipher" with the same IV every time, it will work.
Code that works:
#!/usr/bin/python3
On Thu, Oct 24, 2013 at 6:30 PM, Johannes Bauer wrote:
> On 24.10.2013 09:07, Chris Angelico wrote:
>> AES is a stream cipher;
>
> No, it is definitely not! It's a block cipher! However, since he uses
> CFB mode of operation, it behaves like a stream cipher.
Sorry! Quite right. What I meant was,
On 24/10/2013 04:53, Ben Finney wrote:
Tim Daneliuk writes:
'Easy there Rainman
I'll thank you not to use mental deficiency as some kind of insult.
Calling someone “Rainman” is to use autistic people as the punchline of
a joke. We're a community that doesn't welcome such ableist slurs.
I
On 24/10/2013 01:18, Steven D'Aprano wrote:
- the majority of packages on PyPI now support Python 3, so the
"Wall of Shame" is now renamed the "Wall of Superpowers":
https://python3wos.appspot.com/
Thank you, thank you, thank you, it's been driving me nuts trying to
remember what the
On 24/10/2013 01:17, Steven D'Aprano wrote:
On Wed, 23 Oct 2013 14:27:29 +0100, Mark Lawrence wrote:
I confess I don't understand how *nix people endure having to compile
code instead of having a binary install.
Because it's trivially easy under Unix? Three commands:
./configure
make
make in
On 24/10/2013 05:57, Peter Cacioppi wrote:
Moreover, you get a lot of the good stuff with 2.7.
Much of it backported from Python 3.
--
Python is the second best programming language in the world.
But the best has yet to be invented. Christian Tismer
Mark Lawrence
--
https://mail.python.org
> gmail.com> writes:
>
> I am starting to have doubts as to whether Python 3.x will ever be
actually adopted by the Python community at
> large as their standard.
We're planning to start the switch on 25th December 2013, 14h UTC.
It should be finished at most 48 hours later. You should expect so
On Thu, Oct 24, 2013 at 7:26 PM, Mark Lawrence wrote:
> Precisely my point. I suspect being a Python core dev must do wonders for
> the moral fibre. Your pristine, fully reviewed patch improves performance
> by 10,000% and works wonderfully except on buildbot xyz and has to be
> reverted. How d
On 24/10/2013 07:30, Ethan Furman wrote:
On 10/23/2013 09:54 PM, Steven D'Aprano wrote:
I'm looking for advice on best practices for doing so. Any suggestions
for managing bug fixes and enhancements to two separate code-bases
without them diverging too much?
Confining your code to the interse
On Thu, Oct 24, 2013 at 7:30 PM, Antoine Pitrou wrote:
>> gmail.com> writes:
>>
>> I am starting to have doubts as to whether Python 3.x will ever be
> actually adopted by the Python community at
>> large as their standard.
>
> We're planning to start the switch on 25th December 2013, 14h UTC.
>
Mark Lawrence writes:
> On 24/10/2013 04:53, Ben Finney wrote:
> > Tim Daneliuk writes:
> >
> >> 'Easy there Rainman
> >
> > I'll thank you not to use mental deficiency as some kind of insult.
> > Calling someone “Rainman” is to use autistic people as the punchline
> > of a joke. We're a communi
On 24/10/2013 09:30, Antoine Pitrou wrote:
gmail.com> writes:
I am starting to have doubts as to whether Python 3.x will ever be
actually adopted by the Python community at
large as their standard.
We're planning to start the switch on 25th December 2013, 14h UTC.
It should be finished at m
On 24/10/2013 09:37, Chris Angelico wrote:
On Thu, Oct 24, 2013 at 7:30 PM, Antoine Pitrou wrote:
gmail.com> writes:
I am starting to have doubts as to whether Python 3.x will ever be
actually adopted by the Python community at
large as their standard.
We're planning to start the switch o
Angelico said:
"Which is why I mentioned those helpful __future__ directives,"
OK, thanks, I'll study the __future__.
I will port to 3.x in less than 60 months, or my name isn't Cacioppi. (So, in
the worst case, I might have to backport a change to my name).
--
https://mail.python.org/mai
On Thu, 24 Oct 2013 17:59:59 +1100, Ben Finney wrote:
> Steven D'Aprano writes:
>
>> I'm now at the point where I wish to backport this module to support
>> versions of Python back to 3.1 at least and possibly 2.7, and put it up
>> on PyPI.
>
> Ned Batchelder has managed something at least as a
Steven D'Aprano writes:
> 1) statistics.py in the standard library, which is written for
>Python 3.3/3.4 only, and should be as clean as possible;
>
> 2) a backport of it, on PyPI, which will support older Pythons, and
>may be slower/uglier if need be.
>
> My problem is not supporting 2.
On Thu, 24 Oct 2013 09:43:18 +0100, Mark Lawrence wrote:
> On 24/10/2013 09:30, Antoine Pitrou wrote:
>>> gmail.com> writes:
>>>
>>> I am starting to have doubts as to whether Python 3.x will ever be
>> actually adopted by the Python community at
>>> large as their standard.
>>
>> We're planning
On 10/24/13 2:59 AM, Ben Finney wrote:
Steven D'Aprano writes:
I'm now at the point where I wish to backport this module to support
versions of Python back to 3.1 at least and possibly 2.7, and put it
up on PyPI.
Ned Batchelder has managed something at least as ambitious (supporting
Python ve
On 2013-10-24 14:53, Ben Finney wrote:
> I think the request is incoherent: If you want to allow the user to
> primarily interact with the program, this is incompatible with also
> wanting to redirect standard input.
As a counter-example, might I suggest one I use regularly:
gimme_stuff_on_stdo
Am 24.10.2013 06:54, schrieb Steven D'Aprano:
> As some of you are aware, I have a module accepted into the standard
> library:
>
> http://docs.python.org/3.4/library/statistics.html
>
> I'm now at the point where I wish to backport this module to support
> versions of Python back to 3.1 at lea
On 24 October 2013 01:09, Tim Daneliuk wrote:
>
> Now that I think about it, as I recall from the prehistoric era of writing
> lots of assembler and C, if you use shell redirection, stdin shows
> up as a handle to the file
Yes this is true. A demonstration using seek (on Windows but it is the
sam
On Thu, 24 Oct 2013 06:36:04 -0400, Ned Batchelder wrote:
> coverage.py currently runs on 2.3 through 3.4
You support all the way back to 2.3???
I don't know whether to admire your dedication, or back away slowly since
you're obviously a crazy person :-)
--
Steven
--
https://mail.python.or
On 10/23/2013 11:54 PM, Ben Finney wrote:
we don't welcome ableist (nor sexist) behaviour.
Well now I just feel so very awful ...
--
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PG
On 24 October 2013 12:58, Tim Daneliuk wrote:
> On 10/23/2013 11:54 PM, Ben Finney wrote:
>>
>> we don't welcome ableist (nor sexist) behaviour.
>
> Well now I just feel so very awful ...
Please end this line of discussion. Ben is right: your comment was
entirely unnecessary and could easily offe
On Thursday, October 24, 2013 5:16:58 PM UTC+5:30, Steven D'Aprano wrote:
> On Thu, 24 Oct 2013 06:36:04 -0400, Ned Batchelder wrote:
>
> > coverage.py currently runs on 2.3 through 3.4
>
> You support all the way back to 2.3???
>
> I don't know whether to admire your dedication, or back away sl
> I am starting to have doubts as to whether Python 3.x will ever be
> actually adopted by the Python community at large as their standard.
> Years have passed, and a LARGE number of Python programmers has not
> even bothered learning version 3.x. Why am I bothered by this? Because
> of lot of good
Am 24.10.2013 14:29, schrieb Damien Wyart:
I am starting to have doubts as to whether Python 3.x will ever be
actually adopted by the Python community at large as their standard.
Years have passed, and a LARGE number of Python programmers has not
even bothered learning version 3.x. Why am I bothe
On 23/10/2013 16:24, Cesar Campana wrote:
> Hi!
>
> Im installing the python library for the version 2.7 but Im getting the
> error unable to find vcvarsall.bat
>
> I was looking on line but it says is related to Visual Studio...?
>
> Can you guys please help me to fix this...
>
The other respons
On 10/24/2013 07:10 AM, Oscar Benjamin wrote:
On 24 October 2013 12:58, Tim Daneliuk wrote:
On 10/23/2013 11:54 PM, Ben Finney wrote:
we don't welcome ableist (nor sexist) behaviour.
Well now I just feel so very awful ...
Please end this line of discussion. Ben is right: your comment was
Am Donnerstag, 24. Oktober 2013 15:41:52 UTC+2 schrieb Tim Daneliuk:
> On 10/24/2013 07:10 AM, Oscar Benjamin wrote:
>> On 24 October 2013 12:58, Tim Daneliuk wrote:
>>> On 10/23/2013 11:54 PM, Ben Finney wrote:
we don't welcome ableist (nor sexist) behaviour.
>>> Well now I just feel so very
On 10/24/2013 06:41 AM, Tim Daneliuk wrote:
But now I feel bad about myself and it's all your fault.
Really?
*plonk*
--
https://mail.python.org/mailman/listinfo/python-list
On 10/24/2013 09:36 AM, feedthetr...@gmx.de wrote:
Am Donnerstag, 24. Oktober 2013 15:41:52 UTC+2 schrieb Tim Daneliuk:
On 10/24/2013 07:10 AM, Oscar Benjamin wrote:
On 24 October 2013 12:58, Tim Daneliuk wrote:
On 10/23/2013 11:54 PM, Ben Finney wrote:
we don't welcome ableist (nor sexist)
On 10/24/2013 01:14 AM, Mark Lawrence wrote:
On 24/10/2013 04:53, Ben Finney wrote:
Tim Daneliuk writes:
'Easy there Rainman
I'll thank you not to use mental deficiency as some kind of insult.
Calling someone “Rainman” is to use autistic people as the punchline of
a joke. We're a community
On 10/24/13 9:29 AM, Damien Wyart wrote:
I am starting to have doubts as to whether Python 3.x will ever be
actually adopted by the Python community at large as their standard.
Years have passed, and a LARGE number of Python programmers has not
even bothered learning version 3.x. Why am I bother
On 10/24/13 7:46 AM, Steven D'Aprano wrote:
On Thu, 24 Oct 2013 06:36:04 -0400, Ned Batchelder wrote:
coverage.py currently runs on 2.3 through 3.4
You support all the way back to 2.3???
I don't know whether to admire your dedication, or back away slowly since
you're obviously a crazy person
How to create a program similar to paint, but the difference would be that the
cursor would be always in the middle and the canvas moves or the camera is
always fixed on the cursor as it moves around the canvas. And the canvas should
be infinite. What would be reasonable to use?
In addition, i
To start with, you'll want some sort of Graphic User Interface, a
popular and common (but not the only) one is TkInter, which you can
dive into here: https://wiki.python.org/moin/TkInter
--
https://mail.python.org/mailman/listinfo/python-list
So, i`ll take the canvas, somekind of mouse tracker, for each mouse location il
draw a dot or 2X2 square or something. Main thing i have never understood, is
how can i get the backround to move.
Lets say ia hve 200X200 window. In the middle of it is the cursor that draws.
If i move the mouse t
On 24/10/2013 20:32, markot...@gmail.com wrote:
So, i`ll take the canvas, somekind of mouse tracker, for each mouse
location il draw a dot or 2X2 square or something. Main thing i have
never understood, is how can i get the backround to move.
Lets say ia hve 200X200 window. In the middle of it i
On 10/24/2013 1:46 PM, Ned Batchelder wrote:
On Thu, 24 Oct 2013 06:36:04 -0400, Ned Batchelder wrote:
coverage.py currently runs on 2.3 through 3.4
I want to thank you for this package. I have used it when writing test
modules for idlelib modules and aiming for 100% coverage forces me to
re
On 10/24/2013 01:37 AM, Mark Lawrence wrote:
On 24/10/2013 07:30, Ethan Furman wrote:
On 10/23/2013 09:54 PM, Steven D'Aprano wrote:
I'm looking for advice on best practices for doing so. Any suggestions
for managing bug fixes and enhancements to two separate code-bases
without them diverging
Terry Reedy writes:
> On 10/24/2013 1:46 PM, Ned Batchelder wrote:
> > It's been fun dropping the contortions for coverage.py 4.x, though!
>
> One request: ignore "if __name__ == '__main__':" clauses at the end of
> files, which cannot be run under coverage.py, so 100% coverage is
> reported as 1
On 10/24/2013 1:31 PM, Ned Batchelder wrote:
On 10/24/13 9:29 AM, Damien Wyart wrote:
I am starting to have doubts as to whether Python 3.x will ever be
actually adopted by the Python community at large as their standard.
Years have passed, and a LARGE number of Python programmers has not
even
On 2013-10-24 12:16, markot...@gmail.com wrote:
> How to create a program similar to paint, but the difference would
> be that the cursor would be always in the middle and the canvas
> moves or the camera is always fixed on the cursor as it moves
> around the canvas. And the canvas should be infini
The new module is now five years old. PEP 429 Python 3.4 release
schedule has it listed under "Other proposed large-scale changes" but I
don't believe this is actually happening. Lots of issues on the bug
tracker have been closed as fixed in the new module, see issue 2636 for
more data. Some
On 24/10/2013 21:54, Ben Finney wrote:
Terry Reedy writes:
On 10/24/2013 1:46 PM, Ned Batchelder wrote:
It's been fun dropping the contortions for coverage.py 4.x, though!
One request: ignore "if __name__ == '__main__':" clauses at the end of
files, which cannot be run under coverage.py, so
On 2013-10-24, Tim Chase wrote:
> On 2013-10-24 12:16, markot...@gmail.com wrote:
>> How to create a program similar to paint, but the difference would
>> be that the cursor would be always in the middle and the canvas
>> moves or the camera is always fixed on the cursor as it moves
>> around the
On 2013-10-24 21:51, Grant Edwards wrote:
> > To hold an (effectively) infinite *bitmap* canvas, you'd
> > (effectively) need an (effectively) infinite amount of memory.
>
> Sparse arrays allow it to be sort-of implemented as long as most of
> the bitmap is "empty".
Fair enough. Raw bitmap can
On 10/24/2013 4:54 PM, Ben Finney wrote:
Terry Reedy writes:
On 10/24/2013 1:46 PM, Ned Batchelder wrote:
It's been fun dropping the contortions for coverage.py 4.x, though!
One request: ignore "if __name__ == '__main__':" clauses at the end of
files, which cannot be run under coverage.py,
On 10/24/2013 01:54 PM, Ben Finney wrote:
Terry Reedy writes:
On 10/24/2013 1:46 PM, Ned Batchelder wrote:
It's been fun dropping the contortions for coverage.py 4.x, though!
One request: ignore "if __name__ == '__main__':" clauses at the end of
files, which cannot be run under coverage.py,
Terry Reedy writes:
> OK, I added .coveragerc and that works. In the process of verifying
> this, I was reminded that there is an overt bug in the html report
[…]
At this point, it's probably best to direct this sequence of bug reports
to https://bitbucket.org/ned/coveragepy/issues/>.
--
\
Ethan Furman writes:
> On 10/24/2013 01:54 PM, Ben Finney wrote:
> > You can do this already with current Coverage: tell Coverage to
> > exclude http://nedbatchelder.com/code/coverage/excluding.html>
> > specific statements, and it won't count them for coverage
> > calculations.
>
> While that's
On 10/24/13 6:28 PM, Ethan Furman wrote:
On 10/24/2013 01:54 PM, Ben Finney wrote:
Terry Reedy writes:
On 10/24/2013 1:46 PM, Ned Batchelder wrote:
It's been fun dropping the contortions for coverage.py 4.x, though!
One request: ignore "if __name__ == '__main__':" clauses at the end of
fil
On 10/24/2013 6:36 PM, Terry Reedy wrote:
OK, I added .coveragerc and that works. In the process of verifying
this, I was reminded that there is an overt bug in the html report as
displayed by Firefox. The fonts used for line numbers
("class='linenos'") and line text ("class='text'") are slightl
On 23/10/2013 9:13 AM, Tim Golden wrote:
On 23/10/2013 14:05, Colin J. Williams wrote:
On 23/10/2013 8:35 AM, Mark Lawrence wrote:
On 23/10/2013 12:57, duf...@gmail.com wrote:
Years have passed, and a LARGE number of Python programmers has not
even bothered learning version 3.x.
The changes
Hi,
Thanks to @Stephen D'APrano and @Andrew Berg for your advice.
The advice seems to be that I should move my exception higher up, and try to
handle it all in one place:
for job in jobs:
try:
try:
job.run_all()
except Exception as err: # catch *everything*
On 2013.10.24 20:09, Victor Hooi wrote:
> Also, @Andrew Berg - you mentioned I'm just swallowing the original exception
> and re-raising a new RuntimeError - I'm guessing this is a bad practice,
> right? If I use just "raise"
>
> except Exception as err: # catch *everything*
>
Hi,
We have a directory of large CSV files that we'd like to process in Python.
We process each input CSV, then generate a corresponding output CSV file.
input CSV -> munging text, lookups etc. -> output CSV
My question is, what's the most Pythonic way of handling this? (Which I'm
assuming
F
On 24/10/2013 21:38, Victor Hooi wrote:
> Hi,
>
> We have a directory of large CSV files that we'd like to process in Python.
>
> We process each input CSV, then generate a corresponding output CSV file.
>
> input CSV -> munging text, lookups etc. -> output CSV
>
> My question is, what's the most
On Thu, 24 Oct 2013 20:17:24 -0500, Andrew Berg wrote:
> On 2013.10.24 20:09, Victor Hooi wrote:
>> Also, @Andrew Berg - you mentioned I'm just swallowing the original
>> exception and re-raising a new RuntimeError - I'm guessing this is a
>> bad practice, right?
Well, maybe, maybe not. It depen
On Thu, 24 Oct 2013 18:38:21 -0700, Victor Hooi wrote:
> Hi,
>
> We have a directory of large CSV files that we'd like to process in
> Python.
>
> We process each input CSV, then generate a corresponding output CSV
> file.
>
> input CSV -> munging text, lookups etc. -> output CSV
>
> My questi
On Fri, 25 Oct 2013 02:10:07 +, Dave Angel wrote:
>> If I have multiple large CSV files to deal with, and I'm on a
>> multi-core machine, is there anything else I can do to boost
>> throughput?
>
> Start multiple processes. For what you're doing, there's probably no
> point in multithreading
On 25/10/2013 02:38, Victor Hooi wrote:
So for the reading, it'll iterates over the lines one by one, and won't read it
into memory which is good.
Wow this is fantastic, which OS are you using? Or do you actually mean
that the whole file doesn't get read into memory, only one line at a
ti
On 24/10/2013 23:35, Steven D'Aprano wrote:
> On Fri, 25 Oct 2013 02:10:07 +, Dave Angel wrote:
>
>>> If I have multiple large CSV files to deal with, and I'm on a
>>> multi-core machine, is there anything else I can do to boost
>>> throughput?
>>
>> Start multiple processes. For what you're
On Fri, Oct 25, 2013 at 2:57 PM, Dave Angel wrote:
> But I would concur -- probably they'll both give about the same speedup.
> I just detest the pain that multithreading can bring, and tend to avoid
> it if at all possible.
I don't have a history of major pain from threading. Is this a Python
th
Le mardi 15 octobre 2013 23:00:29 UTC+2, Mark Lawrence a écrit :
> On 15/10/2013 21:11, wxjmfa...@gmail.com wrote:
>
> > Le lundi 14 octobre 2013 21:18:59 UTC+2, John Nagle a écrit :
>
> >
>
> >
>
> >
>
> > [...]
>
> >>
>
> >> No, Python went through the usual design screwups. Loo
Chris Angelico, 25.10.2013 08:13:
> On Fri, Oct 25, 2013 at 2:57 PM, Dave Angel wrote:
>> But I would concur -- probably they'll both give about the same speedup.
>> I just detest the pain that multithreading can bring, and tend to avoid
>> it if at all possible.
>
> I don't have a history of majo
75 matches
Mail list logo
