[issue7020] regression in pywin32 build due to 2.6.3rc1

[Eric Smith]

Changes by Eric Smith :


--
nosy: +eric.smith

___
Python tracker 

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

[issue7020] regression in pywin32 build due to 2.6.3rc1

[Tarek Ziadé]

Tarek Ziadé  added the comment:

I am investingating in py2exe build_ext custom command and in the
distutils bugfixes that where done, to understand the problem, I'll let
you know as soon as I've found it.

--
resolution:  -> accepted

___
Python tracker 

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

[issue7023] Marshal doesn't release GIL while dumping

[zengke]

New submission from zengke :

If marshal.dumps() is handling a large data, It keeps acquiring the GIL
and may take several seconds, Other threads therefor are blocked.
marshal.loads should also be friendly to other threads.

--
components: Library (Lib)
files: marshal_threads.patch
keywords: patch
messages: 93354
nosy: zengke
severity: normal
status: open
title: Marshal doesn't release GIL while dumping
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15006/marshal_threads.patch

___
Python tracker 

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

[issue7023] Marshal doesn't release GIL while dumping

[zengke]

Changes by zengke :


--
versions: +Python 2.4, Python 2.5, Python 2.6

___
Python tracker 

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

[issue7020] regression in pywin32 build due to 2.6.3rc1

[Tarek Ziadé]

Tarek Ziadé  added the comment:

Pywin32 is patching "build_ext.get_ext_filename", making the assumption
that it will be called only in a certain way (namespaces names)
by "build_ext.build_extension", to force the name of the output from
"pywintypes.pyd" to "pywintypes.dll".

But this API, even if its doctest doesn't make it clear (I will change
it to make it clearer) is used for both namespaced names and non
namespaced names by the community.

Lately we had a bug with inplace building of namespaced and non
namespaced extensions. To fix it, "build_ext.build_extension" is now
calling "get_ext_filename" differently and when it calls the pywin32
patched version, it fails because pywin32 fails to recognize the
"pywintypes" name and pass it to the non-patched
build_ext.get_ext_filename, leading to the problem.

The fix has to be done on pywin32 side, by making "get_ext_filename"
works as it is supposed : returning an extension name for any filename,
wheter it's namespaced or not.

I can help on it, it's a very simple fix.

But at the end, if pywin32 has to do such patches, there's a problem in
the way distutils plays with the MSVC linker : we should be able to work
with .dll's and .pyd's whithout having to patch build_ext behavior like
this.

--
resolution: accepted -> invalid

___
Python tracker 

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

[issue6992] Adding a Contributor field in PEP 314

[anatoly techtonik]

anatoly techtonik  added the comment:

> The good pratice, if there are several authors, is to setup a
> mailing-list (and put its address as official contact address).

True. Some packages already do this.

> Otherwise collaboration gets inevitably messy, since authors can get
> contacted in private randomly.

People who use Python are usually smart enough to include all authors
in TO or CC field.

> I don't think we should multiply those fields in order to accomodate for
> subtle role differences. Also, I don't think PyPI is the place to record
> detailed attribution information. An ad-hoc CREDITS, ACKS file or
> similar is what you want IMO.

Well, I am writing a plugin and I my framework doesn't parse CREDITS,
ACKS or similar PEP, but it can extract package information to display
my name. I want my name to be displayed by this framework. It is
called Trac.

> What does changing the type of the "author" field make clearer exactly?
> It is a field for human beings to read, and a human being is perfectly
> able to parse "AP , Tarek " without
> the help of a computer.

Type of `author` is not changed. It remains a single string that
doesn't include email. New field `authors` is introduced instead. It
can contain a single string with comma-separated authors. It is even
better than list.

> The metadata are completely messy. Users are already confused.

I think it should go into another `parent` ticket with a title like
"Perfection is achieved when there is nothing left to take away". =) I
think that we need to deprecate fields and leave links on their
meaning and how to translate them into other fields in documentation.
After three years everybody (well, at least the major part) will be
happy. Otherwise the frustration continue.

> Any change to the metadata fields will require a PEP 341 change, so
> everyone will be free to do a +1 or a -1.
>
> But saying that making the metadata evolve "is not the way we will make
> Python a reliable platform to use and develop for" is completely
> wrong imho.

+1

> Most of the meta data is parsed by humans, so I don't see any
> complication with adding multiple authors to the author field using
> standard email format: "Anatoli , Tarek ".

Right, but then what author_email field is for? It looks almost
obvious that if author contain list of author names then author_email
should contain list of emails. Especially, when you add another author
to the package where author_email is already used. We should not
forget that developers who are overwhelmed with docs even without
distutils and try to keep rules short and simple.

> A metadata system, by definition, has to remain reasonably stable (or be
> version-numbered, such that old metadata can be recognized properly).
> You can certainly add fields, but replacing existing fields with others
> should be sufficiently motivated.

That's why it should be new `authors` field.

> In order to clear up the inconsistency with maintainer not
> being a possible meta-data field, I think "Maintainer" should
> be added to the meta-data. Dito for "Maintainer-EMail".
>
> Regarding making the meta-data fields multi-valued, you have
> to be aware that when parsing the meta-data using an rfc822
> style module, code assuming that only one Author field
> exists, will return (just) one of the available fields and
> it's not at all clear which.

This quote is totally confusing. Sounds WAY too complicated. If you're
going to switch to meta-discussions I may fall off at some point.

I suspect that there are some meta-internals of Distutils that I must
be aware of as a Python developer, but I just want to add myself to
setup.py along with other developer and learn my framework use this
info fully. Consider this a user-story.

>>> In order to clear up the inconsistency with maintainer
>>> not being a possible meta-data field, I think "Maintainer"
>>> should be added to the meta-data. Dito for "Maintainer-EMail".
>>
>> Do you remember what's the story behind those two fields ?
>
> I don't really remember, but suppose that the field was
> added for cases where a package is being abandoned by the
> original author and then maintained by someone new.

I thought that setup.py metadata format is extensible. Let's leave
`maintainers` extension to the tools that need it, i.e. PyPI. But IIRC
even PyPI doesn't use this field to grant access to package info.

--

___
Python tracker 

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

[issue6992] Adding a Contributor field in PEP 314

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

anatoly techtonik wrote:
>> What does changing the type of the "author" field make clearer exactly?
>> It is a field for human beings to read, and a human being is perfectly
>> able to parse "AP , Tarek " without
>> the help of a computer.
> 
> Type of `author` is not changed. It remains a single string that
> doesn't include email. New field `authors` is introduced instead. It
> can contain a single string with comma-separated authors. It is even
> better than list.

Right, but then we have:

author
author_email
authors
maintainer
maintainer_email

for consitency, we'd also need:

author_emails
maintainers
maintainer_emails

That's even more confusing than what we already have and
it's not needed to solve the use case.

>> Most of the meta data is parsed by humans, so I don't see any
>> complication with adding multiple authors to the author field using
>> standard email format: "Anatoli , Tarek ".
> 
> Right, but then what author_email field is for? 

No idea. I think it was a YAGNI which was not really needed.

>> In order to clear up the inconsistency with maintainer not
>> being a possible meta-data field, I think "Maintainer" should
>> be added to the meta-data. Dito for "Maintainer-EMail".
>>
>> Regarding making the meta-data fields multi-valued, you have
>> to be aware that when parsing the meta-data using an rfc822
>> style module, code assuming that only one Author field
>> exists, will return (just) one of the available fields and
>> it's not at all clear which.
> 
> This quote is totally confusing. Sounds WAY too complicated. If you're
> going to switch to meta-discussions I may fall off at some point.

The first part of the quote should be clear. We need a new
meta-field for the already existing setup() keyword parameters
maintainer and maintainer_email.

The second part is something to consider when switching from
a single value meta-data field to a multi-valued one.

The meta-data file in distutils uses the RFC 822 header format
and the rfc822 (in Python 2.x) provides easy ways of getting
at those headers.

However, if code assumes that there's only one "Author" header,
it will just see the last occurrence of that header in the file.

In summary, all that needs to be done is:

* adding the maintainer headers to the meta-data format
* documenting that multiple authors should use a comma-separated
  list of names (optionally with email addresses) in the author
  field.
* document that the author_email and maintainer_email addresses
  should be used to provide a main contact email address for
  each (e.g. the address of a mailing list)

--

___
Python tracker 

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

[issue6992] Adding a Contributor field in PEP 314

[Tarek Ziadé]

Tarek Ziadé  added the comment:

> Right, but then we have:
>
> author
> author_email
> authors
> maintainer
> maintainer_email
>
> for consitency, we'd also need:
>
> author_emails
> maintainers
> maintainer_emails

In my mind the "perfect" situation would be just two arguments:

- authors  (goes in Author field - possibly multi-valued)
- contact_email (goes in Contact-email field)

And deprecate the others.

The "maintainer" concept is not on the metadata side, so it's not used
at *all* by the third-party tools or by PyPI.  

Adding it in the metadata adds more confusion imho than deprecate its
usage on Distutils side to stick with a very simple concept:

- a distribution has authors
- a distribution has a contact email.

So I am -1 adding Maintainer/Maintainer-email in the Metadata.

Now for the "Contact-email", it guess it's OK to keep "author_email ->
Author-email", and it's no big deal is "Author" stays singled valued,
as long as it contains all authors names right ?

So at the end, the changes on distutils setup() side would be:

- authors  (goes in Author field - with "," separations )
- contact_email  (goes in Author-email field)
- deprecation of the "author", "author_email", 
  "maintainer" and "mainainer_email" arguments 

So the metadata doesn't change and we have what we want.

--

___
Python tracker 

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

[issue6186] test_thread occasionally reports unhandled exceptions on OS X

[Skip Montanaro]

Skip Montanaro  added the comment:

and on svn trunk

--
nosy: +skip.montanaro

___
Python tracker 

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

[issue7015] Getting call trace while executing "modules spam" at help prompt

[Jan Kratochvil]

Changes by Jan Kratochvil :


--
nosy: +jankratochvil

___
Python tracker 

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

[issue6992] Adding a Contributor field in PEP 314

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Tarek Ziadé wrote:
> So at the end, the changes on distutils setup() side would be:
> 
> - authors  (goes in Author field - with "," separations )
> - contact_email  (goes in Author-email field)
> - deprecation of the "author", "author_email", 
>   "maintainer" and "mainainer_email" arguments 
> 
> So the metadata doesn't change and we have what we want.

-1 on that idea :-)

The meta-data is only used by PyPI and perhaps a handful
of other tools. The setup() keyword parameters OTOH are
used by most packages out there, so any change to these
has to be carefully planned.

Overall, I find the presented use case not really relevant
enough to warrant such a huge change. Even less so, since
there is a solution that works today without any changes.

The addition of the maintainer meta-data field would not
hurt anyone and create more consistency.

The rest is just documenting best practices.

--

___
Python tracker 

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

[issue7015] Getting call trace while executing "modules spam" at help prompt

[Jan Kratochvil]

Jan Kratochvil  added the comment:

This patch will make the `modules' command succeeed.
Later requesting the specific `gdb' module will cause:

help> gdb
problem in gdb - : 'module' object has
no attribute 'Command'

I think this is right in general, a single broken module should not
abort the whole modules traversal.


Another issues is why the `gdb' module fails: It expects the bindings
inside the native `/usr/bin/gdb' process to exist.  Should it just
silently skip its functions if no `/usr/bin/gdb' binding is found?  Or
should these gdb modules be located outside of `/usr/lib*/python2.x'?
There are already some glue python modules
in `/usr/share/gdb/auto-load/'.  Thanks for advice.

--
keywords: +patch
Added file: http://bugs.python.org/file15007/pkgutil.py.patch

___
Python tracker 

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

[issue7023] Marshal doesn't release GIL while dumping

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

The patch is wrong; the function allows other threads to run while it
calls _PyString_Resize(), this will lead to crashes.

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue6992] Adding a Contributor field in PEP 314

[Tarek Ziadé]

Tarek Ziadé  added the comment:

> The meta-data is only used by PyPI and perhaps a handful
> of other tools.
[...]
> The addition of the maintainer meta-data field would 
> not hurt anyone and create more consistency.

since PyPI has its own Role system (owner, maintainer) managed by the
user who registered the distribution, independantly from the Metadata,
what use case are you thinking about for a new Maintainer field ?

When an author is not maintaining a package anymore, and an extra name
has to be added, we previously said that this extra name could be added
in the author field. 

So what would be the gain to distinguish maintainers form authors, and 
how PyPI will deal with the fact that a package will have maintainers in
its metadata, and maintainers at PyPI that may differ ?

--

___
Python tracker 

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

[issue6992] Adding a Contributor field in PEP 314

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Tarek Ziadé wrote:
> 
> Tarek Ziadé  added the comment:
> 
>> The meta-data is only used by PyPI and perhaps a handful
>> of other tools.
> [...]
>> The addition of the maintainer meta-data field would 
>> not hurt anyone and create more consistency.
> 
> since PyPI has its own Role system (owner, maintainer) managed by the
> user who registered the distribution, independantly from the Metadata,
> what use case are you thinking about for a new Maintainer field ?

PyPI is just an application using the meta-data - and the only one
I know of.

I'm just suggesting to add the meta-data field in order to recreate
consistency - not advocating that setup() parameter or its use.

> When an author is not maintaining a package anymore, and an extra name
> has to be added, we previously said that this extra name could be added
> in the author field. 
> 
> So what would be the gain to distinguish maintainers form authors, and 
> how PyPI will deal with the fact that a package will have maintainers in
> its metadata, and maintainers at PyPI that may differ ?

That's up for the package owners to sort out. I would expect the
maintainer to do a new release and update the maintainer field.

--

___
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)

[Tarek Ziadé]

Tarek Ziadé  added the comment:

> I'm just suggesting to add the meta-data field in order to recreate
> consistency - not advocating that setup() parameter or its use.

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

While I understand your PoV about the fact that B/ is not impacting
existing packages and doesn't require any deprecation, I would like to
find some use cases for having such fields in the Metadata, other than
fixing the inconsistency.

If we don't have a use case, I'd go for A/

--
title: Adding a Contributor field in PEP 314 -> PEP 314 inconsistency 
(authors/author/maintainer)

___
Python tracker 

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

[issue7015] Getting call trace while executing "modules spam" at help prompt

[R. David Murray]

R. David Murray  added the comment:

It may well be possible to improve the handling of exceptions (I haven't
looked at your patch yet), but fixing gdb, or rather the python bindings
for it, are out of the scope of this bug tracker since it is third-party
code.

--
assignee: georg.brandl -> 
components: +Library (Lib) -Documentation
nosy: +r.david.murray
priority:  -> low
stage:  -> test needed
type: crash -> behavior

___
Python tracker 

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

[issue7023] Marshal doesn't release GIL while dumping

[Benjamin Peterson]

Benjamin Peterson  added the comment:

In fact, almost no place in marhsal is thread safe, so releasing the GIL
anywhere is not safe.

--
nosy: +benjamin.peterson
resolution:  -> 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

[issue7024] webbrowser : Could not open ftp server using webbrowser.open()

[Harshad Modi]

New submission from Harshad Modi :

Hi,

I try to open ftp site using webbrowser.open('ftp://localhost:21') in
python2.6.

but It can not open and give error like :
Error showing url: The specified location is not mounted

It is working good in python2.5

so can anybod help me ? what am I wrong ?

Thanks in Adcance.

--
messages: 93368
nosy: hmo
severity: normal
status: open
title: webbrowser : Could not open ftp server using webbrowser.open()
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

[issue7024] webbrowser : Could not open ftp server using webbrowser.open()

[Senthil Kumaran]

Senthil Kumaran  added the comment:

It is very difficult to debug with the information you have provided.
The webbrowser.py has indeed undergone some changes, but they are
positive changes and should not break any working behaviour.

For your problem, you might want to mention.
1) Your OS.
2) Your Default Browser ( as set by the OS)
3) Also, do the webbrowser.open() on a generic site like
"ftp://ftp.aduni.org"; in your python2.6 installation to see if that
works.

It works for me in python2.6 + firefox 3.x + Ubuntu.

--
nosy: +orsenthil

___
Python tracker 

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

[issue3366] Add gamma function, error functions and other C99 math.h functions to math module

[Mark Dickinson]

Mark Dickinson  added the comment:

A first attempt for lgamma, using Lanczos' formula.

In general, this gives very good accuracy.  As the tests show, there's one 
big problem area, namely when gamma(x) is close to +-1, so that lgamma(x) 
is close to 0.  This happens for x ~ 1.0,  x ~ 2.0, and various negative 
values of x (mathematically, lgamma(x) hits zero twice in each interval 
(n-1, n) for n <= -2).  In that case the accuracy is still good in 
absolute terms (around 1e-15 absolute error), but terrible in ulp terms.

I think it's reasonable to allow an absolute error of a few times the 
machine epsilon in lgamma:  for many uses, the lgamma result will be
exponentiated at some point (often after adding or subtracting other 
lgamma results), and at that point this absolute error just becomes a 
small relative error.

--
Added file: http://bugs.python.org/file15008/lgamma1.patch

___
Python tracker 

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

[issue7020] regression in pywin32 build due to 2.6.3rc1

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

Thank you Tarek.

I was able to fix the issue by patching pywin32's setup.py by using the 
`get_ext_filename` function from the CVS HEAD revision (which handles non-
namespaced extensions as well).

--
status: open -> closed

___
Python tracker 

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

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Thomas W. Barr]

Thomas W. Barr  added the comment:

os.path.realpath() doesn't normalize case, so this could have issues on
Windows. The new patch should not.

The Mac version of os.path.normpath doesn't change the path, as per the
posix version, which isn't correct on HFS+, which is not case sensitive.
That's another bug for another ticket, though.

--
Added file: http://bugs.python.org/file15009/zipfile-6972-patch-2.diff

___
Python tracker 

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

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Thomas W. Barr]

Changes by Thomas W. Barr :


Removed file: http://bugs.python.org/file15003/zipfile-6972-patch.diff

___
Python tracker 

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

[issue3366] Add gamma function, error functions and other C99 math.h functions to math module

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

I agree with your reasoning.

Any chance of also getting the incomplete beta and gamma functions,
needed to compute the CDF of many commonly used probability
distributions? (Beta, Logarithmic, Poisson, Chi-Square, Gamma, etc.)

--

___
Python tracker 

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

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Ned Deily]

Ned Deily  added the comment:

"The Mac version of os.path.normpath doesn't change the path, as per the
posix version, which isn't correct on HFS+, which is not case sensitive."

Not so. Case-sensitive vs case-insensitive behavior is chosen when 
initializing an HFS+ file system (since OS X 10.3).

--
nosy: +ned.deily

___
Python tracker 

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

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Thomas W. Barr]

Thomas W. Barr  added the comment:

Good point, I'd forgotten that case-sensitive file systems are an
option. I do know that it's not the default, though, and that as shipped
from Apple, at least the consumer machines are case-insensitive. Things
may be different in server-land.

For what it's worth, NTFS isn't entirely case-insensitive, either.
(http://support.microsoft.com/kb/100625)

Should the os.path.normcase() method be made smarter, and actually query
the filesystem about such things? (If I should start a new ticket for
this, somebody please let me know.)

--

___
Python tracker 

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

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Ned Deily]

Ned Deily  added the comment:

Yes, as shipped from the factory, the default "root" file system is 
still case-insensitive but the user can change that.  There there are 
file systems on attached disk images and NFS-mounted file systems, etc 
etc.  More to the point, it's not a system attribute, rather it's a 
file-system attribute and, since a file system mount point can be almost 
anywhere in a directory structure, in general, you can't predict where 
you're going to encounter insensitive vs -sensitive behavior; it could 
vary from directory to directory.  But isn't dealing with case-
insensitive behavior just a special case of the general case of what 
extract/extractall do about overwriting existing files?  I don't see 
that addressed in the current docs.

--

___
Python tracker 

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

[issue7015] Getting call trace while executing "modules spam" at help prompt

[Jan Kratochvil]

Jan Kratochvil  added the comment:

The python bindings were therefore fixed downstream:
gdb-6.8.91.20090930-2.fc12
http://koji.fedoraproject.org/koji/buildinfo?buildID=134595

--

___
Python tracker 

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

[issue7025] Python 3.1 and 3.2 (dev) opensearch.xml still references 3.0

[Jon Parise]

New submission from Jon Parise :

The _static/opensearch.xml output on docs.python.org for the 3.1 and 3.2
(dev/py3k) branches still refers to the 3.0 documentation.

Doc/conf.py's html_use_opensearch value should be updated in those
source branches to reflect their updated version numbers.

--
assignee: georg.brandl
components: Documentation
messages: 93378
nosy: georg.brandl, jon
severity: normal
status: open
title: Python 3.1 and 3.2 (dev) opensearch.xml still references 3.0
type: behavior
versions: 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

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Thomas W. Barr]

Thomas W. Barr  added the comment:

A fair point. I was thinking that we could query the OS about whatever
filesystem the path is on, but this wouldn't work for a file that hasn't
been created yet.

The issue with extractall() isn't just that it can extract over existing
files, it's that it can write files anywhere on the filesystem, both by
exploiting symlinks and through path manipulation. The more I think
about it, though, the more I think the case sensitivity is a non-issue
here, since the trailing part of the extraction paths is built out of
the base path, which I then compare against. The capitalization will
therefore be consistent, and I don't need to worry about this. Does this
seem right?

--

___
Python tracker 

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

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

The patch won't work if the target file already exists as a symlink.

I think that such a check is not a good idea. Using symlinks to extract files 
to somewhere else may be a feature, after all.  Specially if the symlink 
already exists before the operation. Some real-case example:
  /home/xxx/bin   --> symlink to /someotherpath/bin
  /home/xxx/lib   --> symlink to /someotherpath/lib
Now I want to extract "lib/libXXX.so" into "/home/xxx"

I suggest to only update the documentation with a warning, similar to the one 
for the tarfile module.

--

___
Python tracker 

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

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Ralf Schmitt]

Ralf Schmitt  added the comment:

Adding a warning to the documentation is wrong. The intention of the
code clearly is to only create files in the destination directory (or
why remove the first slash then?) and that is also the impression I get
from reading the documentation.

--

___
Python tracker 

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

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Adding a warning to the documentation is not wrong, it is the only thing 
that is possible for the 2.6.3 release.  Its too late in the current 
release process to change code.

--

___
Python tracker 

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

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

[Bill Janssen]

Bill Janssen  added the comment:

On Tue, Sep 29, 2009 at 12:47 PM, Giampaolo Rodola'
wrote:

>
> Giampaolo Rodola'  added the comment:
>
> Uhm... I'm sorry but actually I'm not sure about this patch anymore.
> Now that I look at ssl.py again I'm noticing that send() is trapped in a
> "while True" loop as well and the patch doesn't cover it.
>
> Not sure if that has been added recently or it was already there at the
> time I submitted the report but it's another thing that need to be
> fixed.
>
>
> Moreover, I'm sure that removing the "while" loop is good for non-
> blocking sockets but what about blocking ones?
> Are SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE supposed to be raised
> in a blocking environment?
>

No.

> If they aren't then the current patch just needs to take care of send()
> method too, then it's fine.
>

Yes, it's fine.

Bill

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

___
Python tracker 

___On Tue, Sep 29, 2009 at 12:47 PM, Giampaolo 
Rodola' rep...@bugs.python.org> 
wrote:

Giampaolo Rodola' billiej...@users.sourceforge.net>
 added the comment:

Uhm... I'm sorry but actually I'm not sure about this patch anymore.
Now that I look at ssl.py again I'm noticing that send() is trapped in a
"while True" loop as well and the patch doesn't cover it.

Not sure if that has been added recently or it was already there at the
time I submitted the report but it's another thing that need to be
fixed.


Moreover, I'm sure that removing the "while" loop is good for 
non-
blocking sockets but what about blocking ones?
Are SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE supposed to be raised
in a blocking 
environment?No. 
If they aren't then the current patch just needs to take care of send()
method too, then it's fine.Yes, it's 
fine.Bill 
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7026] test_urllib: unsetting missing 'env' variable

[Sridhar Ratnakumar]

New submission from Sridhar Ratnakumar :

test test_urllib failed -- Traceback (most recent call last):
  File "/home/apy/rrun/tmp/autotest/apy/lib/python2.6/test/
test_urllib.py", line 106, in setUp
env.unset(k)
NameError: global name 'env' is not defined


Looking in trunk's copy I see this:

def setUp(self):
# Records changes to env vars
self.env = test_support.EnvironmentVarGuard()
# Delete all proxy related env vars
for k, v in os.environ.iteritems():
if 'proxy' in k.lower():
del env[k]

Should not that be "del self.env[k]"?

--
components: Tests
messages: 93384
nosy: srid
severity: normal
status: open
title: test_urllib: unsetting missing 'env' variable
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

[issue7026] test_urllib: unsetting missing 'env' variable

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

The above mentioned traceback occurs in 2.6.3rc1

--

___
Python tracker 

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

[issue7025] Python 3.1 and 3.2 (dev) opensearch.xml still references 3.0

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Fixed in r75161.

--
nosy: +benjamin.peterson
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

[issue7027] test_io.py: codecs.IncrementalDecoder is sometimes None

[Sridhar Ratnakumar]

New submission from Sridhar Ratnakumar :

This test failure occurs on Windows XP (x86) with 2.6.3.rc1

==
ERROR: Test seek/tell using the StatefulIncrementalDecoder.
--
Traceback (most recent call last):
  File "C:\Python26\lib\test\test_io.py", line 1063, in testSeekAndTell
testSeekAndTellWithData(input)
  File "C:\Python26\lib\test\test_io.py", line 1043, in
testSeekAndTellWithData
decoded = f.read()
  File "C:\Python26\lib\io.py", line 1725, in read
decoder = self._decoder or self._get_decoder()
  File "C:\Python26\lib\io.py", line 1514, in _get_decoder
decoder = make_decoder(self._errors)
  File "C:\Python26\lib\test\test_io.py", line 636, in __init__
codecs.IncrementalDecoder.__init__(self, errors)
AttributeError: 'NoneType' object has no attribute 'IncrementalDecoder'

--
components: Tests
messages: 93387
nosy: srid
severity: normal
status: open
title: test_io.py: codecs.IncrementalDecoder is sometimes None
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

[issue7027] test_io.py: codecs.IncrementalDecoder is sometimes None

[R. David Murray]

Changes by R. David Murray :


--
nosy: +benjamin.peterson, pitrou
priority:  -> normal
stage:  -> needs patch
type:  -> behavior

___
Python tracker 

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

[issue7026] test_urllib: unsetting missing 'env' variable

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Fixed that in revision 75166. Even in release26-maint got to chnage it
from env.unset(k) to self.env.unset(k).

--
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> fixed

___
Python tracker 

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

[issue3329] API for setting the memory allocator used by Python

[Tim Lesher]

Changes by Tim Lesher :


--
nosy: +tlesher

___
Python tracker 

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

[issue7028] hex function should work with floats

[Josh Cogliati]

New submission from Josh Cogliati :

The hex() builtin function only takes integers.  Also there is no way to
create a floating point number from a hexadecimal string.  However it
would often be useful to be able to see the hexadecimal version of an
float since this is an exact representation as compared to the decimal
version.  

I propose that the format 0xMantisaP0xBase2Exponent be used (but other
possibilities would be fine.  For example in this way 0.5 decimal would
be 0x1p-0x1 hex.  1.1 decimal would be 0x8cccdp-0x33 and pi
would be 0x3243f6a8885a3p-0x30

Attached are two functions I created to implement this.  If this would
be better as a PEP I will create one.  

This will cause a slight incompatibility, since now hex will throw an
exception if it is passed a float.

--
components: Library (Lib)
files: fhex.py
messages: 93389
nosy: jrincayc
severity: normal
status: open
title: hex function should work with floats
versions: Python 3.1
Added file: http://bugs.python.org/file15011/fhex.py

___
Python tracker 

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

[issue7028] hex function should work with floats

[Josh Cogliati]

Changes by Josh Cogliati :


--
type:  -> feature request

___
Python tracker 

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

[issue6733] curses line wrap broken when mixing full- and half-width unicode characters

[fugounashi]

Changes by fugounashi :


--
components: +Library (Lib)

___
Python tracker 

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

[issue7024] webbrowser : Could not open ftp server using webbrowser.open()

[Harshad Modi]

Harshad Modi  added the comment:

[Senthil Kumaran]
Thanks to Reply.
1) OS : Ubuntu 9.04 - the Jaunty Jackalope - released in April 2009.
2) Default Browser : Firefox 3.0.8
3) Tested with "ftp://ftp.aduni.org"; but still error.
4) Python 2.6.2 (release26-maint, Apr 19 2009, 01:58:18) [GCC 4.3.3] on
linux2

Sorry It is not work for me in python2.6.2 + Ubuntu 9.04 + Firefox 3.0.8

Thanks

--

___
Python tracker 

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