Alan added the comment:
Using repr highlights the issue which lies in the behaviour of str.strip()
which does not strip away null spaces as I would have expected:
' 'utm10\x00' ' == ' 'utm10' '
not equal
Changing the code to:
currColl=line.split("
Alan added the comment:
The big innovation with poll() is that it takes an array of descriptors like a
normal function.
https://www.geometrydash.me/
--
nosy: +alanpreston
___
Python tracker
<https://bugs.python.org/issue28
New submission from Alan :
Dear PythonDev,
Thank you for your tremendous work in building a simpler programming language
for all.
As an avid user of lists, I am upset that my list cannot preserve its
referential integrity in the attached pythonissue.txt file. In the following,
(EXPECTED
Alan added the comment:
Thank you for your feedback steven.daprano and eric.smith. My first experience
with a computer was 22 years ago and started as a computer science student 13
years ago. I began in the Visual Basic programming community in 2008, so I
apologize as I am new to the Python
New submission from Alan:
The "Select Python Installations" dialog box contains the line "Select the
Python locations where should be installed." If
is anything other than a very short string, the line is
truncated, due to the following factors:
- the line doesn
New submission from Alan:
I've written a piece of code to POST request to a web service.
===
import json
import urllib
from urllib import request
from urllib import parse
def Payload(start_date, end_date, pnode
Alan WiIliams added the comment:
Hi, I'd like to work on this issue. Based on the discussion, the main thing to
do here is to raise a deprecation warning when isdst is used?
--
nosy: +Alan.Williams
___
Python tracker
<https://bugs.py
Alan McIntyre added the comment:
Confirmed that this happens on Mac OS X with a fresh build of py3k from svn.
--
nosy: +alanmcintyre
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Alan McIntyre added the comment:
The last character is n-1, but the section you quote says the *right
edge* of the last character (not the last character itself) has index n;
this seems correct in the context of the mnemonic scheme.
--
nosy: +alanmcintyre
Alan McIntyre added the comment:
I have to review a few complex math topics for some of my current course
work, so I wouldn't mind taking a look into this. I can't promise I'll
have the time required to make all of cmath correct (assuming it's as
unsound as claimed), bu
Changes by Alan Hourihane :
--
resolution: accepted -> remind
___
Python tracker
<http://bugs.python.org/issue10898>
___
___
Python-bugs-list mailing list
Un
Alan McIntyre added the comment:
I also can't see any file operations that might occur between the two .tell()
calls, and a full test pass (including test_zipfile64) on the py3k development
branch doesn't turn up any problems on Linux (2.6.38, x86_64) for me, so I
agree the se
Alan McIntyre added the comment:
I re-checked testzip-patch3.diff since some time has passed since I last
commented on it, and it still seems to work ok (the small test_zipfile.py block
failed to apply, but that's easy enough to do manually). Passes full test run,
test_zipfile64.py
Alan McIntyre added the comment:
So far I haven't had the opportunity to sit down and write up a "lenient
zipfile handling" patch; my apologies to those that could really use one. If
somebody does propose a patch, I'll be glad to test and review it.
I suppose I would l
New submission from Alan Grow :
If you split a string in a maximum of zero places, you should get the original
string back. "".split(s,0) behaves this way. But re.split(r,s,0) performs an
unlimited number of splits in this case.
To get an unlimited number of splits, "&qu
New submission from Alan Beccati :
Hello,
did I discover a python string comparison bug or is this behaviour expected and
I am doing something wrong?
This is the code I run:
for line in lines[4:]:
currColl=line.split(":")[1].strip()
print "'",currC
Alan Hourihane added the comment:
Hi Antoine,
Unfortunately the #undef is too early and later #includes redefine it.
We should move the #undef closer to the code that actually uses them.
--
resolution: fixed -> accepted
status: closed ->
Alan Hourihane added the comment:
No, that patch still doesn't work.
--
resolution: fixed -> accepted
___
Python tracker
<http://bugs.python.org
Alan Hourihane added the comment:
I've had to split the three #undef's up to just before they're used.
--
___
Python tracker
<http://bugs.pyt
Alan Hourihane added the comment:
Well, I'd probably prefer something akin to my first patch then.
There's no need to #undef things at all if we just prefix the usage with PYTHON_
--
___
Python tracker
<http://bugs.python.o
Changes by Alan Justino :
--
nosy: +alanjds
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue9528>
___
___
Python-bugs-list mailing list
Unsub
Alan Justino added the comment:
@haypo: Because it affects version 2.7 too.
@Victor: Even since we will not backport any modules to Python 2.7, is not
worth to sign that this affects it too? Even wontfix or rejected, it affects,
does not?
Have I made something wrong? Sorry to be so newbie
Alan Justino added the comment:
(noticed a typo at the start of my last msg: @Victor should be @brett.cannon)
--
___
Python tracker
<http://bugs.python.org/issue9
Alan McIntyre added the comment:
Here's an updated patch against the py3k trunk (testzip-patch3.diff) that
passes all tests (including test_zipfile64) on Linux on a 64-bit machine.
I can backport this to 2.x, but I'll wait until somebody indicates a need for
it before I spend any
Alan McIntyre added the comment:
Apparenty _EndRecData64 needed the same kind of check that _EndRecData has when
trying to seek to the end-of-archive record. So I added that, and everything
seems to work correctly now. All tests pass on my 64-bit Linux box (including
test_zipfile64).
The
Alan McIntyre added the comment:
I wrote a test for this and tried out the patch on the Python3 trunk, and it
seems to work ok. I've attached an updated patch that includes the test.
It probably wouldn't hurt to go look for other places where a struct is being
unpacked withou
Alan McIntyre added the comment:
Thanks for the patch, Craig; I should have some time later today or tomorrow to
do a review. Did you have a patch for the test suite(s) as well? If not, I
can just make sure your test case is covered in test_zipfile64
Alan McIntyre added the comment:
Here's an updated patch for the py3k trunk with tests. This pretty much
doubles the runtime of test_zipfile64.py. The patch also removes some
unnecessary code from the existing test_zipfile64 tests.
Note: It looks like writestr will also suffer f
Alan McIntyre added the comment:
Maybe ZipFile should have an option to handle archives in a non-strict mode, in
which it would raise warnings or just completely ignore a small set of minor
violations of the spec. That way people that want behavior that's in
compliance with the spec
Alan McIntyre added the comment:
I had to look up the abbreviation (Easier to Ask Forgiveness than Permission),
but that does sound like a good idea. Thanks for mentioning it. :-)
--
___
Python tracker
<http://bugs.python.org/issue4
Changes by Alan McIntyre :
Removed file: http://bugs.python.org/file9144/empty-zipfile.diff
___
Python tracker
<http://bugs.python.org/issue1710703>
___
___
Python-bug
Alan McIntyre added the comment:
My apologies if Georg was waiting on me to say, "Yes." :-)
I've attached an updated patch that has the NEWS/doc changes Antoine mentioned.
I also just checked that the tests still pass on Linux against the current
trunk, and that the d
Changes by Alan McIntyre :
Removed file: http://bugs.python.org/file18534/zipfile_empty2.diff
___
Python tracker
<http://bugs.python.org/issue1710703>
___
___
Python-bug
Changes by Alan Kennedy :
--
nosy: +amak
___
Python tracker
<http://bugs.python.org/issue3566>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
New submission from Alan Hourihane :
Python 2.7.1 redefines FSTAT, but the problem is my libc already defines FSTAT
in sys/ioctl.h.
I've worked around this by prefixing the FSTAT define with PYTHON. It should
probably be done with STAT too.
--- Modules/posixmodule.c.old 2011-01-12
Alan Hourihane added the comment:
On Tue, 2011-01-18 at 19:59 +, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> How about adding "#undef FSTAT" instead? Would it work for you?
Sure.
Alan.
--
___
Py
New submission from Alan Isaac :
In PEP 227 missing text is marked with XXX. Most of this is just calls for
examples and elaboration. However under the Implementation section XXX marks a
substantive question about the documentation.
Fixing this may be low priority, but a tracker search
Alan Isaac added the comment:
Bear with my confusion about your response. Are you saying that CPython
documentation bugs cannot be submitted here, or that this does not constitute a
CPython documentation bug? I assume the latter. But then, can you tell me
where to find the correct CPython
Changes by Alan Kennedy <[EMAIL PROTECTED]>:
--
nosy: +amak
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2550>
__
___
Python-bugs-list mailin
Alan McIntyre <[EMAIL PROTECTED]> added the comment:
Sure, I'll look at it later today or over the weekend. I should
probably break out the parts that apply to other issues and update those
patches as well.
__
Tracker <[EMAIL PROTECTED]>
<ht
Alan McIntyre <[EMAIL PROTECTED]> added the comment:
I don't see a patch attached, but the duplicated code does need
removing. If you can attach a patch I'll try it out.
As much as I dislike the "string" names (magicXXX seemed much more
descriptive), I suppose they
Alan McIntyre <[EMAIL PROTECTED]> added the comment:
The patch seems to work just fine for me, all tests pass (including
test_zipfile64) on an Intel Mac. I'd vote to go ahead and revert the
magicXXX variables back to their original names--I'm sure Twisted isn't
the only p
Alan McIntyre <[EMAIL PROTECTED]> added the comment:
Thanks for fixing this, Amaury. I ran the test_zipfile64 and
test_zipfile tests on Linux and OS X, and they pass.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Alan McIntyre <[EMAIL PROTECTED]> added the comment:
Your patch seems like a better way to detect whether a file is written
as Zip64, and it seems to be able to properly handle extracting a >2GB
file from a >2GB archive, so I'd vote to include it.
I tested it with r66233,
Alan McIntyre <[EMAIL PROTECTED]> added the comment:
No, I don't have commit access at the moment.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
New submission from Alan Gardner <[EMAIL PROTECTED]>:
I believe I have found a bug in win32file.GetCommState and
win32file.SetCommState. I have seen it in Python 2.4 and Python 2.5,
running an older version of pywin32, as well as the current (212)
version. It exists in Win2k and WinXP.
New submission from alan hoover :
Background:
building a screen using Tkinter based on information from a database to let
user take action on the database rows. I don't know how many rows there will
be, so I'm storing the widgets in arrays for each column.
Code:
for row in
Alan McIntyre added the comment:
There was another issue that also asked for an extract feature, and if I
recall correctly I said I'd try to work on it (I think I have some code
somewhere for it but I'll have to look). Tonight or tomorrow I will see
if I can find that other issue a
Alan McIntyre added the comment:
At the moment I don't have a Windows machine available, but on my Mac,
time.localtime doesn't seem to mind interpreting negative input values.
So I doubt that forcing timestamps to be non-negative is the way to fix
this.
I poked around a bit in the c
Alan McIntyre added the comment:
This sort of change definitely needs to be made to avoid reading huge
files into memory for testzip(). I've attached a modified patch as
zipfile_testzip_amcintyre.diff; it didn't seem appropriate to have a
module-level variable for the size of the test
Alan McIntyre added the comment:
I just posted a patch on issue 467924
(http://bugs.python.org/issue467924) that adds extract and extractall
methods. Recommend closing this issue unless the patch over there is
insufficient for some reason.
--
nosy: +alanmcintyre
Alan McIntyre added the comment:
I attached a patch with the following changes (as zipfile_extract.diff):
(1) Add a note to the docs (under writestr) about how the compression is
selected if a ZipInfo is passed as the zinfo_or_arcname parameter. If
anybody thinks it's a good idea to
Alan McIntyre added the comment:
Are the method renames/additions suggested in the original issue worth
doing? When I first started using this module, I found the
documentation easy and thorough enough to understand how to use it, so I
would vote for just leaving the ZipFile interface the way
Alan McIntyre added the comment:
The reported warning was being produced when writing the "end of central
directory record", in ZipFile.close().
Based on a little experiment with 70k test text files, the default
archiver in OS X appears to just use the number of files mod 64k in
Alan McIntyre added the comment:
Here's a patch that just uses the "mod 64k" approach. If I get time to
look at some other implementations, and find a better way to handle it,
I'll submit an update. Otherwise, maybe on bug day people can try it
out with a variety of archiv
Alan McIntyre added the comment:
Based on the ZIP spec (I'm using the one here:
http://www.pkware.com/documents/casestudies/APPNOTE.TXT), I'm inclined
to agree. There's a general note that says "All fields unless otherwise
noted are unsigned and stored in Intel low-byte:high
Alan McIntyre added the comment:
I just tried out this test with the trunk and 2.5.2 from svn (on OS X,
not sure if that might make a difference), and didn't get the reported
error. Since the issue has apparently been fixed at some point, is
there any reason not to close this
Alan McIntyre added the comment:
Since there's no reply about where ZIP files with appended 'garbage'
might come from, should this be closed? I agree with amk; it doesn't
seem wise to ignore incorrectly formatted files without a good reason.
On a related note, it seems that
New submission from Alan McIntyre:
The current behavior of zipfile._EndRecData is to look in the last 4k of
data in a file if it appears it might have an archive comment; this
results in flagging proper ZIP files with comments longer than ~4074
bytes as "not a ZIP file."
I plan on
Alan McIntyre added the comment:
Oh thanks, I meant to ask whether or not the run time was too long, but
forgot. Only running when -ulargefile is enabled seems fine to me. I
can tweak the patch for that if you'd like; moving it to test_zipfile64
should do that,
Alan McIntyre added the comment:
I just tried it on 2.5 and 2.6, since I didn't have the earlier versions
available. If I find some time I'll see if I can try it on 2.3 & 2.4;
maybe that will shed some light on whether it's been fixed or if is
something specific to Windows
Alan McIntyre added the comment:
Well I can't promise it will be swift, since my winter vacation ended
today, but I'll keep on top of it as best I can. :)
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Alan McIntyre added the comment:
Here's the first draft of a patch (zipfile-unsigned-fixes.diff) that
does a few things:
- Interpret fields as unsigned unless required (CRC, etc.)
- Corrects reading of ZIP files with large archive comments
- Replaces hard-coded structure sizes with module-
Alan McIntyre added the comment:
Thanks for the reminder, Eric; I'll include that and post the updated patch.
As a side note, on OS X, running regrtest with -uall or -ulargefile
still skips test_zipfile4 for some reason. I'll have a look at that
before submitting the next version of
Alan McIntyre added the comment:
Currently the extra field data is only parsed when it contains Zip64
extended information. It could probably be broken up into a list of
(id, data) pairs at a minimum for all data types, since the spec says
that's the structure that "should" be u
Alan McIntyre added the comment:
A fix for this is included in the patch for issue 1622.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1746>
__
___
Python-bugs-
Alan McIntyre added the comment:
Here's an updated patch (zipfile-unsigned-fixes2.diff) that contains
Eric's fixes. I also changed the structure for the Zip64 extension data
to be unsigned. I think this should cover all the deficiencies caused
by the improper use of unsigned values.
Alan McIntyre added the comment:
I just noticed that my changes for issue 1526 are included in this
patch. Eric, if you have time could you have a look at that issue and
see if you think I addressed it properly? If not I can back them out
into a separate patch for that issue
Alan McIntyre added the comment:
I just noticed that my changes for this issue are included in the patch
for issue 1622; if that gets committed then this issue should be closed.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Alan McIntyre added the comment:
Here's a quick patch that covers the issues mentioned in my post from
2007-05-09.
Added file: http://bugs.python.org/file9144/empty-zipfile.diff
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.or
Alan McIntyre added the comment:
I think you applied the wrong patch; the referenced revision doesn't
include the tests from zipfile-printdir-2.diff.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.or
Alan McIntyre added the comment:
It would seem that such a zip file is not consistent with the spec
(http://www.pkware.com/documents/casestudies/APPNOTE.TXT). My first
reaction is that we shouldn't accept behavior outside the spec unless
it's something that's done by m
Alan McIntyre added the comment:
I noticed that in the trunk, ZipFile._extract_member, at line 865, still
uses 777 (the default of os.makedirs) to create directories. I attached
a patch for it.
A quick grep shows that tarfile still uses the default permissions for
os.makedirs and mkdir
Alan McIntyre added the comment:
It seems like most of the methods on integers are for two-argument
operations (add, mul, div, etc.), while a lot of single-argument
operations are in the math module. If this gets added would it fit
better as a function in the math module?
I have to say a
Alan McIntyre added the comment:
>Except that hypot is not a one-liner, if you want to get edge cases
right.
Ah, true; thanks for pointing that out.
Should there be some upper limit on the argument math.factorial would
take? At the moment I can't think of any reason for picking a giv
New submission from Alan Brooks <[EMAIL PROTECTED]>:
Patch attached that escapes the executable name so this test doesn't fail.
--
components: Tests
files: test_subprocess-r61479.patch
keywords: patch
messages: 63883
nosy: lanny
severity: normal
status: open
title: test_subpr
Alan McIntyre <[EMAIL PROTECTED]> added the comment:
It's my fault the xmlrpc tests try to use non-blocking sockets. That
got added because sometimes failing tests would just sit there with the
server blocking until the entire test process got killed for running too
long.
There are
Changes by Alan Kennedy <[EMAIL PROTECTED]>:
--
nosy: +amak
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2452>
__
___
Python-bugs-list mailing
Alan McIntyre <[EMAIL PROTECTED]> added the comment:
Is there anything else that needs to be addressed before this can be
committed? At the moment I don't know of anything, just wanted to make
sure somebody wasn't waiting on me.
As a reminder, issues #1526 and #1746 should b
Alan Brooks added the comment:
I also get this exact same problem. Mac OS 10.5.6 on an Intel MacBook
trying to install the release version of 2.6.1. I found it was failing to
build _Res, but worked around by *not* using --enable-universalsdk.
--
nosy: +lanny
Alan Robertson added the comment:
There are a variety of different reasons this can fail, not just on MacOS. You
could give it a bad IP address of a server, etc. [That was my particular case].
The constructor should create an attribute 'socket' and initialize it to None
early on.
New submission from Alan Robertson :
When an exception "as" variable occurs, it deletes local variables with the
same name. This is certainly surprising, and doesn't appear to be a documented
behavior (but maybe I don't know where to look). The word "bug" come
Alan Robertson added the comment:
Thanks for your kind explanation. I may even vaguely remember seeing this
sometime in the past. Thanks much for your time!
--
___
Python tracker
<https://bugs.python.org/issue39
Alan Robertson added the comment:
On Wed, Jan 6, 2021, at 10:30 AM, Vinay Sajip wrote:
>
> Vinay Sajip added the comment:
>
> TBH as I said in the now-closed PR, using a NullSocket seems overkill.
> As mentioned in msg359594, it seems to make more sense to assign a
> s
Alan Robertson added the comment:
As far as I know, this only happens during shutdown. During shutdown it has
already removed the attribute as part of the teardown process. In this case
adding the attribute at the begining will do no good.
On Wed, Jan 6, 2021, at 10:30 AM, Vinay Sajip wrote
New submission from Alan Moore :
Using IDLE 3.9.1 on Arch Linux.
In IDLE I've selected the "classic unix" key set. It worked for a while, then
stopped registering key combinations for more than one key (e.g. Ctrl-x Ctrl-s).
Have tried creating a custom key set and manua
Alan Moore added the comment:
OK, it seems that closing all my firefox windows restored correct behavior to
IDLE. I can only guess that somehow firefox was eating the Ctrl-x.
Not sure if this is a firefox issue, a window manager issue, or an IDLE issue.
If you think it's not the l
Alan Moore added the comment:
An interesting note this morning, and again I don't know if this is actually an
IDLE bug; I had left IDLE running overnight and opened a new code window this
morning. Somehow IDLE "forgot" that Ctrl-N means "next line" and not "
Alan Moore added the comment:
Ok, sorry to keep poking at this issue, but I think I was too hasty in blaming
firefox.
As I previously mentioned, IDLE "forgot" that Ctrl-N meant "next line" and
reverted it to "new window". I fixed that behavior by chang
Alan Moore added the comment:
Spent some time today with IDLE and PDB, and I've ruled out any other program
on my system as the culprit:
- I can create a tkinter GUI that will respond to a binding like
and it works fine.
- In pdb, I can bind <> to a callback and it is getting
Change by Alan Briolat :
--
nosy: +alan.briolat
___
Python tracker
<https://bugs.python.org/issue40815>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Alan Iwi :
It is possible to make `queue.Queue` and `queue.SimpleQueue` objects iterable
by adding simple `__iter__` and `__next__` methods. This is to suggest adding
these methods to the existing `Queue` and `SimpleQueue` so that they are
iterable by default.
```
class
Alan Jenkins added the comment:
Here's a simple test case that fails on the main branch.
https://github.com/sourcejedi/cpython/commit/50184ea3b354fd775866d036ccee058ec6734927
> the patch assumes that python signal handler will be called *before* reading
> from self-pipe.
>
New submission from Alan Jenkins :
## Test program ##
import asyncio
import time
import os
import signal
import sys
# This bug happens with the default, ThreadedChildWatcher
# It also happens with MultiLoopChildWatcher,
# but not the other three watcher types.
#asyncio.set_child_watcher
Alan Jenkins added the comment:
There's one way to fix this in MultiLoopChildWatcher (but not
ThreadedChildWatcher). Make sure the waitpid() runs on the same thread that
created the subprocess. Prototype:
https://github.com/sourcejedi/cpython/c
Alan Jenkins added the comment:
Put the other way, if you wanted to fix this bug in ThreadedChildWatcher, and
go as far as allowing cancelling Process.wait(), followed by kill() /
send_signal(), then I think you need -
* siginterrupt(SIGCHLD, 1)
* not to mind about any random C code that
Change by Alan Coopersmith :
--
nosy: +alanc
___
Python tracker
<https://bugs.python.org/issue42173>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alan Yorinks added the comment:
Hi Carol,
Thanks for the update. I retested on Python 3.7 and the problem
seems to have been resolved some where along the way.
BTW, I am using MicroPython on an ESP8266 remotely controlled from a
Python program on a PC. You can read about it here:
https
Change by Alan Huang :
--
pull_requests: +11509, 11510
___
Python tracker
<https://bugs.python.org/issue35045>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Alan Huang :
--
pull_requests: +11509
___
Python tracker
<https://bugs.python.org/issue35045>
___
___
Python-bugs-list mailing list
Unsubscribe:
1 - 100 of 256 matches
Mail list logo
