Martin v. Löwis added the comment:
I think Raymond's original concern still applies: The macros do add to the
learning curve. I would personally expect that Py_REPLACE(op, op2) does an
INCREF on op2, but it does not.
Explicit is better than implicit.
--
nosy: +l
Martin v. Löwis added the comment:
I'm not sure we are looking at the same code base, I look at
http://hg.python.org/cpython/file/b56ce3410ca6/Lib/collections/__init__.py#l401
and ISTM that collections.Counter is *not* implemented in C. Also, according to
http://hg.python.org/cpython
Martin v. Löwis added the comment:
It's certainly possible to write a "proper" dealloc - just call PyObject_Del
directly. This is correct if the type isn't subclassable, and works if it
actually isn't subclassed, or if the subclass object can also be released
through
Martin v. Löwis added the comment:
If the set of slots gets extended, extensions would have to opt-in to use the
newer slots, i.e. the availability of slot numbers should be conditional at
compile-time.
Returning 0 for slots not supported in a version seems fine to me as well
(after
Martin v. Löwis added the comment:
See my review in Rietveld.
--
___
Python tracker
<http://bugs.python.org/issue20414>
___
___
Python-bugs-list mailing list
Unsub
Martin v. Löwis added the comment:
It seems fine to me to link pythonXY.dll with wsock32.dll. This is a standard
library in Windows NT+, so there is no need to avoid linking with it.
I also now agree that any change that we may make is too big for 3.4, so I
propose to defer any action on this
Martin v. Löwis added the comment:
I think the change should be reverted, and the original issue closed as "won't
fix".
Alternatively, to fix the original issue, the specific linker warning could be
suppressed.
--
___
Python
Martin v. Löwis added the comment:
For the record, format 3 was added through issue16475, format 4 was added
through issue19219.
In msg175962, Kristjan argued that there is no reason _not_ to share int
objects, e.g. across multiple code objects. Now it seems that this argument is
flawed
Martin v. Löwis added the comment:
I propose a more general solution: add a function PyType_GetSlot.
--
keywords: +patch
Added file: http://bugs.python.org/file33762/getslot.diff
___
Python tracker
<http://bugs.python.org/issue17
Changes by Martin v. Löwis :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue17432>
___
___
Python-bugs-list mailing list
Unsubscrib
Martin v. Löwis added the comment:
One sub issue then is naming: _overlapped renamed
Overlapped.GetOverlappedResult to Overlapped.getresult. I think the _winapi
name is better, since all other methods also use Windows API function names
Martin v. Löwis added the comment:
I think overlapped.c should be merged back to _winapi (apparently, it started
with code from _winapi). overlapped has a number of functions that aren't in
_winapi, but should be (IMO). Then, the _overlapped module should be dropped.
Of course, this may
Martin v. Löwis added the comment:
Lars, would you like to take a look?
--
___
Python tracker
<http://bugs.python.org/issue18321>
___
___
Python-bugs-list mailin
Martin v. Löwis added the comment:
I completely lost track which problem is being solved here. Is it still "IDLE
crashes when pasting non-BMP unicode char on Py3"? If so, how is this patch
solving it?
IMO, the issue shouhldn't have been reopened. Instead, a new issue shoul
Martin v. Löwis added the comment:
Since 3.2 has seen its last bugfix release, this won't be added to 3.2 anymore.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.
Martin v. Löwis added the comment:
This is now fixed for 3.3 and 3.4. Sorry it took so long.
--
___
Python tracker
<http://bugs.python.org/issue17432>
___
___
Changes by Martin v. Löwis :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue19526>
___
___
Python-bugs-list
Martin v. Löwis added the comment:
The procedure to obtain the new API was this:
* write a C file
#define Py_LIMITED_API
#include
* compile this with gcc -E | grep -v '#'
* diff and inspect the two preprocessor outputs. Ideally, they come out empty,
but they currently sh
Martin v. Löwis added the comment:
I agree with Serhiy. This use case is not "supported", i.e. it getting this
compiler warning if you implement a function from the interpreter core is not a
bug.
The work-around that he suggests sounds reasonable to me.
--
nosy: +loewis
Martin v. Löwis added the comment:
Thanks for the report. Restored in 8a3718f31188
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
I have now removed the aha code.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Changes by Martin v. Löwis :
--
priority: release blocker -> normal
___
Python tracker
<http://bugs.python.org/issue19347>
___
___
Python-bugs-list mai
Martin v. Löwis added the comment:
I just looked at the hash-forum archives (*)
http://cio.nist.gov/esd/emaildir/lists/hash-forum/msg02809.html
which says that they plan to publish the draft "soon after Christmas".
They also indicate how the padding open issue might get resolved (a
Changes by Martin v. Löwis :
--
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/issue17997>
___
___
Python-bugs-list mai
Martin v. Löwis added the comment:
Ok, this this remains a release blocker. I'm still +1 for removing it, and I'm
-0 for removing it just before the release candidate. AFAICT, there is *zero*
(.1) chance that it actually becomes a NIST standard before the Python
relea
Martin v. Löwis added the comment:
Demoting this from release blocker: apparently, the release-blocking property
was only intended for 2.6.9, which has been released.
--
nosy: +loewis
priority: release blocker -> critical
___
Python tracker
&l
Martin v. Löwis added the comment:
I suggest that a documentation issue cannot be a release blocker. Most people
read the documentation online, and will read an update once it is available.
--
nosy: +loewis
___
Python tracker
<h
Martin v. Löwis added the comment:
I propose to downgrade this from "release blocker" again. "prefer to have
everything we can sorted" is IMO not a sufficient rationale to block the
release; if taken literally, 3.4 could never ever release since it doesn't have
eve
Martin v. Löwis added the comment:
test_venv now passes on that buildbot, apparently since PIP 1.5 has fixed the
issue, and is now bundled with Python.
--
nosy: +loewis
resolution: -> fixed
status: open -> closed
___
Python tracker
Martin v. Löwis added the comment:
Just to clarify the status of this issue: it *only* blocks 3.2.
--
priority: release blocker -> normal
___
Python tracker
<http://bugs.python.org/issu
Martin v. Löwis added the comment:
I'm going to remove sha3 from the trunk tomorrow unless I hear otherwise.
Python shouldn't implement something called "sha3" until SHA-3 actually is a
standard. According to the current NIST timeline, the comment period on the
draft FIPS
Martin v. Löwis added the comment:
BTW, congrats to issue 20,000.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue2>
___
___
Python-bug
Martin v. Löwis added the comment:
As a further datapoint, it would be good to find out whether any of you has NTP
enabled, and if so, against what time server. To find out, open the clock
settings ("Datums- und Uhrzeiteinstellungen ändern"), and go to NTP tab
(&qu
Martin v. Löwis added the comment:
The command works fine; I have now integrated it into the installer.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
But it's not in git, AFAICT,
https://github.com/pypa/pip/blob/1.5.X/pip/__init__.py
still has "1.5rc4" in 93820f5e37, and pypi.python.org/pypi/pip still points to
1.4.1. So what do you mean by
Martin v. Löwis added the comment:
The only "known" (to me) release date of PIP is documented on
http://www.pip-installer.org/en/latest/news.html
"Beta and final releases of 1.5 are planned for end of 2013."
Apparently, this hasn't happened, either. Something *mus
New submission from Martin v. Löwis:
According to PEP 453, the integration of pip must be reverted if PIP 1.5 was
not released by December 29. AFAICT, this hasn't happened. So is it ok that I
revert the PIP integration by Saturday?
--
messages: 207149
nosy: dstufft, larry, l
Martin v. Löwis added the comment:
>From what I read, it appears that the SO posting is plain wrong. Consider, for
>example,
https://developer.gnome.org/glib/stable/glib-Character-Set-Conversion.html#g-filename-to-utf8
# Converts a string which is in the encoding used by GLib for fil
Martin v. Löwis added the comment:
Nick: which glib functions are you specifically referring to? Many of them
don't deal with strings at all, and of those that do, many are
encoding-agnostic (i.e. it is correct to claim that they operate on UTF-8, but
likewise also correct that they op
Martin v. Löwis added the comment:
Bike-shedding: instead of jsonb, make it json.bytes. Else, it may get confused
with other protocols, such as "JSONP" or "BSON".
--
nosy: +loewis
___
Python tracker
<http://bug
Martin v. Löwis added the comment:
I think this issue can be resolved by reducing the loss to the maximum
available precision; it's about time.time(), after all.
I don't think pygettimeofday can change; gettimeofday traditionally has only
µs. So the issue really is that it
Martin v. Löwis added the comment:
+1
--
___
Python tracker
<http://bugs.python.org/issue19668>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
I agree with Nick; this is really a minor issue and we can resolve it here in
the tracker. I missed the place in the PEP where it said that the option should
be checked, since it mentions changes to the installers twice, and in
"implementation strategy
Martin v. Löwis added the comment:
> AssertionError: 1385161652120374900 not greater than or equal to
> 1385161652120375500
> Anything coming from T() would have "000" at the end, not "900" or "500".
But "900" *is* "000" :-)
A. t1
Martin v. Löwis added the comment:
This "clean uninstall" is a convention at least on Windows and Linux (except
that on Linux, you have the option of leaving manually-edited configuration
files behind if you wish).
An MSI can indeed invoke commands on uninstall (preferably of cou
Martin v. Löwis added the comment:
Tim,
> First, if *both* timestamps went through this code, it's monotonically
> non-decreasing. ts1 < ts2 [...] but T(ts1) > T(ts2) can't happen
It's as Steve says (and I tried to say before): What *can* happen is that ts1 >
Martin v. Löwis added the comment:
One "obvious" conversion error is this code from
http://hg.python.org/cpython/file/4101bfaa76fe/Python/pytime.c#l35
microseconds = large.QuadPart / 10 - 116444736;
This discard the 100ns part of the current time, rounding it down to the
Martin v. Löwis added the comment:
OTOH, a time.time() in units of 100ns needs 53.6 bits, so it should "almost"
fit.
--
___
Python tracker
<http://bugs.python.o
Martin v. Löwis added the comment:
Looking at the ReactOS sources, it appears that Windows doesn't do any
rounding, so it's all Python's fault. Windows keeps its system time (in
KI_USER_SHARED_DATA) in essentially a FILETIME represenation (i.e. units of
100ns since 1601), and
Martin v. Löwis added the comment:
>> Then, the utime call in step 4 asked to set this to
> You mean step 3, right? ("date back 10s")
No, I really meant step 4 (touch). The second touch call *really* steps
backwards. I don't find that very surprising, since it is actua
Martin v. Löwis added the comment:
I think I found the problem. In one run, the current time (as reported by
time.time()) was
1385154213.291315
On the first touch call (in step 1), the file is not there, and gets its
current time internally from the system (not sure which part exactly
Martin v. Löwis added the comment:
IIUC, the sequence of events is this:
1. touch
2. read old_mtime
3. date back 10s
4. touch
5. read mtime
So the time stamp that is set in step 3 is never read, correct? So there is no
test that it is newer than the 10s-old-stamp, but only newer then the
Martin v. Löwis added the comment:
I don't quite understand the test: why is it dating back the file by 10s, but
then not using the dated-back time stamp for anything?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
-1. The macro name doesn't claim the cast to be safe, i.e. it's not
"Py_SAFELY_DOWNCAST", but "safe downcast", i.e. it's an assertion that the cast
actually has been verified as be
Martin v. Löwis added the comment:
Attached is a patch that takes a different approach to framing, putting it into
an optional framing layer by means of a buffered reader/writer.
The framing structure is the same as in PEP 3154; a separate PYFRAMES magic is
prepended to guard against protocol
Martin v. Löwis added the comment:
I have now committed the changes to the installer. A demo installer can be
found at
http://prof.beuth-hochschule.de/fileadmin/user/mvon_loewis/python-3.4.16027.msi
I'm skeptical about the lack of proper deinstallation: per convention,
uninstallati
Martin v. Löwis added the comment:
I'm currently blocked on a discrepancy of this request and PEP 453.
You are asking me to run "ensurepip --upgrade", whereas the PEP asks for an
option to install the bundled pip (i.e. a mere ensurepip). Which of these
Martin v. Löwis added the comment:
I missed the original message. I'll try to come up with a patch.
--
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
IIUC, the current implementation strategy is to check the wheels into source
control. If so, what's to be done in the installer (except for making sure that
the wheels get bundled and installed into the msi, which it should do by
de
Martin v. Löwis added the comment:
I'd be +0 on extracting common identifiers. I see a slight increase of
readability, and expect a slight reduction of memory usage, and a tiny
reduction in runtime. It's not really worth the effort, but I fail to see that
it causes harm.
I see n
Martin v. Löwis added the comment:
Wouldn't it be better if linking _testembed generated _testembed.exp instead of
generating python.exp? I hope using $@.exp somehow could help. Hard-coding the
name of the export file sounds like a flaw in the first place.
--
nosy: +l
Martin v. Löwis added the comment:
Well, that was one of the motivations of introducing this Py_IDENTIFIER
machinery: to be able to cleanup at the end (unlike the static variables that
were used before, which couldn't be cleaned up).
--
___
P
Martin v. Löwis added the comment:
Thanks for the patch.
Note: moving all identifiers would not have made a difference. They are static
variables, so from a run-time point of view, there is no difference whether
they are inside or outside of functions.
--
resolution: -> fixed
sta
Martin v. Löwis added the comment:
Victor: There already *is* a cleanup function that clears all allocated
identifier memory at interpreter shutdown. Please read the source.
--
___
Python tracker
<http://bugs.python.org/issue19
Martin v. Löwis added the comment:
Another matter of style: I suggest alphabetical order for the identifiers, at
least when the list gets long.
--
___
Python tracker
<http://bugs.python.org/issue19
Martin v. Löwis added the comment:
As a matter of style, I suggest that all identifiers are moved to the top of a
file if some of them live there. IOW, it's (IMO) unstylish to have some at the
top, and some in the middle (although this works perfectly fine, of course).
--
Martin v. Löwis added the comment:
tok->enc and tok->encoding should always have the same value, except that
tok->enc gets set earlier.
tok->enc is used when parsing from strings, to remember what codec to use. For
file based parsing, the codec object created knows what encoding
Martin v. Löwis added the comment:
It's certainly possible to update SQLite without rebuilding Python. Just
replace sqlite3.dll with a newer version.
--
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
LGTM
--
___
Python tracker
<http://bugs.python.org/issue19433>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
The patch looks good to me. The stable ABI was originally intended for Windows
only, where the functions are guaranteed to be included in python3.dll (as the
.def file references them); they are included in python3X.dll as link.exe
doesn't do the same o
Martin v. Löwis added the comment:
I agree that the comment can be removed. If the code is (now) statically
type-safe, there is no point in keeping it.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue19
Martin v. Löwis added the comment:
It's at https://mail.python.org/mailman/listinfo/python-list
--
___
Python tracker
<http://bugs.python.org/issue19210>
___
___
Martin v. Löwis added the comment:
Stephen: do you agree that your example actually doesn't demonstrate the issue
you originally reported?
Your first to print statements don't actually print a tuple, whereas the latter
two do, and the string gets always escaped in the tuple, and
Martin v. Löwis added the comment:
Marc-Andre: please don't confuse "use in major operating systems" with "major
use in operating systems". I agree with Antoine that UTF-16 isn't widely used
on Windows, despite notepad and Office supporting it. Most users on Wind
Martin v. Löwis added the comment:
According to
http://stackoverflow.com/questions/17399302/how-can-i-detect-windows-8-1-in-a-desktop-application
another strategy is to directly read the version out of the registry, from
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
(values
Martin v. Löwis added the comment:
tim.peters: looking at the implementation of the proposed annoying functions
with names like IsWindows8Point1OrGreater, it turns out that they all go back
to VerifyVersionInfoW, which is available since W2k (but still doesn't tell the
actual ve
Martin v. Löwis added the comment:
Documenting the pydotorg setup is a field of ongoing discussions. If you ask
three people involved, you get three answers where this should be documented,
with no chance for consensus.
>From an infrastructure point of view, it is up to the infrastruct
Martin v. Löwis added the comment:
"make touch" (or "hg touch") certainly should be mentioned. Details of the
buildbot configuration need not.
Publishing the buildbot configuration file might be useful, except that it also
contains all the builder passwords, which should
Martin v. Löwis added the comment:
I have now updated the master.cfg to make buildbottouch a separate build step.
--
___
Python tracker
<http://bugs.python.org/issue19
Martin v. Löwis added the comment:
Here is a patch that backdates outputs 1s after their youngest input (and
sleeps if necessary to avoid producing files in the future).
With that, I get
lap-le:3k loewis$ touch Parser/asdl_c.py ;date;make touch;date
Mo 30 Sep 2013 15:29:21 CEST
hg --config
Martin v. Löwis added the comment:
I see two solutions, both involving to track the newest timestamp that needs to
pass.
a) touch the file to have a time stamp in the future. make might complain,
though.
b) sleep until a second has passed, then touch (actually, sleep of 100ms
multiple times
Martin v. Löwis added the comment:
Pepijn: Can you please submit the contributor form?
http://www.python.org/psf/contrib/contrib-form/
--
___
Python tracker
<http://bugs.python.org/issue19
Martin v. Löwis added the comment:
Antoine: in (my experience of) memory analysis, the size of a single object is
mostly irrelevant. If you need to know how much memory something consumes, you
typically want to know the memory of a set of objects. So this is the case that
really must be
Martin v. Löwis added the comment:
> The problem is that that definition isn't helpful.
> If we ever change itertools.tee to use non-PyObjects internally, s
> suddenly its sys.getsizeof() would have to return much larger numbers
> despite visible behaviour not having changed at
Martin v. Löwis added the comment:
One issue at a time, please, and issue18960 is already its own issue.
In any case, item "1" in "Concepts" of PEP 263 is clear that any deviation from
the declared encoding should ca
Martin v. Löwis added the comment:
Terry: the comment isn't self-contradictory. Instead, the file constitutes a
perfectly fine iso-8859-15 byte sequence (albeit a meaningless one: any byte
sequence is perfectly fine iso-8559-15, and, in a comment, any characters are
allowed by the P
Martin v. Löwis added the comment:
It turns out that TortoiseHg was showing the files as modified. I have now
"reverted" my local changes, so this should be fine now. I was somewhat under
time pressure when making the release, so I didn't notice then (and TortoiseHg
seems to
Martin v. Löwis added the comment:
Is there an easy way to recheck the entire tree, possibly reverting any files
that don't match the content that they should have? I'd rather not throw the
tree away.
--
___
Python tracker
<http://bu
Martin v. Löwis added the comment:
Thanks!
--
___
Python tracker
<http://bugs.python.org/issue17684>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
Simplicity is in the eye of the beholder, yet... you need to remember the break
when *writing* the code, so the loop might be more difficult to write (but
then, I need to remember/lookup the function name and parameters for
coalesce)... when reading the code
Martin v. Löwis added the comment:
Nick: that the code is difficult to decipher is really the fault of functional
programming, which is inherently difficult to decipher (since last function
applied is written first).
Explicit iteration is easier to read. I would write Hynek's example as
Martin v. Löwis added the comment:
I also think it should go to itertools.
I also found the name "first" confusing, in particular since it means what
Serhiy assumes in LISP, which might be familiar to people interested in
functional list processing. Also, Ruby and Smalltalk use
Martin v. Löwis added the comment:
Note that 3.4 will need a different patch, due to issue17684.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue18
Martin v. Löwis added the comment:
Charles-Francois: why did you commit this to default only, and not to 3.3?
(see also issue18651)
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue17
Martin v. Löwis added the comment:
Thanks for the report. This is now fixed on the active branches.
--
nosy: +loewis
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
I have now added the uuid.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
Thanks for the patch. It works fine (with the expected limitation that you need
to restart running shells for this to take effect).
--
resolution: -> fixed
status: open -> closed
___
Python tracker
Martin v. Löwis added the comment:
Nobody has contributed a patch in five years, so it apparently is pretty hard.
--
___
Python tracker
<http://bugs.python.org/issue3
Martin v. Löwis added the comment:
This is not true. Installing the modules into the SxS folder using the Merge
Module (msm) is also a recommended way of installing the DLLs.
I fail to see a problem in this report.
--
nosy: +loewis
___
Python
Martin v. Löwis added the comment:
Julien: I propose to resolve this issue in the same way as we have done
previously with analysis tools (with some unfortunate exceptions).
Somebody motivated enough (hopefully you) agrees to initially study the tool
output, and ideally also then agrees to
301 - 400 of 4778 matches
Mail list logo
