Changes by Jeroen Van Goey :
--
hgrepos: -207
___
Python tracker
<http://bugs.python.org/issue18912>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Van Goey added the comment:
Patch for Python 2.7.4 attached
--
keywords: +patch
Added file: http://bugs.python.org/file31571/2.7itertoolsmodule.c.patch
___
Python tracker
<http://bugs.python.org/issue18
Jeroen Van Goey added the comment:
Patch for Python 3.4.0a1 attached
--
Added file: http://bugs.python.org/file31572/3.4itertoolsmodule.c.patch
___
Python tracker
<http://bugs.python.org/issue18
New submission from Jeroen de Jong:
I ma trying to find a way to round correctly. So far I get unexpected results
for some values.
--
components: Windows
files: Rounding.py
messages: 222444
nosy: jeroen1225
priority: normal
severity: normal
status: open
title: Rounding properly
type
New submission from Jeroen Van Goey:
The header of a cookie file generated by _MozillaCookieJar.py contains a link
to the spec: http://www.netscape.com/newsref/std/cookie_spec.html
This URL no longer exists (redirects to the AOL homepage). Attached patch
replaces the link with a mirror where
Jeroen Van Goey added the comment:
Added patch file for Python 3.3
--
Added file: http://bugs.python.org/file33197/cookiejar.diff
___
Python tracker
<http://bugs.python.org/issue20
New submission from Jeroen Van Goey:
I installed Python 3.6 from J Fernyhough's PPA by doing
sudo add-apt-repository ppa:jonathonf/python-3.6
sudo apt-get update
sudo apt-get install python3.6
I made a string, using the new literal string interpolation, but I supplied an
invalid f
Jeroen Van Goey added the comment:
Thanks Barry for your extensive explanation!
--
___
Python tracker
<http://bugs.python.org/issue29307>
___
___
Python-bug
New submission from Jeroen van der Ham <[EMAIL PROTECTED]>:
logging.basicConfig seems to ignore level=0:
>>> import logging
>>> logging.basicConfig(level=0)
>>> logging.getLogger().getEffectiveLevel()
30
>>> import logging
>>>
New submission from Jeroen van den Hout :
Currently when building an extension which lists a SWIG interface (.i) file as
a source file, SWIG creates the files correctly in the build_ext command.
Unfortunately this command is run after the build_py command, so the python
files (.py) created
Jeroen van den Hout added the comment:
Well, if I look at the source code build_ext explicitly calls for SWIG to
handle interface files. Also, in case of commands like 'pip install ',
the build sequence is predefined anyways, unless you explicitly define your own
sequence i
Jeroen van den Hout added the comment:
I'm sorry, I read your comment completely wrong, so please disregard my
previous comment.
I would argue the sequence doesn't really matter that much for non SWIG
packages, since those will install correctly no matter if the extensions are
Jeroen van den Hout added the comment:
> Adding a separate build step for SWIG (then the order would be build_swig,
> build_py, build_ext) would be safer and IMHO also more logical.
I like this suggestion and contemplated it. However SWIG interface files are
defined in Extension ins
New submission from Jeroen van der Heijden:
When compiling a regular expression with groups (subpatterns),
circular references are created.
Here is an example to illustrate the problem:
>>> import gc
>>> import re
>>> gc.disable() # disable garbage collector
>
Jeroen van der Heijden added the comment:
Thanks Serhiy,
I totally agree with your solution. Using a list with subpattern widths is
definitely better compared to using weakref.
--
___
Python tracker
<http://bugs.python.org/issue25
New submission from Jeroen van der Heijden:
When a ConnectionResetError occurs, reference cycles are created due to
__traceback__. As far as I can see there's no way to prevent this to happen
since the event loop exception handler is not called for the following events:
BrokenPipe
Jeroen Ruigrok van der Werven added the comment:
What's the consensus on this? I ask since I actually ran into code today that
uses DictMixin and as such wasn't converted by the 2to3 tool.
--
nosy: +asmodai
___
Python trac
Jeroen Ruigrok van der Werven added the comment:
That nl_AW is an interesting one. Aruba is part of the Kingdom of the
Netherlands, so in essence it should follow nl_NL. From what I can see that
locale seems to be limited to (certain) Linux systems. I'll raise the issue
with the CLDR gu
Changes by Jeroen Ruigrok van der Werven :
--
nosy: +asmodai
___
Python tracker
<http://bugs.python.org/issue7384>
___
___
Python-bugs-list mailing list
Unsub
Jeroen Ruigrok van der Werven added the comment:
For the record, this happens on FreeBSD 8 as well.
It seems it is still the same bug as what I reported back in March 2009 on the
Python-dev list.
If you run the test stand-alone with ./python Lib/test/regrtest.py -uall
test_curses it passes
Jeroen Ruigrok van der Werven added the comment:
Just to state the obvious: ncursesw is needed for wide character support (i.e.
Unicode).
Also, have you tried asking Thomas Dickey (dic...@invisible-island.net) about
this? He might be able to give some clue about it since he's the main c
Jeroen Ruigrok van der Werven added the comment:
I did some digging on my side, the fact you see ncurses referenced from
readline is due to the build linking readline to libtermcap:
cc -fstack-protector -shared -Wl,-x -o libreadline.so.8
-Wl,-soname,libreadline.so.8 `lorder readline.So
Jeroen Ruigrok van der Werven added the comment:
Stefan, I was emailing with Rong-En Fan, a FreeBSD committer, about this issue
and he asked:
"Basically, this is caused by
a) our readline.so is linked against ncurses.so (via -ltermcap which is the
same lib)
b) wide-character en
New submission from Jeroen Ruigrok van der Werven:
FreeBSD has in its ports currently a change for Modules/_ctypes/libffi/
configure.ac that adds amd64-*-freebsd* next to x86_64. I have attached
said patch (but updated to be a diff to trunk) and I hope it can be
changed in trunk to minimize
Jeroen Ruigrok van der Werven added the comment:
Current output on XP with 2.5.1:
D:\>test.py
Traceback (most recent call last):
File "D:\test.py", line 12, in
r.close()
IOError: [Errno 0] Error
Traceback (most recent call last):
File "D:\test.py", line 20, in
Jeroen Ruigrok van der Werven added the comment:
Using Facundo's attachment:
D:\>using_subprocess.py
D:\>
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Jeroen Ruigrok van der Werven added the comment:
Patch for against 2.6 trunk @ r60910.
--
nosy: +asmodai
Added file: http://bugs.python.org/file9476/userdict.rst.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Jeroen Ruigrok van der Werven added the comment:
Patch against 2.5 trunk @ r60911.
Added file: http://bugs.python.org/file9477/libuserdict.tex.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Jeroen Ruigrok van der Werven added the comment:
Is this not solved with the new documentation interface? It groups all
Carbon modules under a collapsable tree element.
See http://docs.python.org/dev/modindex.html under Carbon
--
nosy: +asmodai, georg.brandl
Jeroen Ruigrok van der Werven added the comment:
As taken from http://blogs.msdn.com/astebner/
archive/2006/08/23/715755.aspx
"Hi Didier - You should not try to install this vcredist package using
a nested install. Performing nested installs causes problems with
installing hotfixes fo
Jeroen Ruigrok van der Werven added the comment:
The hints that the vcredist cannot/should not be installed nested, but
should be chained.
The details on the full flags used/supported by the vcredist files.
And the last one how to do the merge modules (and some other
scenario's) way of a
Jeroen Ruigrok van der Werven added the comment:
OK, I played around a bit and created a setup project (.vdproj file).
The relevant part for the merge modules is:
"MergeModule"
{
"{CEE29DC0-9FBA-4B99-8D47-5BC643D9B626}:_8968169979C7478FA
Jeroen Ruigrok van der Werven added the comment:
Hi Martin,
yes, that's exactly what I am saying actually. :)
This is the resulting file I created: Python26.msi
Right now it only installs into C:\Python26 and puts python.exe,
pythonw.exe and python26.dll there, but it is a start
New submission from Jeroen Ruigrok van der Werven:
Quoting from my email to Raymond:
In the Trac/Genshi community we've been tracking a bit obscure memory
leak that causes us a lot of problems.
Please see http://trac.edgewall.org/ticket/6614 and then
http://genshi.edgewall.org/ticket/19
Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> added the comment:
Given how Bazaar is not an official choice for the repository adding
this kind of thing will lead to a road to add such information for Hg
and other VCSes as well in order to be fair to all.
--
nosy: +a
Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> added the comment:
But isn't that Bazaar thing totally stand-alone from the SVN
repository? What experimental branches are you talking about?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> added the comment:
Go ahead. I'm not a committer, merely a person on the side.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
New submission from Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]>:
xml.dom.minidom details three methods: writexml(), toxml(),
toprettyxml(). Only one, toxml(), showed the optional encoding argument.
In the documentation for writexml() the encoding argument is explained,
but topre
Jeroen Ruigrok van der Werven added the comment:
Nick et al,
currently trying b3 and using the bundled pip (1.5.2) to update the bundled
setuptools from 2.1 to 2.2 on Windows 7 and I get the following. Any idea if
this is still an issue with the newer versions (and thus might be relevant to
Jeroen Ruigrok van der Werven added the comment:
Yes, looks like it is just the email module:
F:\Python33>Scripts\pip3.3.exe install -U setuptools
Downloading/unpacking setuptools from
https://pypi.python.org/packages/3.4/s/setuptools/setuptools-2.2-py2.py3-none-any.whl#
Jeroen Ruigrok van der Werven added the comment:
Just to confirm that I, indeed, did not run into problems any more with RC1
trying to upgrade setuptools.
--
___
Python tracker
<http://bugs.python.org/issue20
New submission from Jeroen Ruigrok van der Werven:
Just tried the rc2 MSI on Windows 7 x64. Go through the normal setup I always
pick the Advanced option of compiling the .py files. In rc1 the script it
spawns works as it should, with rc2 I see it pop up, have a Traceback before it
quickly
Jeroen Ruigrok van der Werven added the comment:
This is, by the way, an upgrade install over rc1. Need to test a clean install
at some point as well.
Running the MSI with /L* gives me:
Action 8:13:22: RemovePip.
Action start 8:13:22: RemovePip.
CustomAction RemovePip returned actual error
Jeroen Ruigrok van der Werven added the comment:
Ah, this might be something we need to fix in the process of the installer. If
you have a pip installed that got updated, the install will now fail due
version mismatch. Updated the title.
Traceback (most recent call last):
File "F:\Pyt
Jeroen Ruigrok van der Werven added the comment:
Nick, this resolves the installation issues for me at least. +1
--
___
Python tracker
<http://bugs.python.org/issue20
Jeroen Ruigrok van der Werven added the comment:
This seems to be present in c-api/arg.rst in trunk already.
Candidate for closure after verifying it's been merged appropriately?
--
nosy: +asmodai
___
Python tracker
<http://bugs.py
Jeroen Ruigrok van der Werven added the comment:
I added initial documentation for both PyObject_HEAD_INIT and
PyVarObject_HEAD_INIT in r71874.
The text currently reads:
PyObject_HEAD_INIT(type)ΒΆ
This is a macro which expands to initialization values for a new
PyObject type. This macro
Jeroen Ruigrok van der Werven added the comment:
What do we want to do with this one, because it is now seems out of
scope for documentation given the changes Gerhard implemented.
--
nosy: +asmodai
___
Python tracker
<http://bugs.python.
Jeroen Ruigrok van der Werven added the comment:
Currently in trunk the types implementation only defines:
DictProxyType = type(TypeType.__dict__)
This is also documented in library/types.rst as:
types.DictProxyType
The type of dict proxies, such as TypeType.__dict__.
It's the
Jeroen Ruigrok van der Werven added the comment:
There has been no patch forthcoming in 3-4 years. Should the possibility
of a stack size increase for HP-UX be documented somewhere in the
installation/build documentation so that this issue can finally be
closed or do we want to fix configure
Jeroen Ruigrok van der Werven added the comment:
We want to document that old-style classes get converted into new-style
classes and that in general this goes without problems, except for some
corner cases such as containing a __slots__ directive? Or did I miss
anything else?
--
nosy
Jeroen Ruigrok van der Werven added the comment:
Thanks, committed in r71882.
Georg, I guess this needs to be backported to 2.6 at least and we need
to check what 3.x has.
--
nosy: +asmodai
___
Python tracker
<http://bugs.python.org/issue4
Changes by Jeroen Ruigrok van der Werven :
--
priority: -> low
stage: -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue4239>
___
___
Jeroen Ruigrok van der Werven added the comment:
Just to make it clear: I committed this to trunk, since it is relevant
to that as well. We can always move the documentation over with minor
tweaks.
--
stage: needs patch -> commit review
___
Pyt
Jeroen Ruigrok van der Werven added the comment:
I am not entirely sure, but I think part of the reason was that if the
documentation needed to be built, it would need the snapshot at that
time. Georg? Was it intentional?
I consider this a low priority issue, but needs to be looked at whether
Jeroen Ruigrok van der Werven added the comment:
This is at least relevant to 2.7, reflect this in the issue.
Patch to remove the notion we don't support TLS yet.
We will need to see where to add the current functions in the overall
scheme of threading documentation.
--
key
Jeroen Ruigrok van der Werven added the comment:
Mmm, depends on the case, I guess. The current implementation of the
macros is hardcoded for the most part. Where it is variable I left the
arguments in.
I was following the example from the other macros and I guess that since
this is the
Jeroen Ruigrok van der Werven added the comment:
How does this look as an initial idea?
--
keywords: +patch
nosy: +asmodai
Added file: http://bugs.python.org/file13772/py_ssize_t-note.diff
___
Python tracker
<http://bugs.python.org/issue4
Changes by Jeroen Ruigrok van der Werven :
Removed file: http://bugs.python.org/file13772/py_ssize_t-note.diff
___
Python tracker
<http://bugs.python.org/issue4
Jeroen Ruigrok van der Werven added the comment:
Pure ignore. Let me adjust the patch. Do we prefer versionchanged before
or after versionadded? I am guessing after versionadded so we get a
better chronological view. Although there's something to be said for a
reverse chronological vie
Jeroen Ruigrok van der Werven added the comment:
Committed a first batch in r71910.
--
___
Python tracker
<http://bugs.python.org/issue4129>
___
___
Python-bug
Jeroen Ruigrok van der Werven added the comment:
Fixed the slice stuff in r71915.
--
___
Python tracker
<http://bugs.python.org/issue4129>
___
___
Python-bug
Jeroen Ruigrok van der Werven added the comment:
OK, I went through the entire C API documentation and marked up every
part that changed from int to Py_ssize_t in our documentation.
--
resolution: -> accepted
stage: -> committed/rejected
status: open -&g
Jeroen Ruigrok van der Werven added the comment:
I assume this is relative to the resolution of a user's monitor. For me,
using the current documentation it only takes about 1/8th - 1/9th of my
width.
--
nosy: +asmodai
___
Python tracker
Jeroen Ruigrok van der Werven added the comment:
Not that I saw.
Merged to py3k and 2.6.
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Jeroen Ruigrok van der Werven added the comment:
Merged 2.6 and py3k what was appropriate.
--
___
Python tracker
<http://bugs.python.org/issue4129>
___
___
Pytho
Jeroen Ruigrok van der Werven added the comment:
Garrett, I use FreeBSD myself too, so feel free to bounce anything my way.
--
nosy: +asmodai
___
Python tracker
<http://bugs.python.org/issue5
Jeroen Ruigrok van der Werven added the comment:
Had this actually been brought up?
--
nosy: +asmodai
___
Python tracker
<http://bugs.python.org/issue3
Jeroen Ruigrok van der Werven added the comment:
So far effbot hasn't said anything about this. So Frederik, was it
intended to be exposed or not?
--
nosy: +asmodai
___
Python tracker
<http://bugs.python.org/i
Jeroen Ruigrok van der Werven added the comment:
OK, clear, then I'll see what I can do.
--
___
Python tracker
<http://bugs.python.org/issue5337>
___
___
Jeroen Ruigrok van der Werven added the comment:
Shouldn't the fallback be to setlocale(LC_CTYPE, "C") instead of
silently passing, though?
--
nosy: +asmodai
___
Python tracker
<http://bugs.pytho
Jeroen Ruigrok van der Werven added the comment:
You don't want to completely nix the setlocale(LC_CTYPE, "") call
though. The "" denotes to grab the native environment, in other words,
to grab whatever the current user's LC_CTYPE environment variable is set
to
Jeroen Ruigrok van der Werven added the comment:
Babel already provides (almost all of) this. It uses the Unicode CLDR
data to present the information you need.
See http://babel.edgewall.org/
--
nosy: +asmodai
___
Python tracker
<h
Jeroen Ruigrok van der Werven added the comment:
OK, then I'll apply it.
But I am curious about your thoughts about the _parse_localename()
method being called from setlocale() raising a ValueError, whereas a
setlocale(LC_CTYPE, "") should not fail at all, which it currently doe
Jeroen Ruigrok van der Werven added the comment:
Sorry, I was actually off by a method last night.
It turns out the problem lies in _localemodule.c.
Let me start with the basic question: is our setlocale() supposed to
mirror POSIX' operations/sema
Jeroen Ruigrok van der Werven added the comment:
As C99 section 7.23.3.5 states:
"Each conversion specifier is replaced by appropriate characters as
described in the following list. The appropriate characters are
determined using the LC_TIME category of the current locale and by the
valu
Jeroen Ruigrok van der Werven added the comment:
I will first point out where our current implementation is broken, in my
opinion of course, after which I propose a small patch.
Both C90 (7.4.1.1) and C99 (7.11.1.1) state:
"A value of "C" for locale specifies the minimal en
Jeroen Ruigrok van der Werven added the comment:
On the subject whether or not returning a null pointer should be
considered he said:
->
On the subject whether or not returning a null pointer should be
considered an error he said:
--
___
Pyt
Changes by Jeroen Ruigrok van der Werven :
Removed file: http://bugs.python.org/file13843/locale.diff
___
Python tracker
<http://bugs.python.org/issue1443504>
___
___
Changes by Jeroen Ruigrok van der Werven :
Removed file: http://bugs.python.org/file13849/locale.diff
___
Python tracker
<http://bugs.python.org/issue1443504>
___
___
Jeroen Ruigrok van der Werven added the comment:
Really correct this time.
--
Added file: http://bugs.python.org/file13850/locale.diff
___
Python tracker
<http://bugs.python.org/issue1443
Jeroen Ruigrok van der Werven added the comment:
Georg pointed out a mistake I introduced in my patch, updated now.
--
Added file: http://bugs.python.org/file13849/locale.diff
___
Python tracker
<http://bugs.python.org/issue1443
Jeroen Ruigrok van der Werven added the comment:
I asked that as well on the POSIX/SUS list and Don Cragun responded with:
"If you make the last argument to setlocale() be a pointer to
unallocated memory, implementations would be allowed to set errno to
EFAULT and terminate the process w
Jeroen Ruigrok van der Werven added the comment:
Committed the initial patch in r72375 for trunk and r72376 for py3k.
Any other branches that would need the merge? 3.0?
--
resolution: -> accepted
stage: test needed -> committed/rejected
status: open ->
Jeroen Ruigrok van der Werven added the comment:
Committed in r72381 and r72395.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue1
Jeroen Ruigrok van der Werven added the comment:
I can verify this on Vista.
2.5 gives:
>>> from locale import setlocale, LC_ALL
>>> setlocale(LC_ALL, "fr")
'French_France.1252'
Whereas 2.6 fails.
There is no difference between 2.5's and 2.6&#x
Jeroen Ruigrok van der Werven added the comment:
My tests were with official distributions.
Yamamoto-san, thank you for your testing. I was thinking it might have
been something to do with changed semantics, but I am happy you saved me
the time from having to compile.
Looking at the
Jeroen Ruigrok van der Werven added the comment:
Interesting. I'll see if I can dig into this.
--
nosy: +asmodai
___
Python tracker
<http://bugs.python.org/i
Jeroen Ruigrok van der Werven added the comment:
On FreeBSD there's no need for the ncurses package in most case. Since
somewhere along 6.x and 7.x line Rong-En Fan switched FreeBSD to do what
I did for DragonFly BSD a long time: to have both normal and wide curses
available.
As far as P
Jeroen Ruigrok van der Werven added the comment:
Not sure, never got around to dig into it. But we did have some locale fixes,
including better picking up default encodings and whatnot.
--
___
Python tracker
<http://bugs.python.org/issue2
Jeroen Ruigrok van der Werven added the comment:
Given that cryptography.io is fast becoming the solution for dealing with X.509
certificates on Python, I would like to add my vote to add my vote for this
feature. Right now, getting the full chain in DER is what I am missing to
complete a
601 - 691 of 691 matches
Mail list logo
