[issue46700] wrong nomenclature (options vs. arguments) in argparse

2022-02-12 Thread mirabilos
mirabilos added the comment: Hm, the change helps indeed. I did this in my code: p = argparse.ArgumentParser(description='…', add_help=False) g = p.add_argument_group('Options') g.add_argument('-h', action='help', help='show this help me

[issue46701] cannot use typographical quotation marks in bug description

2022-02-09 Thread mirabilos
New submission from mirabilos : When trying to use typographical quotation marks (U+201C, U+201D) in the Comment field trying to submit a bug here, I get a red-background error message saying: Error: 'utf8' codec can't decode bytes in position 198-199: invalid co

[issue46700] wrong nomenclature (options vs. arguments) in argparse

2022-02-09 Thread mirabilos
New submission from mirabilos : The argparse documentation and tutorial as well as its default option groups speak of "positional arguments" and "optional arguments". These are not used correctly, though. Elements of the argument vector (past item #0) are distingu

[issue46695] _io_TextIOWrapper_reconfigure_impl errors out too early

2022-02-09 Thread mirabilos
New submission from mirabilos : The following is not possible: with open('/tmp/x.ssv', 'r', newline='\n') as f: f.readline() # imagine a library call boundary here if hasattr(f, 'reconfigure'): f.reconfigure(newline='\n')

[issue23332] datetime.isoformat() -> explicitly mark UTC string as such

2015-02-27 Thread mirabilos
mirabilos added the comment: Hm, RFCs are just RFCs and not standards, they can recommend whatever they want, and they can (and do) contradict each other. I’ve seen things (mostly related to eMail and PIM synchronisation) that require ‘Z’ for UTC proper. Additionally, +00:00 can be UTC, but

[issue23332] datetime.isoformat() -> explicitly mark UTC string as such

2015-01-28 Thread mirabilos
mirabilos added the comment: There’s another minor bug here: UTC should append “Z”, not “+00:00”, which other timezones at that offset can do. Agreed about no timezone being “floating” time in many instances, e.g. the iCalendar format uses that. -- nosy: +mirabilos

[issue22187] commands.mkarg() buggy in East Asian locales

2014-09-05 Thread mirabilos
mirabilos added the comment: Just for the record, please do not assume all shells behave like GNU bash. -- nosy: +mirabilos ___ Python tracker <http://bugs.python.org/issue22

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

2014-04-04 Thread mirabilos
mirabilos added the comment: Andreas Schwab dixit: >The fixed version is here: git://git.code.sf.net/p/aranym/code That’s a source repository. I was asking for released tarballs that have been packaged. But clearly I have been outvoted by the m68k porters. So please feel free to go ahead

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

2014-04-04 Thread mirabilos
mirabilos added the comment: Stefan Krah dixit: >If the asm instructions silently fail, I'd say add a test to ./configure >that detects the broken versions of the emulator in question. No, the problem is at runtime: Debian is a binary distro, and thus, packages can get built and

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

2014-04-04 Thread mirabilos
mirabilos added the comment: Andreas Schwab dixit: >Finn Thain writes: > >>Sorry, what? You seek to veto an upstream Python bug fix because it will >>lead to correct binaries that a certain emulator can't handle? That Yes, because of the value ARAnyM has for Lin

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

2014-04-03 Thread mirabilos
mirabilos added the comment: Andreas Schwab dixit: >There is no excuse for using a broken emulator. Sure, if nobody releases a fixed version… and even then, there’s got to be a grace period. I say that if you break ARAnyM you kill off Debian/m68k on ARAnyM (and I’ll have to shut down

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

2014-04-03 Thread mirabilos
mirabilos added the comment: Andreas Schwab dixit: >Andreas Schwab added the comment: > >> Enabling this *will* break Python on Linux/m68k > >??? It will not of course, it will *fix* it. You have no idea what you are >talking about. No: it will break Debian/m68k whic

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

2014-04-03 Thread mirabilos
mirabilos added the comment: Veto on m68k-float-prec.patch for Linux/m68k for now. Reasoning is same as in #18062 (thanks skrah for linking it): Enabling this *will* break Python on Linux/m68k on the most widespread emulator in all released versions of that emulator (ARAnyM) because the

[issue18062] m68k FPU precision issue

2013-05-26 Thread mirabilos
mirabilos added the comment: Eero Tamminen dixit: >> > Now as additional data point, UAE/WinUAE/etc. would be interesting. > >I built the test with fpu_control.h header from eglibc, using >Sparemint GCC 2.9.5 (with 2010 binutils) and MiNTlib. When it's Nice ;) >I.e

[issue18062] m68k FPU precision issue

2013-05-26 Thread mirabilos
mirabilos added the comment: Laurent Vivier dixit: > For the "etc" ;-) , in Qemu, I have: Hm, I thought qemu did not emulate an MMU? bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited

[issue18061] m68k Python 3.3 test results

2013-05-26 Thread mirabilos
mirabilos added the comment: Serhiy Storchaka dixit: >> >Do you run tests as root? >> Yes. > >Well, this is issue17746. OK, I’ll re-run the tests as regular user (need to create one… ☺) and with all those fixes applied, then we’ll have a look again. (This will t

[issue18062] m68k FPU precision issue

2013-05-26 Thread mirabilos
mirabilos added the comment: Laurent Vivier dixit: > BTW, the result on a real CPU (68040) is : 68881 even ;-) > test#1 fail: 1.0E+00 > test#2 fail: 1.00040E+16 > changing FPU control word from to 0080 => 0080 > test#1 good: 1.000

[issue18062] m68k FPU precision issue

2013-05-26 Thread mirabilos
mirabilos added the comment: Mark Dickinson dixit: >If there are tests failing with the 'legacy' mode, that may just >indicate buggy tests that haven't been properly marked as depending on >the short float repr. (E.g., by decorating with I think that’s what we’re se

[issue18062] m68k FPU precision issue

2013-05-25 Thread mirabilos
mirabilos added the comment: Stefan Krah dixit: >> fixing this in general would allow keeping the FPUCW on i387 unchanged too. > >Actually dtoa.c (which is used on i387) explicitly requires to change >the control word. Right. By fixing the “older” code, i386 is not required to c

[issue18062] m68k FPU precision issue

2013-05-25 Thread mirabilos
mirabilos added the comment: mirabilos dixit: >mirabilos added the comment: >Yes, that’s precisely what’s not working on the most widespread >emulator, at the very least. (I have working code for that, in >three(!) variants, but it just ignores those requests to change >precisio

[issue18061] m68k Python 3.3 test results

2013-05-25 Thread mirabilos
mirabilos added the comment: Serhiy Storchaka dixit: >About test_shutil failure. What filesystem are used? /dev/root on / type ext3 (rw,noatime,errors=remount-ro,user_xattr,acl,barrier=1,nodelalloc,data=ordered) >Do you run tests as root? Yes. >Is m68k big-endian? Yes: ILP32 big-

[issue18063] m68k struct alignment issue vs. PyException_HEAD

2013-05-25 Thread mirabilos
mirabilos added the comment: Okay, then I’ll ignore those for now. Thanks! -- ___ Python tracker <http://bugs.python.org/issue18063> ___ ___ Python-bugs-list m

[issue18063] m68k struct alignment issue vs. PyException_HEAD

2013-05-25 Thread mirabilos
mirabilos added the comment: Include/unicodeobject.h has the same problem; its “state” member currently allocates 8 bit, which is only padded up to 16 bit. asciifields = "nnbP" makes that work too; result attached as after-patch-2.txt Will just changing the testsuite to match

[issue18063] m68k struct alignment issue vs. PyException_HEAD

2013-05-25 Thread mirabilos
mirabilos added the comment: Sure (attached). -- Added file: http://bugs.python.org/file30374/after-patch-1.txt ___ Python tracker <http://bugs.python.org/issue18

[issue18062] m68k FPU precision issue

2013-05-25 Thread mirabilos
mirabilos added the comment: > > We do not want to change it to 64-bit because it’s not supported > > in all environments. > Does this also apply to changing the precision temporarily? Yes, that’s precisely what’s not working on the most widespread emulator, at the very least.

[issue18063] m68k struct alignment issue vs. PyException_HEAD

2013-05-25 Thread mirabilos
mirabilos added the comment: >>> struct.calcsize("PPnP5Pb") 37 >>> struct.calcsize("PPnP5Pi") 40 >>> struct.calcsize("PPnP5Pb0P") 38 >>> struct.calcsize("PPnP5Pi0P") 40 I already offered to re-run tests in verbos

[issue18063] m68k struct alignment issue vs. PyException_HEAD

2013-05-25 Thread mirabilos
mirabilos added the comment: Yes, that's in test_sys. -- ___ Python tracker <http://bugs.python.org/issue18063> ___ ___ Python-bugs-list mailing list Unsubsc

[issue18061] m68k Python 3.3 test results

2013-05-25 Thread mirabilos
mirabilos added the comment: OK sure; I put the two I identified already into issue18062 and issue18063; we can then retry here after those get fixed (I’ll just resend results from a patched tree then). -- ___ Python tracker <h

[issue18063] m68k struct alignment issue vs. PyException_HEAD

2013-05-25 Thread mirabilos
New submission from mirabilos: Hi, splitting off issue18061 by request of pitrou: struct alignment issue: PyException_HEAD misses explicit alignment instruction; uses invalid (non-portable) alignment assumptions. ABI change on m68k. See issue18061 for details. -- components

[issue18062] m68k FPU precision issue

2013-05-25 Thread mirabilos
New submission from mirabilos: Hi, splitting off issue18061 by request of pitrou: FPU precision issue: MC68881 FPU, similar to Intel 80387, uses 80-bit precision internally. We do not want to change it to 64-bit because it’s not supported in all environments. Can probably be reproduced on

[issue18061] m68k Python 3.3 test results

2013-05-25 Thread mirabilos
New submission from mirabilos: Hi! As a followup to http://bugs.python.org/issue17237 I took the tree of Python 3.3.1 I had compiled already, with the patch that was eventually committed for issue17237, and ran the testsuite. Since I used configure flags to get it compiled quickly, it

[issue17237] m68k aligns on 16bit boundaries.

2013-05-11 Thread mirabilos
mirabilos added the comment: Antoine Pitrou dixit: >(note, on 2.7, it's "python -m test.regrtest") That indeed does things. So I had mistaken them for the same problem. >Ah, that's because the system Python install doesn't include the test >suite. Perhaps

[issue17237] m68k aligns on 16bit boundaries.

2013-05-11 Thread mirabilos
mirabilos added the comment: Antoine Pitrou dixit: >"python -m test" (with any options you might like), but we don't No, I tried that (as it was the only thing I could find on the ’net as well) on an i386 system and only get: tglase@tglase:~ $ python2.7 -m test /usr/bin/py

[issue17237] m68k aligns on 16bit boundaries.

2013-05-11 Thread mirabilos
mirabilos added the comment: Thanks Antoine! Now, for “finishing up” this… to follow up on Stefan’s comment… is there any way I can run the testsuite from an installed Python (from the Debian packages)? (I build the packages with disabled testsuite, to get the rest of the system running

[issue17237] m68k aligns on 16bit boundaries.

2013-05-11 Thread mirabilos
mirabilos added the comment: Right, keeping it simple helps in preventing accidents, and the code block looks full of magic enough as-is. Maybe add a comment block that says: /* * m68k is a bit different from most architectures in that objects * do not use "natural alignment" - f

[issue17237] m68k aligns on 16bit boundaries.

2013-05-10 Thread mirabilos
mirabilos added the comment: + dest is always aligned on common platforms + (if sizeof(PyASCIIObject) is divisible by SIZEOF_LONG). Actually, that’s the part that is

[issue17237] m68k aligns on 16bit boundaries.

2013-05-10 Thread mirabilos
mirabilos added the comment: I’m currently thinking this patch. (Will need another day or so for compiles to finish, though.) -- Added file: http://bugs.python.org/file30210/python3.3_3.3.1-1+m68k.1.debdiff ___ Python tracker <http://bugs.python.

[issue17237] m68k aligns on 16bit boundaries.

2013-05-10 Thread mirabilos
mirabilos added the comment: Currently 22; it will increase to 24 if a few more bits are added. That’s why I said it’s “fragile” magic. -- ___ Python tracker <http://bugs.python.org/issue17

[issue17237] m68k aligns on 16bit boundaries.

2013-05-10 Thread mirabilos
mirabilos added the comment: file30203/ascii_decode_nonaligned.patch is potentially a nop (the struct being a multiple of, in the m68k case 4, bytes is not an indicator of whether to skip it). I think we can be bold and put #if !defined(__m68k__) and #endif around the entire block and

[issue17237] m68k aligns on 16bit boundaries.

2013-05-10 Thread mirabilos
mirabilos added the comment: Antoine: precisely. Serhiy: sure. The times are now in msec per loop. I did three subsequent runs, so the second and third tuple are cache-warm. Without assert: (89,88), (87,87), (89,86) Without block : (79,78), (78,78), (79,78) And in a second run: Without

[issue17237] m68k aligns on 16bit boundaries.

2013-05-10 Thread mirabilos
mirabilos added the comment: Hi again, sorry for being a bit late in following up to this. Here are the results for the two runs you requested; these were done on the same machine, intermixed (the first one cache-clean, the second and third run subsequently (so that the third run is cache

[issue17237] m68k aligns on 16bit boundaries.

2013-02-20 Thread mirabilos
mirabilos added the comment: Serhiy Storchaka dixit: >> Which tree should I build? A release (if so, which)? Or >> some CVS branch? > >It doesn't matter. Erm, still, which one do I build? Not 3.2 because it obviously works, at least as packaged in Debian. bye, //mirab

[issue17237] m68k aligns on 16bit boundaries.

2013-02-20 Thread mirabilos
mirabilos added the comment: Serhiy Storchaka dixit: >mirabilos, if you are motivated enough, do the following. Compile two >Python executables - one with deleted assert, and second with deleted >a block between "#if SIZEOF_LONG <= SIZEOF_VOID_P" and "#endif". Ru

[issue17237] m68k aligns on 16bit boundaries.

2013-02-19 Thread mirabilos
mirabilos added the comment: @pitrou: As for performance, 2-byte and 4-byte are the same on m68k, given that they usually have RAM which doesn’t benefit from that kind of alignment, and systems that are structured accordingly. The “best” cpp define I don’t know, but my system defines __m68k__

[issue17237] m68k aligns on 16bit boundaries.

2013-02-19 Thread mirabilos
mirabilos added the comment: @skrah: “I don't think we should support this platform officially.” Please don’t break what works. We have almost complete (about three quarters of roughly 10'000 source packages) Debian unstable working on m68k, with several versions of Python in u