[issue7068] 2.6.3 does not use specified compiler

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Thanks for reporting this.

It appears that Benjamin tried to undo the .compiler attribute renaming
Tarek had applied and r72586, but forgot to change back line 303 to the
original version:

{{{
# Setup the CCompiler object that we'll use to do all the
# compiling and linking
self.compiler = new_compiler(compiler=self.compiler,
 verbose=self.verbose,
 dry_run=self.dry_run,
 force=self.force)
}}}

--
nosy: +lemburg

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7070] round(x) gives wrong result for large odd integers

[Mark Dickinson]

New submission from Mark Dickinson :

The single-argument form of the builtin round function can give
incorrect results for large integers.

>>> x = 5e15+1
>>> x == int(x)
True
>>> x == round(x)  # expect True here
False
>>> x
5001.0
>>> round(x)
5002.0
>>> int(x)
5001

This is already fixed in trunk (and in 3.x);  the fix needs to be
backported to release26-maint.

--
assignee: mark.dickinson
keywords: easy
messages: 93635
nosy: mark.dickinson
priority: high
severity: normal
stage: needs patch
status: open
title: round(x) gives wrong result for large odd integers
type: behavior
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5127] UnicodeEncodeError - I can't even see license

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

So the discussion is now on 2 points:

1. Is the change backwards compatible? (at the code level, after
recompilation).  My answer is yes, because all known case
transformations stay in the same plane: if you pass a char in the BMP,
they return a char in the BMP; if you pass a code >0x1000, you get
another code >0x1000. In other words: in narrow builds, when you pass
Py_UNICODE, the answer will be correct even when downcasted to
Py_UNICODE.  If you want, I can add checks to makeunicodedata.py to
verify that future Unicode standards don't break this statement.

"Naive" code that simply walks the Py_UNICODE* buffer will have
identical behavior.  (The current unicode methods are in this case. 
They should be fixed, later)

2. Is this change acceptable for 3.2?  I'd say yes, because existing
extension modules that use these functions will need to be recompiled;
the functions names change, the modules won't load otherwise.  There is
no need to change the API number for this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7068] 2.6.3 does not use specified compiler

[Tarek Ziadé]

Tarek Ziadé  added the comment:

Thanks for noticing, I'll rename it in the maintenance branch, but I
need to wait for Barry to give me the green light since the 2.6 branch
is frozen right now.

--
nosy: +barry

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6516] reset owner/group to root for distutils tarballs

[Bheemesh]

Bheemesh  added the comment:

Hello Tarek,

done in r75192 and r75194. Thanks Till !

Can you please tell me how to get this correction into use?

--
nosy: +bheemesh

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1282647] socket.getaddrinfo() bug for IPv6 enabled platforms

[Bert Vermeulen]

Bert Vermeulen  added the comment:

This is not a python bug, but a bug in the underlying libc. A simple
getaddrinfo() call in C exhibits the exact same behavior. It has been
fixed at some point; I see this bug on Centos 3.3 but not on Centos 4.4,
for example.

I've attached a small C demo that will fail on Centos 3.3, but work on
more recent platforms.

--
nosy: +biot
Added file: http://bugs.python.org/file15053/gai.c

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7071] distutils and IronPython compatibility

[Michael Foord]

New submission from Michael Foord :

distutils package installation isn't compatible with IronPython.

To reproduce first install IronPython 2.6 (RC1 is currently latest
version) from the msi installer. This installs by default on Windows
into "C:\Program Files\IronPython 2.6" and includes a "site-packages"
folder in the "Lib" subfolder.

With the simplest Python package created with "python setup.py sdist"
(CPython) from the first example in the distutils documentation I get
the following on install:

C:\compile\test\foo-1.0>"C:\Program Files\IronPython 2.6\ipy.exe"
setup.py install
running install
running build
running build_py
creating build
creating build\lib
copying foo.py -> build\lib
running install_lib
copying build\lib\foo.py -> C:\Program Files\IronPython
2.6\Lib\site-packages
error: C:\Program Files\IronPython 2.6\Lib\site-packages\foo.py: None

C:\compile\test\foo-1.0>dir "C:\Program Files\IronPython
2.6\Lib\site-packages"

 Volume in drive C has no label.
 Volume Serial Number is FC33-85DD

 Directory of C:\Program Files\IronPython 2.6\Lib\site-packages

06/10/2009  11:37  .
06/10/2009  11:37  ..
15/09/2009  08:53   121 README.txt
   1 File(s)121 bytes
   2 Dir(s)  71,854,129,152 bytes free


See also the following bug report against IronPython on the codeplex
issue tracker. Here the distutils install fails in bytecode compilation. 

http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=24810

Bytecode compilation should not be attempted on IronPython as it does
not use Python bytecode. ( sys.dont_write_bytecode is True )

The fixes should be backported to Python 2.6 *if possible* as IronPython
2.6 uses the standard library from SVN and will pick up changes even
between releases.

--
assignee: tarek
messages: 93640
nosy: michael.foord, tarek
severity: normal
stage: needs patch
status: open
title: distutils and IronPython compatibility
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7071] distutils and IronPython compatibility

[Michael Foord]

Changes by Michael Foord :


--
keywords: +26backport

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7071] distutils and IronPython compatibility

[Michael Foord]

Michael Foord  added the comment:

Hmmm... ok, so I was running on Vista where a normal user can't create
files in the "Program Files" directory anyway. If I run with elevated
permissions then I get the same error as reported on the IronPython
issue on codeplex (which is probably what you will see if you try this
on Windows XP):

C:\compile\test\foo-1.0>"C:\Program Files\IronPython 2.6\ipy.exe"
setup.py install
running install
running build
running build_py
running install_lib
copying build\lib\foo.py -> C:\Program Files\IronPython
2.6\Lib\site-packages
byte-compiling C:\Program Files\IronPython 2.6\Lib\site-packages\foo.py
to foo.p
yc
Traceback (most recent call last):
  File "setup.py", line 2, in setup.py
  File "C:\Program Files\IronPython 2.6\Lib\distutils\core.py", line
152, in set
up
  File "C:\Program Files\IronPython 2.6\Lib\distutils\dist.py", line
975, in run
_commands
  File "C:\Program Files\IronPython 2.6\Lib\distutils\dist.py", line
995, in run
_command
  File "C:\Program Files\IronPython
2.6\Lib\distutils\command\install.py", line
589, in run
  File "C:\Program Files\IronPython 2.6\Lib\distutils\cmd.py", line 333,
in run_
command
  File "C:\Program Files\IronPython 2.6\Lib\distutils\dist.py", line
995, in run
_command
  File "C:\Program Files\IronPython
2.6\Lib\distutils\command\install_lib.py", l
ine 100, in run
  File "C:\Program Files\IronPython
2.6\Lib\distutils\command\install_lib.py", l
ine 134, in byte_compile
  File "C:\Program Files\IronPython 2.6\Lib\distutils\util.py", line
535, in byt
e_compile
  File "C:\Program Files\IronPython 2.6\Lib\py_compile.py", line 138, in
compile

ValueError: unmarshallable object
C:\compile\test\foo-1.0>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6516] reset owner/group to root for distutils tarballs

[Bheemesh]

Bheemesh  added the comment:

I just took download of the latest python 2.6.3 which was updated on 2nd
OCT 09, and found that while tarball creation everything looks OK, but
when we un-tar the archive the permissions goes back to the current user
logged in. Can this be set to the user mentioned while archive was created?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7068] 2.6.3 does not use specified compiler

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

Tarek, please commit this fix before 2.6.4rc1 (i.e. asap :)

--
priority:  -> release blocker
resolution:  -> accepted

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6516] reset owner/group to root for distutils tarballs

[Tarek Ziadé]

Tarek Ziadé  added the comment:

Hi Bheemesh,

This is a new feature, so it was added in the current trunk that will
become 2.7 and 3.2.

So unfortunately, you can't have it in any 2.6 release.

A workaround is to create your own sdist command, that includes the
changes made in 2.7.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7068] 2.6.3 does not use specified compiler

[Tarek Ziadé]

Tarek Ziadé  added the comment:

Done in r75269. Thanks Shun-ichi and Marc-André

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[Ralf Schmitt]

Changes by Ralf Schmitt :


--
nosy: +schmir

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6516] reset owner/group to root for distutils tarballs

[Bheemesh]

Bheemesh  added the comment:

HI Tarek,

Thanks very much for a quick reply here.
since i am new to this , can you help me with sdist command to have the
latest changes?

Best Regards,
Bheemesh

On Tue, Oct 6, 2009 at 5:59 PM, Tarek Ziadé  wrote:

>
> Tarek Ziadé  added the comment:
>
> Hi Bheemesh,
>
> This is a new feature, so it was added in the current trunk that will
> become 2.7 and 3.2.
>
> So unfortunately, you can't have it in any 2.6 release.
>
> A workaround is to create your own sdist command, that includes the
> changes made in 2.7.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--
Added file: http://bugs.python.org/file15054/unnamed

___
Python tracker 

___HI Tarek,Thanks very much for a quick reply here.since i am new to 
this , can you help me with sdist command to have the latest 
changes?Best Regards,Bheemesh
On Tue, Oct 6, 2009 at 5:59 PM, Tarek Ziadé rep...@bugs.python.org> 
wrote:

Tarek Ziadé ziade.ta...@gmail.com> added the 
comment:

Hi Bheemesh,

This is a new feature, so it was added in the current trunk that will
become 2.7 and 3.2.

So unfortunately, you can't have it in any 2.6 release.

A workaround is to create your own sdist command, that includes the
changes made in 2.7.

--

___
Python tracker rep...@bugs.python.org>
http://bugs.python.org/issue6516>
___

___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] PEP 314 inconsistency (authors/author/maintainer)

[anatoly techtonik]

anatoly techtonik  added the comment:

>> Tarek Ziadé  added the comment:

>> Yes but fixing this inconsitency can be done on either side:
>> A - remove the maintainer and maintainer_email
>> B - add the Maintainer and Maintainer-email in the metadata

>> If we don't have a use case, I'd go for A/
>
> Having a maintainer for a package is not at all uncommon.
>
> Whether you put that maintainer into a separate field or not
> is really a mix of respect/taste/culture.

Please, be specific. PyPi maintainer or trac-plugin package maintainer
or debian package maintainer? Which should be mentioned in debian
package for a trac plugin uploaded to PyPi for easy_install?

> I'd go for B, since we already have the maintainer setup()
> variable and just need to add the missing meta-data field.
>
> Whether this gets used or not is up to 3rd party code
> using the meta-data to decide and not really a distutils
> question.

Is distutils format extensible? Can you create example of extending
distutils format using this maintainer use case, so that every project
can add their own maintainer fields if they need them? If it is
impossible then I suggest to stop this discussion and start planning
extensible distutils2 format with setup2.py and other2 files.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] PEP 314 inconsistency (authors/author/maintainer)

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

anatoly techtonik wrote:
> 
> anatoly techtonik  added the comment:
> 
>>> Tarek Ziadé  added the comment:
> 
>>> Yes but fixing this inconsitency can be done on either side:
>>> A - remove the maintainer and maintainer_email
>>> B - add the Maintainer and Maintainer-email in the metadata
> 
>>> If we don't have a use case, I'd go for A/
>>
>> Having a maintainer for a package is not at all uncommon.
>>
>> Whether you put that maintainer into a separate field or not
>> is really a mix of respect/taste/culture.
> 
> Please, be specific. PyPi maintainer or trac-plugin package maintainer
> or debian package maintainer? Which should be mentioned in debian
> package for a trac plugin uploaded to PyPi for easy_install?

The maintainer of the plugin.

>> I'd go for B, since we already have the maintainer setup()
>> variable and just need to add the missing meta-data field.
>>
>> Whether this gets used or not is up to 3rd party code
>> using the meta-data to decide and not really a distutils
>> question.
> 
> Is distutils format extensible? Can you create example of extending
> distutils format using this maintainer use case, so that every project
> can add their own maintainer fields if they need them? If it is
> impossible then I suggest to stop this discussion and start planning
> extensible distutils2 format with setup2.py and other2 files.

The meta-data format is versioned, so it's well possible to
add new fields to it or make changes in core distutils.

It's even possible to extend if in custom setup scripts,
provided you know your way around in distutils. Have a
look at dist.py. You'll need to write a Distribution sub-class
and register this via the distclass setup() parameter.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5395] array.fromfile not checking I/O errors

[Eduardo Aguiar]

Eduardo Aguiar  added the comment:

Another try. I have opened a file for writing, and have tried to read
from it:

>>> fp = open ('xxx', 'w')
>>> fp.read ()
Traceback (most recent call last):
  File "", line 1, in 
IOError: [Errno 9] Bad file descriptor

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7072] isspace(0xa0) is true on Mac OS X

[Naoki INADA]

New submission from Naoki INADA :

Old FreeBSD's libc has a bug relate to utf-8 locale and Python have 
patch for it: http://svn.python.org/view/python/trunk/Include/pyport.h?
view=diff&pathrev=43219&r1=36792&r2=36793

This bug appears in Mac OS X again. This test fails:
>>> s = '\xa0'
>>> assert s.strip() == s
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')
'en_US.UTF-8'
>>> assert s.strip() == s

So above patch should be enabled for Mac OS X.

--
messages: 93650
nosy: naoki
severity: normal
status: open
title: isspace(0xa0) is true on Mac OS X
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] PEP 314 inconsistency (authors/author/maintainer)

[anatoly techtonik]

anatoly techtonik  added the comment:

On Tue, Oct 6, 2009 at 4:04 PM, Marc-Andre Lemburg
 wrote:
>>
>> Please, be specific. PyPi maintainer or trac-plugin package maintainer
>> or debian package maintainer? Which should be mentioned in debian
>> package for a trac plugin uploaded to PyPi for easy_install?
>
> The maintainer of the plugin.
>

So, the maintainer of the plugin is mentioned in setup.py, but this
field is also used in PyPi and the person who maintains it there wants
some attribution. Should this person change maintainer field to
himself?

>> Is distutils format extensible? Can you create example of extending
>> distutils format using this maintainer use case, so that every project
>> can add their own maintainer fields if they need them? If it is
>> impossible then I suggest to stop this discussion and start planning
>> extensible distutils2 format with setup2.py and other2 files.
>
> The meta-data format is versioned, so it's well possible to
> add new fields to it or make changes in core distutils.

No, that's not the way. Suppose we have three independent external
frameworks that use setup.py files for deploying their
plugins/components. All three need to extend distutils format. Which
version should they choose? What if official distutils release will
decide to use this version? Will other tools parse all these new
versions correctly?

> It's even possible to extend if in custom setup scripts,
> provided you know your way around in distutils. Have a
> look at dist.py. You'll need to write a Distribution sub-class
> and register this via the distclass setup() parameter.

As you may see I definitely do not know my way in distutils. =) Can
you show the example of extending setup.py with pypi_maintainers
field, that includes emails that should be granted maintainer rights
by PyPi automatically on setup.py submission? It is not that I am
challenging you to something - I just want to say that there are not
many people who knows distutils like you to create the best solution
for this user story. Even if it can be a tedious task the outcome is
really important for further distutils usability improvement.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5395] array.fromfile not checking I/O errors

[Jan Hosang]

Jan Hosang  added the comment:

Thanks Aduardo! (I could have sworn I tried that.) I changed the test to 
reading from a file in 'wb' mode, which raised a EOFError before and now 
raises IOErrors.

--
Added file: http://bugs.python.org/file15055/array_ioerror.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6670] Printing the 'The Python Tutorial'

[Ezio Melotti]

Ezio Melotti  added the comment:

To fix this problem is enough to add an !important to the margin: 0;
rule in the @media print {} at the end of basic.css (line 408).

I'll try to explain why the !important is necessary.
In default.css @import url("basic.css"); (correctly) appears at the
beginning, and imports the rules from basic.css, including the @media
print {}. A few lines later, in default.css, there's the rule
div.bodywrapper { margin: 0 0 0 230px; }, and with no @media specified
it defaults on 'all'.

In default.css we then end up with something equivalent to:

/* This is defined in basic.css and imported
   at the beginning of default.css */
@media print {
/* some rules omitted for clarity */
div.bodywrapper { margin: 0; }
}

/* This is defined later in default.css */
@media all { /* This is implicit */
div.bodywrapper { margin: 0 0 0 230px; }
}

When the file is printed both the rules are applied, because 'all' also
includes 'print'.
Since both the media have the same priority (i.e. the specific @media
print does NOT have higher priority than the implicit @media all) and
both the rules have the same priority too, the latter wins.
The !important is then needed to raise the priority of the first rule.

Note that adding the !important is not a really good solution IMHO: the
problem could appear again if other rules with the same priority of the
ones in @media print {} are specified elsewhere.
A good solution would be to move the print rules after the normal ones,
so in case the print media is used these rules will have higher priority.
The @import can only appear at the beginning of a file so the two
possible solutions are:

1) put the rules with media all in, for example, all.css and the ones
with media print in print.css and then, in default.css, write only:
@import url('all.css');
@import url('print.css') print;

2) like 1) but importing the print.css separately using  in the
html pages:



A third solution might be to specify the media of the normal rules to
'screen', but some rules are probably common to both the media.

More information here: http://www.w3.org/TR/CSS2/cascade.html

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] PEP 314 inconsistency (authors/author/maintainer)

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

anatoly techtonik wrote:
> 
> anatoly techtonik  added the comment:
> 
> On Tue, Oct 6, 2009 at 4:04 PM, Marc-Andre Lemburg
>  wrote:
>>>
>>> Please, be specific. PyPi maintainer or trac-plugin package maintainer
>>> or debian package maintainer? Which should be mentioned in debian
>>> package for a trac plugin uploaded to PyPi for easy_install?
>>
>> The maintainer of the plugin.
>>
> 
> So, the maintainer of the plugin is mentioned in setup.py, but this
> field is also used in PyPi and the person who maintains it there wants
> some attribution. Should this person change maintainer field to
> himself?

We have a long description field for such things. If you look on PyPI
that field is even being used for complete documentation of a package,
so adding a note about some extra maintainer is certainly within
range.

>>> Is distutils format extensible? Can you create example of extending
>>> distutils format using this maintainer use case, so that every project
>>> can add their own maintainer fields if they need them? If it is
>>> impossible then I suggest to stop this discussion and start planning
>>> extensible distutils2 format with setup2.py and other2 files.
>>
>> The meta-data format is versioned, so it's well possible to
>> add new fields to it or make changes in core distutils.
> 
> No, that's not the way. Suppose we have three independent external
> frameworks that use setup.py files for deploying their
> plugins/components. All three need to extend distutils format. Which
> version should they choose? What if official distutils release will
> decide to use this version? Will other tools parse all these new
> versions correctly?

There's only one official distutils meta-format: that of core distutils.

Up until now, we've only added new fields, so old tools will
continue to work (but not know about the new fields).

>> It's even possible to extend if in custom setup scripts,
>> provided you know your way around in distutils. Have a
>> look at dist.py. You'll need to write a Distribution sub-class
>> and register this via the distclass setup() parameter.
> 
> As you may see I definitely do not know my way in distutils. =) Can
> you show the example of extending setup.py with pypi_maintainers
> field, that includes emails that should be granted maintainer rights
> by PyPi automatically on setup.py submission? It is not that I am
> challenging you to something - I just want to say that there are not
> many people who knows distutils like you to create the best solution
> for this user story. Even if it can be a tedious task the outcome is
> really important for further distutils usability improvement.

I don't have time for such challenges. Like I said: it's possible
and easy to do, but that doesn't necessarily mean that adding
custom fields to the meta-file format should be encouraged.

I also don't think that distutils meta data should be used
for automatic administration of tools such as PyPI. It has
purely informational character and helps in searching or
browsing Python packages. Nothing more.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7029] Improve pybench

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Here is an updated patch with the superfluous timing function removed.
Please advise me on how you "don't like the implementation"

I'm also considering adding a '--quiet' flag that causes it to only emit 
the 'total' line.  This is useful for automated testing of builds.  Any 
thoughts about that?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7029] Improve pybench

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

And here is the actual patch.

--
Added file: http://bugs.python.org/file15056/pybench.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3244] multipart/form-data encoding

[Andrey Petrov]

Andrey Petrov  added the comment:

Once upon a time I wrote a library that did some of this among other things:

http://code.google.com/p/urllib3/

Or specifically:
http://code.google.com/p/urllib3/source/browse/trunk/urllib3/filepost.py

The code was borrowed from some of the recipes mentioned, but cleaned up
and adjusted a bit. Feel free to use it or borrow from it in any way you
like.

--
nosy: +shazow

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue918368] urllib doesn't correct server returned urls

[Adam Nelson]

Adam Nelson  added the comment:

This seems a bit serious for inclusion in 2.7 IMHO.  urllib is used in all 
sorts of hackish ways in the wild and I really wonder if this is going to 
cause more problems for people than it's worth.  The 3.x series alone 
seems like the best place for this which is addressed by issue 1153027.

--
nosy: +AdamN

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5127] UnicodeEncodeError - I can't even see license

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

It's not as easy as that.

The functions for case conversion are used in a way that assumes they
never fail (and indeed, the existing functions cannot fail).

What we can do is change the input parameter to Py_UCS4, but not the
Py_UNICODE output parameter, since that would cause lots of compiler
warnings and implicit truncation on UCS2 builds, which would be a pretty
disruptive change.

However, this change would not really help anyone if there are no
mappings from BMP to non-BMP or vice-versa, so I'm not sure whether this
whole exercise is worth the effort.

It appears to be better to just leave the case mapping APIs unchanged -
or am I missing something ?

The situation is different for the various Py_UNICODE_IS*() APIs: for
these we can change the input parameter to Py_UCS4, remove the name
mangling and add UCS2 helper functions to maintain API compatibility on
UCS2 builds.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7069] inspect.isabstract to return boolean values only

[Gabriel Genellina]

Gabriel Genellina  added the comment:

Tests added.

--
Added file: http://bugs.python.org/file15057/inspect.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7069] inspect.isabstract to return boolean values only

[Gabriel Genellina]

Changes by Gabriel Genellina :


Removed file: http://bugs.python.org/file15052/inspect.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7029] Improve pybench

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Kristján Valur Jónsson wrote:
> 
> Kristján Valur Jónsson  added the comment:
> 
> Here is an updated patch with the superfluous timing function removed.
> Please advise me on how you "don't like the implementation"

The reporting methods are a complete mess (not your patch, my code).
They need a rewrite and then I can apply the extra gross output.

Something that would need to change is the .stat() patch: why
didn't you just add 3 new fields to the tuple instead of using
a list with 2 tuples ?

In any case, please don't invest too much time into this. I'm going
to rewrite the statistics part anyway and can then add the new
gross values while I'm at it.

> I'm also considering adding a '--quiet' flag that causes it to only emit 
> the 'total' line.  This is useful for automated testing of builds.  Any 
> thoughts about that?

Could be useful, yes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5127] UnicodeEncodeError - I can't even see license

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

> that would cause lots of compiler
> warnings and implicit truncation on UCS2 builds

Unfortunately, there is no such warning, or the initial problem we are trying 
to solve would have been spotted by such a warning (unicode_repr() calls 
Py_UNICODE_ISPRINTABLE() with a Py_UCS4 argument).

gcc has a -Wconversion flag, (which I tried today on python) but it is far too 
verbose before version 4.3, and this newer version still has some false 
positives. http://gcc.gnu.org/wiki/NewWconversion

But the most important thing is that implicit truncation on UCS2 builds is what 
happens already! The patch does not solve it, but at least it yields sensible 
results to wary code.
Or can you imagine some (somewhat working) code which behavior will be worse 
after the change?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1571184] Generate numeric/space/linebreak from Unicode database.

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Patch applied with r75272.
Merged to py3k, adapted and regenerated files with r75274.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6670] Printing the 'The Python Tutorial'

[Jesse Noller]

Jesse Noller  added the comment:

This request really does need a patch+tests+doc changes - I don't know if 
anyone with +commit has the time to distill the various implementations 
and generate something.

--
nosy: +jnoller

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6670] Printing the 'The Python Tutorial'

[Jesse Noller]

Changes by Jesse Noller :


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6670] Printing the 'The Python Tutorial'

[Jesse Noller]

Jesse Noller  added the comment:

I posted to the wrong bug, apologies

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3244] multipart/form-data encoding

[Jesse Noller]

Jesse Noller  added the comment:

This request really does need a patch+tests+doc changes - I don't know if 
anyone with +commit has the time to distill the various implementations 
and generate something.

--
nosy: +jnoller

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5127] UnicodeEncodeError - I can't even see license

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc :


Added file: http://bugs.python.org/file15058/unicodectype_ucs4_3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7073] Python 2.6.3 final windows installer installs a release candidate

[Jose Antonio Martin H]

New submission from Jose Antonio Martin H :

Python 2.6.3 (r263rc1:75186, Oct  2 2009, 20:40:30) [MSC v.1500 32 bit
(Intel)] on win32

That is the python that is installed with the python 2.6.3 installer.

--
components: Installation
messages: 93667
nosy: jamartinh
severity: normal
status: open
title: Python 2.6.3 final  windows installer installs a release candidate
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7073] Python 2.6.3 final windows installer installs a release candidate

[Ezio Melotti]

Ezio Melotti  added the comment:

This is a known issue, 2.6.4 will be out soon. See
http://mail.python.org/pipermail/python-committers/2009-October/000648.html

--
nosy: +ezio.melotti
resolution:  -> later
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7074] Turtle module crashes python

[Terry J. Reedy]

New submission from Terry J. Reedy :

Attached file run from IDLE edit window with 3.1, winxp works fine--
turtle moves in response to cursor keys-- if quit soon enough.
But after about 1000 key repeats, pythonw crashes with standard MSVC++
runtime error window, pythonw error window, and IDLE shell window
trackback ending with "RuntimeError: maximum recursion depth exceeded
while calling a Python object". The full traceback in appended to the file.

Disabling the undo buffer did not solve the problem.

Running the file from regular interpreter with
>>>exec(open(filename,'r').read())

gave essentially same result -- same traceback with slightly different
associated messages, so it is not an IDLE problem.

The demo/test at the bottem of turtle.py works fine -- but it does not
run as long.

I do not see the recursion, but calling the configuration merge with
every movement seems fishy.

--
components: Library (Lib)
files: turtlecrash.py
messages: 93669
nosy: tjreedy
severity: normal
status: open
title: Turtle module crashes python
type: crash
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15059/turtlecrash.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7074] Turtle module crashes python

[Terry J. Reedy]

Changes by Terry J. Reedy :


Removed file: http://bugs.python.org/file15059/turtlecrash.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7074] Turtle module crashes python

[Terry J. Reedy]

Terry J. Reedy  added the comment:

resubmitting file

--
Added file: http://bugs.python.org/file15060/turtlecrash.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue918368] urllib doesn't correct server returned urls

[Senthil Kumaran]

Senthil Kumaran  added the comment:

AdamN, did you specifically come across a scenario which broke due to
this change? I can understand your concern, in general. The
'non-breaking' existing tests is the one of confidence factor we have in
introducing the changes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6845] Restart support in binary upload for ftplib

[Pablo Mouzo]

Changes by Pablo Mouzo :


Removed file: http://bugs.python.org/file14876/issue6845.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3563] fix_idioms.py generates bad code

[Joe Amenta]

Joe Amenta  added the comment:

Attached a patch that implements more thoroughly what appears to be the
intended behavior.

--
nosy: +joe.amenta
Added file: http://bugs.python.org/file15061/fix_idioms.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3563] fix_idioms.py generates bad code

[Joe Amenta]

Changes by Joe Amenta :


Removed file: http://bugs.python.org/file15061/fix_idioms.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3563] fix_idioms.py generates bad code

[Joe Amenta]

Joe Amenta  added the comment:

Missed a paren in the last one... re-uploading it.

--
Added file: http://bugs.python.org/file15062/fix_idioms.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3563] fix_idioms.py generates bad code

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee: collinwinter -> benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7075] Bug while put a set on a dict

[Chu-Cheng]

New submission from Chu-Cheng :

>>> x={1:{1}}
>>> x[1] = (x.get(1).add(2))
>>> x
{1: None}

But...
>>> x={1:{1}}
>>> o = x.get(1)
>>> o.add(2)
>>> o
{1, 2}
>>> x[1] = o
>>> x
{1: {1, 2}}

--
components: None
messages: 93674
nosy: chucheng
severity: normal
status: open
title: Bug while put a set on a dict
versions: Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7075] Bug while put a set on a dict

[Chu-Cheng]

Chu-Cheng  added the comment:

my fault, I know what is the difference now :) sorry for bugging

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Terry J. Reedy]

Terry J. Reedy  added the comment:

For anyone trying this on another system: you must specifically click on
and drag the mouse/turtle graphic.

Running from IDLE edit, I get no traceback in the Shell Window, unlike
with the script I attached to #7074 and now here. While I am closing the
latter as probably due to the same cause, it does act differently:
adding the 'speed(0)' command present in dragbug.py appears to have
fixed the problem with turtlecrash.py.

Rewriting dragbug to use tkinter canvas directly would determine whether
the turtle module is a factor. The change of behavior with turtlecrash
with the speed command suggests to me that it might be.

--
nosy: +tjreedy
Added file: http://bugs.python.org/file15063/turtlecrash.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7069] inspect.isabstract to return boolean values only

[Jan Hosang]

Jan Hosang  added the comment:

I changed the patch so it does not introduce new dependencies and fails 
before the patch of isabstract().

--
Added file: http://bugs.python.org/file15064/inspect.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7076] Documentation add note about SystemRandom

[Shawn Ligocki]

New submission from Shawn Ligocki :

I did not notice the existence of random.SystemRandom until after I had
implemented my own version. I thought it would be nice to mention it in
the opening section. I've added a tiny note about random.SystemRandom.
What do you guys think, feel free to reword it, I just think that it
should be mentioned.

http://docs.python.org/library/random.html

--
assignee: georg.brandl
components: Documentation
files: random.patch
keywords: patch
messages: 93678
nosy: georg.brandl, sligocki
severity: normal
status: open
title: Documentation add note about SystemRandom
type: feature request
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15065/random.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7076] Documentation add note about SystemRandom

[Jan Hosang]

Jan Hosang  added the comment:

I think non-determinism is more then os.urandom can deliver. As far as I 
know the OS still does deterministic calculations, though they are maybe 
less obvious. Maybe call it "safer, OS dependent"?

--
nosy: +chuck

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7076] Documentation add note about SystemRandom

[Raymond Hettinger]

Raymond Hettinger  added the comment:

FWIW, the docs for os.urandom() state:

"""Return a string of n random bytes suitable for cryptographic use.

This function returns random bytes from an OS-specific randomness
source. The returned data should be unpredictable enough for
cryptographic applications, though its exact quality depends on the OS
implementation. On a UNIX-like system this will query /dev/urandom, and
on Windows it will use CryptGenRandom.
"""

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7076] Documentation add note about SystemRandom

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee: georg.brandl -> rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com