Announcing Numexpr 2.4
Numexpr is a fast numerical expression evaluator for NumPy. With it,
expressions that operate on arrays (like 3*a+4*b) are accelerated
and use less memory than doing the same calculation in Python.
It wears
I'm happy to announce a new release of pyparsing, version 2.0.2.
This release contains some small enhancements and some bugfixes.
Change summary:
---
- Extended expr(name) shortcut (same as expr.setResultsName(name))
to accept expr() as a shortcut for expr.copy().
- Added
Crochet is an MIT-licensed library that makes it easier to use Twisted
from regular blocking code. Some use cases include:
* Easily use Twisted from a blocking framework like Django or Flask.
* Write a library that provides a blocking API, but uses Twisted for
its
I am happy to announce the release of Bokeh version 0.4.4!
Bokeh is a Python library for visualizing large and realtime datasets on the
web. Its goal is to provide elegant, concise construction of novel graphics in
the style of Protovis/D3, while delivering high-performance interactivity to
Anthony Papillion papill...@gmail.com writes:
Some say 'Python 3 is the future, use it for everything now' and other
say 'Python 3 is the future but you can't do everything in it now so
use Python 2'.
Python 3 is generally better than Python 2, except for a few packages
that haven't been
On Sat, Apr 19, 2014 at 4:40 PM, Paul Rubin no.email@nospam.invalid wrote:
If you're starting a new project and you get to choose between 2 and 3,
other things equal I'd say use 3. I've kept using 2 basically because
it's the path of least resistance. I'm somewhat following the 3
situation
On Sat, Apr 19, 2014 at 1:34 AM, Chris Angelico ros...@gmail.com wrote:
That'll make Python 2.6/2.7 behave like Python 3.x in three ways:
firstly, print will be a function instead of a statement (and it's
more powerful than the statement form, as well as being more
flexible); secondly, quoted
On Sat, Apr 19, 2014 at 7:25 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
The change from / denoting classic
division to true division really only affects the case where both
operands are integers, so far as I'm aware. If you want to divide two
integers and get a decimal result, then convert
Ian Kelly ian.g.ke...@gmail.com:
On Sat, Apr 19, 2014 at 1:34 AM, Chris Angelico ros...@gmail.com wrote:
if you're going to move to Python 3, you may as well have your code
start working that way, so you get used to typing // to divide
integers and get an integer (floor division).
[...]
Anthony Papillion papill...@gmail.com writes:
So I've been working with Python for a while and I'm starting to take
on more and more serious projects with it. I've been reading a lot
about Python 2 vs Python 3 and the community kind of seems split on
which should be used.
The community is in
On Saturday, April 19, 2014 4:35:41 PM UTC+5:30, Ben Finney wrote:
Well, it's clear: Python 3 is uncontroversially the future :-) Also:
\Spam will be a thing of the past in two years' time. --Bill |
`\ Gates, 2004-01-24 |
_o__)
On Fri, 18 Apr 2014 22:28:05 -0500, Anthony Papillion papill...@gmail.com
wrote:
Hello Everyone,
So I've been working with Python for a while and I'm starting to take
on more and more serious projects with it. I've been reading a lot
about Python 2 vs Python 3 and the community kind of seems
On 4/16/2014 6:38 AM, Egon Frerich wrote:
If I use the interpreter I get:
Python 3.3.5 (default, Apr 12 2014, 23:34:20)
[GCC 4.6.3] on linux
Type help, copyright, credits or license for more information.
import mptt
print(mptt)
module 'mptt' from './mptt/__init__.py'
But if I import mptt in
On Sat, Apr 19, 2014 at 9:53 PM, Steve Hayes hayes...@telkomsa.net wrote:
Some say 'Python 3 is the future, use it for everything now' and other
say 'Python 3 is the future but you can't do everything in it now so
use Python 2'.
Yes, that made me more or less abandon my attempt to learn Python.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/04/14 05:49, Andrew Berg wrote:
On 2014.04.18 22:28, Anthony Papillion wrote:
What is the general feel of /this/ community? I'm about to start
a large scale Python project. Should it be done in 2 or 3? What
are the benefits, aside from the
On 2014.04.19 07:58, Ian Foote wrote:
Django has been there since 1.5. My company has been using python3 in
production since 1.6 was released. There have been a few other third
party libraries we've wanted to use but can't, but we've been able to
work around that.
I guess I'm a bit behind the
On 4/19/2014 12:04 AM, Ryan Hiebert wrote:
If you are starting a new project, I'd highly encourage you to use
Python 3. It is a stable, well supported, and beautiful language, and
gives you the full power of the innovation that is current in the
Python world. Python 2 is still well supported
Chris Angelico ros...@gmail.com wrote:
I strongly recommend going for Python 3 unless something actually
stops you from doing so.
One of the problems is you don't know in advance if something is going
to stop you. By committing to P3 now, you are eliminating from possible
future use, all of
On Sat, Apr 19, 2014 at 11:26 PM, Roy Smith r...@panix.com wrote:
Chris Angelico ros...@gmail.com wrote:
I strongly recommend going for Python 3 unless something actually
stops you from doing so.
One of the problems is you don't know in advance if something is going
to stop you. By
On Friday, April 18, 2014 8:46:13 PM UTC-7, Larry Hudson wrote:
On 04/18/2014 04:14 PM, gwhite wrote:
[snip]
I'm not sure when a backslash continuation might be needed, or if that
requirement has been designed out of Python.
['they' meaning trailing backslashes]
No, 'they' are
On Friday, April 18, 2014 10:28:05 PM UTC-5, Anthony Papillion wrote:
Hello Everyone,
So I've been working with Python for a while and I'm starting to take
on more and more serious projects with it. I've been reading a lot
about Python 2 vs Python 3 and the community kind of seems split on
Am 18.04.2014 13:48, schrieb Peter Otten:
Egon Frerich wrote:
Basically Python 3 allows for packages to omit the __init__.py
$ mkdir aaa
$ python3 -c'import aaa; print(aaa)'
module 'aaa' (namespace)
$ touch aaa/__init__.py
$ python3 -c'import aaa; print(aaa)'
module 'aaa' from
Am 19.04.2014 14:33, schrieb bob gailer:
On 4/16/2014 6:38 AM, Egon Frerich wrote:
If I use the interpreter I get:
Python 3.3.5 (default, Apr 12 2014, 23:34:20)
[GCC 4.6.3] on linux
Type help, copyright, credits or license for more information.
import mptt
print(mptt)
module 'mptt' from
On Saturday, April 19, 2014 5:23:01 PM UTC+5:30, Steve Hayes wrote:
It took me a week, with some help from this forum, to get the Print statement
to work.
How long does it take one to learn to drive a car?
To play the piano? To become a brain surgeon?
No I am not exactly in the gung-ho over
On 19/04/2014 14:06, Eric S. Johansson wrote:
On 4/19/2014 12:04 AM, Ryan Hiebert wrote:
If you are starting a new project, I'd highly encourage you to use
Python 3. It is a stable, well supported, and beautiful language, and
gives you the full power of the innovation that is current in the
On 4/19/2014 2:40 AM, Paul Rubin wrote:
That said, I don't know anyone who actually uses Python 3.
I have no idea who you know ;-)
LibreOffice bundles 3.3. So anyone who does Python scripting in
LibreOffice is using Python 3. Actually, I believe LO uses Python
internally for some of its
On 19/04/2014 07:40, Paul Rubin wrote:
That said, I don't know anyone who actually uses Python 3.
You do now :)
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
---
This email is free from viruses and malware because
On Sun, Apr 20, 2014 at 3:23 AM, Terry Reedy tjre...@udel.edu wrote:
LibreOffice bundles 3.3. So anyone who does Python scripting in LibreOffice
is using Python 3.
This much I agree with...
Actually, I believe LO uses Python internally for some of
its scripting. If so, everyone using LO is
- Original Message -
From: Chris Angelico ros...@gmail.com
To:
Cc: python-list@python.org python-list@python.org
Sent: Saturday, April 19, 2014 3:42 PM
Subject: Re: Why Python 3?
snip
Right. It's not the magic line that fixes everything; if it were,
Python 3 wouldn't be a big
On Sat, Apr 19, 2014 at 3:37 AM, Chris Angelico ros...@gmail.com wrote:
On Sat, Apr 19, 2014 at 7:25 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
The change from / denoting classic
division to true division really only affects the case where both
operands are integers, so far as I'm aware. If
On Sun, Apr 20, 2014 at 5:58 AM, Ian Kelly ian.g.ke...@gmail.com wrote:
Considering that Fraction and Decimal did not exist yet, what type do
you think the PEP 238 implementers should have chosen for the result
of dividing two ints? If float is not acceptable, and int is not
acceptable (which
On Sat, Apr 19, 2014 at 2:31 PM, Chris Angelico ros...@gmail.com wrote:
On Sun, Apr 20, 2014 at 5:58 AM, Ian Kelly ian.g.ke...@gmail.com wrote:
Considering that Fraction and Decimal did not exist yet, what type do
you think the PEP 238 implementers should have chosen for the result
of dividing
On Sun, Apr 20, 2014 at 6:38 AM, Ian Kelly ian.g.ke...@gmail.com wrote:
Or you just cast one of them to float. That way you're sure you're
working with floats.
Which is inappropriate if the type passed in was a Decimal or a complex.
In that case, you already have a special case in your code,
Chris Angelico wrote:
I'd rather have to explicitly request floating-point division;
When you write / in Python 3, you *are* explicitly requesting
floating-point division.
Similarly, when you write // you're explicitly requesting
integer division.
I don't see the problem. You write whatever
On Sun, Apr 20, 2014 at 11:06 AM, Gregory Ewing
greg.ew...@canterbury.ac.nz wrote:
Chris Angelico wrote:
I'd rather have to explicitly request floating-point division;
When you write / in Python 3, you *are* explicitly requesting
floating-point division.
Similarly, when you write //
Chris Angelico wrote:
Is your function so generic that it has to be able
to handle float, Decimal, or complex, and not care about the
difference, and yet has to ensure that int divided by int doesn't
yield int?
It doesn't have to be that generic to cause pain. Even if
you're only dealing with
On 04/18/2014 10:49 PM, Andrew Berg wrote:
Python 3 is not the future; it is the present. If you're developing
an application, just use Python 3.4 and don't look back unless you
absolutely positively *need* one of the big libraries that doesn't
fully support Python 3 yet.
Depends on what OS
Terry Reedy tjre...@udel.edu writes:
LibreOffice bundles 3.3. So anyone who does Python scripting in
LibreOffice is using Python 3. Actually, I believe LO uses Python
internally for some of its scripting. If so, everyone using LO is
indirectly using 3.3.
I didn't even know LO supported Python
On 4/19/2014 9:06 PM, Gregory Ewing wrote:
Chris Angelico wrote:
I'd rather have to explicitly request floating-point division;
When you write / in Python 3, you *are* explicitly requesting
floating-point division.
Similarly, when you write // you're explicitly requesting
integer division.
Aivar Annamaa added the comment:
Regarding #16795, the documentation says The lineno is the line number of
source text and the col_offset is the UTF-8 byte offset of the first token that
generated the node, not that lineno and col_offset indicate a suitable
position to mention in the error
Roundup Robot added the comment:
New changeset bc4eb1b3db5d by Eric Snow in branch '3.4':
Issue #21200: Return None from pkgutil.get_loader() when __spec__ is missing.
http://hg.python.org/cpython/rev/bc4eb1b3db5d
--
nosy: +python-dev
___
Python
Eric Snow added the comment:
The change is pretty minor so I went ahead and pushed it. To be honest, we
should consider deprecating both get_loader and find_loader. I'm just not
going to worry about it right now. :)
--
resolution: - fixed
stage: patch review - resolved
status: open
Senthil Kumaran added the comment:
Christian's patch is good.It helps in setting the socket.makefile file
descriptor to a well behaving well file close wrapper and thus will help us
prevent some tricky fd close issues.
I added tests for coverage to ensure that we are asserting the type and
Eric Snow added the comment:
Here's a (currently segfaulting) patch that demonstrates how I'd like to solve
this. Feedback on the approach is welcome. :) When I get a chance I'll debug
the segfault.
--
assignee: - eric.snow
keywords: +patch
stage: - patch review
Added file:
Senthil Kumaran added the comment:
I agree. Having tell on a file descriptor of a URL request is not going to be
of help. You can easily write to a local file and use all the local file
features, if it is things like .tell is desired.
--
resolution: - not a bug
stage: needs patch -
Antoine Pitrou added the comment:
Why exactly does it need to be backported? os.urandom under 2.7 works fine.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21305
___
Martin v. Löwis added the comment:
I think the issue is actually slightly different. You can certainly build your
Python in debug, and still link with the release mode Python. The question is
what in debug means, and the normal definition would be with the generation
of debug symbols by the
Changes by Cory Benfield c...@lukasa.co.uk:
--
nosy: +Lukasa
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21308
___
___
Python-bugs-list mailing
New submission from Christian Heimes:
I'm interested to assist with all back port tickets as soon as my internet
connection is fixed. A technician is going to check my line again on Tuesday.
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
I'm not really interested to assist with backport tickets myself. You may nosy
me but I may not care at all :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21308
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +neologix
stage: - patch review
versions: +Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21287
___
New submission from John Szakmeister:
It's pretty typical for ccache packages to install symlinks for compilers that
may not be present on the system, such as Homebrew's ccache package.
Unfortunately, the _osx_support.py file is mislead by the presence of the
symlink and ends up backtracing.
John Szakmeister added the comment:
Here's the alternate fix.
--
Added file:
http://bugs.python.org/file34973/alt-fix-osx-llvm-detection-with-ccache.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21311
Nick Coghlan added the comment:
It was in the list of security fixes Alex and Donald wanted to reduce
vulnerabilities in 2.x network services, and Guido was OK with backporting
it.
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
It was in the list of security fixes Alex and Donald wanted to reduce
vulnerabilities in 2.x network services, and Guido was OK with backporting
it.
What security issue is there exactly? os.urandom() does a similar thing
in 2.7 and 3.x (it reads from
Alex Gaynor added the comment:
It's not a security issue per-se, but if you're doing many small reads, there's
such an enormous performance and scalability difference that if users run into
an issue, they're likely to work around it by using a non-CS PRNG, and
compromising their application
Antoine Pitrou added the comment:
It's not a security issue per-se, but if you're doing many small
reads, there's such an enormous performance and scalability difference
that if users run into an issue, they're likely to work around it by
using a non-CS PRNG, and compromising their
Antoine Pitrou added the comment:
Note that the 3.4 scheme is not fully debugged yet: issue21207. There is a
reason we don't backport new features!
Regardless, I'm not interested in this, so I'll let you take the risk of
regressions if you want to.
--
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: -pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21305
___
___
Python-bugs-list mailing
Changes by Alex Gaynor alex.gay...@gmail.com:
--
nosy: +alex
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21207
___
___
Python-bugs-list mailing
Changes by Senthil Kumaran sent...@uthcode.com:
--
nosy: -orsenthil
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18967
___
___
Python-bugs-list
Senthil Kumaran added the comment:
For this bug, I think, section 2.2.4 and section 2.2.5 can be moved to section
13 and inserted between section 13.1 and 13.2 as it seem to be fit in naturally
there.
--
___
Python tracker rep...@bugs.python.org
Changes by Senthil Kumaran sent...@uthcode.com:
--
nosy: -orsenthil
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2052
___
___
Python-bugs-list
Benjamin Peterson added the comment:
The last argument to _PyObject_CallMethodIdObjArgs needs to be NULL...
--
nosy: +benjamin.peterson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21226
Roundup Robot added the comment:
New changeset 16207b8495bf by R David Murray in branch '3.4':
#9364: Improve the text printed by help(pydoc) and help(help).
http://hg.python.org/cpython/rev/16207b8495bf
New changeset 256c782ab078 by R David Murray in branch 'default':
Merge: #9364: Improve the
R. David Murray added the comment:
Thanks, Glenn. I tweaked the wording further. If someone thinks it is worth
the effort to backport this to 2.7, they can do so and reopen the issue.
--
assignee: eric.araujo -
nosy: +r.david.murray
resolution: - fixed
stage: needs patch - resolved
New submission from Jack McCracken:
The thread_foobar.h reference for the interface for abstracting the
platform-specific thread implementation does not include newer features such as
timed locking and TLS support.
--
components: Interpreter Core
files: update_thread_foobar.diff
Jack McCracken added the comment:
Missed a word in a comment
--
Added file: http://bugs.python.org/file34975/update_thread_foobar_v2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21312
Antoine Pitrou added the comment:
You may want to provide an implementation of PyThread_acquire_lock() that
simply defers to PyThread_acquire_lock_timed() (see thread_pthread.h, which
does the same).
--
nosy: +pitrou
___
Python tracker
Jack McCracken added the comment:
Added an example of deferring to PyThread_acquire_lock_timed in
PyThread_acquire_lock. Also fixed a mistake in the string of a dprintf in
PyThread_acquire_lock_timed.
--
Added file: http://bugs.python.org/file34976/update_thread_foobar_v3.diff
Antoine Pitrou added the comment:
Hum, your comment about deferring is wrong, since thread_nt.h also does the
deferring:
int
PyThread_acquire_lock(PyThread_type_lock aLock, int waitflag)
{
return PyThread_acquire_lock_timed(aLock, waitflag ? -1 : 0, 0);
}
--
Jack McCracken added the comment:
Oops... I removed that and just put the deferral in there.
--
Added file: http://bugs.python.org/file34977/update_thread_foobar_v4.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21312
Antoine Pitrou added the comment:
Thanks! The patch looks good to me, I'll let it sleep a bit to see if other
people have an opinion.
--
nosy: +tim.peters
stage: - patch review
versions: +Python 3.5
___
Python tracker rep...@bugs.python.org
Jessica McKellar added the comment:
This looks like a copy-paste typo from test_asynchat, which does use `usepoll`.
Attached is a patch that removes `usepoll` and a
`DispatcherWithSendTests_UsePoll` TestCase that did nothing but set
`usepoll=True`.
* The diff passes `make patchcheck`.
* The
Changes by Ned Deily n...@acm.org:
--
assignee: - ned.deily
nosy: +ned.deily
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21311
___
___
Roundup Robot added the comment:
New changeset cbe7b5a5a110 by Antoine Pitrou in branch 'default':
Issue #7221: remove redundant tests in test_asyncore. Patch by Jessica
McKellar.
http://hg.python.org/cpython/rev/cbe7b5a5a110
--
nosy: +python-dev
Antoine Pitrou added the comment:
Now committed. Thanks for the patch!
--
resolution: - fixed
stage: patch review - resolved
status: open - closed
versions: +Python 3.5 -Python 2.7, Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset e3217efa6edd by Ned Deily in branch '2.7':
Issue #21311: Avoid exception in _osx_support with non-standard compiler
http://hg.python.org/cpython/rev/e3217efa6edd
New changeset 3d1578c705c9 by Ned Deily in branch '3.4':
Issue #21311: Avoid exception
Ned Deily added the comment:
Thanks for the report and the patches. I am not sure exactly what problem
using ccache is causing but it is clear that, if for whatever reason the call
to _read_output fails and returns None, the 'llvm-gcc' test will fail so that
test should be fixed as suggested
Ned Deily added the comment:
Stefan, the patch LGTM although I sure wish we were removing some
CFLAGS-related configuration variables rather than adding another. But I don't
have a better suggestion short of a comprehensive cleanup of all of them.
--
stage: - commit review
versions:
R. David Murray added the comment:
The change covered by the patch (which patch rejected as garbage, by the way, I
have no idea why) has already been applied by Serhiy Storchaka, apparently as a
blanked change of 'empty string' to 'empty bytes object'.
There are several other places in the
Changes by R. David Murray rdmur...@bitdance.com:
--
Removed message: http://bugs.python.org/msg216880
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4744
___
R. David Murray added the comment:
The change covered by the patch (which patch rejected as garbage, by the way, I
have no idea why) has already been applied by Serhiy Storchaka, apparently as a
blanket change of 'empty string' to 'empty bytes object'.
There are several other places in the
paul j3 added the comment:
http://bugs.python.org/issue14191
implements the other side of optparse behavior - allowing a complete
intermixing of optionals and positionals.
It does that with a new 'ArgumentParser.parse_intermixed_args()' method.
--
New submission from Eric Snow:
Py_GetVersion() (in Python/getversion.c) builds the version string returned by
sys.version:
PyOS_snprintf(version, sizeof(version), %.80s (%.80s) %.80s,
PY_VERSION, Py_GetBuildInfo(), Py_GetCompiler());
In turn, Py_GetBuildInfo() (in
John Szakmeister added the comment:
Thank you Ned! The issue is that you can create symlinks to ccache to and put
them on your path. Distros do this for you now, but most create symlinks for a
bunch of compilers... including ones that may not be installed. So the
presence of the name
Jessica McKellar added the comment:
Thanks for the bug report and patch, belopolsky!
The original patch no longer applies cleanly, so attached is a regenerated
version.
* The new patch passes `make patchcheck`.
* The full test suite passes with this patch.
* I manually tested that before the
Eric Snow added the comment:
Thanks, Benjamin. Here's an updated patch that passes all tests. It should be
good to go. And yet again our zipimport implementation was a pain point. :(
--
Added file:
http://bugs.python.org/file34980/fix-PyImport_ExecCodeModuleObject.diff
Changes by akira 4kir4...@gmail.com:
--
nosy: +akira
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21302
___
___
Python-bugs-list mailing list
Jessica McKellar added the comment:
I ran some experiments to see what the state of the world is. I generated a
test.csv by exporting a CSV file from Numbers on OSX. This generated a file
with Windows-style \r\n-terminated lines. The attached test_csv.py tries to
open this CSV file in binary
Changes by Jessica McKellar jesst...@mit.edu:
Added file: http://bugs.python.org/file34982/test.csv
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8387
___
Jessica McKellar added the comment:
All of the examples from https://docs.python.org/3/library/csv.html run without
issue on OSX, though.
In summary, the Python 2 examples error out on OSX and switching them to use
'U' instead of 'b' would fix this. I don't think any action needs to be taken
Roundup Robot added the comment:
New changeset 1f3946b22e64 by Ned Deily in branch '3.4':
Issue #11571: Ensure that the turtle window becomes the topmost window
http://hg.python.org/cpython/rev/1f3946b22e64
New changeset 01228d7b5e01 by Ned Deily in branch 'default':
Issue #11571: merge with
Roundup Robot added the comment:
New changeset 004fe3449193 by Ned Deily in branch 'default':
Issue #10291: Cleanup turtledemo to use docstrings for help.
http://hg.python.org/cpython/rev/004fe3449193
--
nosy: +python-dev
___
Python tracker
Changes by Ned Deily n...@acm.org:
--
versions: +Python 3.4, Python 3.5 -Python 2.7, Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11571
___
Ned Deily added the comment:
The fix for turtle has been applied for release in 3.4.1 and 3.5.0.
--
resolution: wont fix - fixed
stage: commit review - resolved
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11571
Mark Lawrence added the comment:
I think that it's complete nonsense to talk about binary csv files on Windows.
They are just plain text files that can be manipulated with any old editor or a
spreadsheet.
--
nosy: +BreamoreBoy
___
Python tracker
Ned Deily added the comment:
Thanks for the refresh, Jessica. I decided to separate out the turtle window
raise for OS X and apply that for 3.4.1 and 3.5.0 in Issue11571. The remainder
of the patch to use the docstrings, plus removal of the two other obsolete text
files, is spplied here for
R. David Murray added the comment:
The magic of newline='' in python3 is that it *preserves* the line end
characters, which is the same thing binary mode does on windows. The place
that matters, as I remember it, is when there is a newline embedded inside a
quoted string. I don't remember
Luiji Maryo added the comment:
Apologies, I was tired when I looked into this. It turns out that SMTP is
explicitly case-insensitive with command names. I still think it'd be nice to
use upper-case commands for consistency with the FROM: and TO: lines, though,
or to put the FROM: and TO:
1 - 100 of 105 matches
Mail list logo
