Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
Guido van Rossum wrote:
> Ah, sigh. I didn't know that os.listdir() behaves differently when the
> argument is Unicode. Does os.listdir(".") really behave differently
> than os.listdir(u".")? Bah! I don't think that's a very good design
> (although I see where it comes from). Promoting only those entries
> that need it seems the right solution
Unfortunately, this solution is hard to implement (I don't know whether
it is implementable at all correctly; atleast on Windows, I see no
way to implement it efficiently).
Here are a number of problems/questions:
- On Windows, should listdir use the narrow or the wide API? Obviously
the wide API, since it is not Python which returns the question marks,
but the Windows API.
- But then, the wide API gives all results as Unicode. If you want to
promote only those entries that need it, it really means that you
only want to "demote" those that don't need it. But how can you tell
whether an entry needs it? There is no API to find out.
You could declare that anything with characters >128 needs it,
but that would be an incompatible change: If a character >128 in
the system code page is in a file name, listdir currently returns
it in the system code page. It then would return a Unicode string.
Applications relying on the olde behaviour would break.
- On Unix, all file names come out as byte strings. Again, how do
you know which ones to promote, and using what encoding? Python
currently guesses an encoding, but that may or may not be the one
intended for the file name.
So the general "Bah!" doesn't really help much: when it comes to
a specific algorithm to implement, the options are scarce.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
{MAL]
> This is exactly what I'm getting at: I can see the potential
> use for resource management (which is what started out the
> whole idea IIRC), but fail to see why you'd want to use it
> for anything more complicated than that.
Substitute "different" for "complicated".
'with' is not application specific, it is incredibly general. All it
does is abstract recurring uses of try/finally.
Naming it after a specific class of applications would be a mistake.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python on PyPI
Hi, to whom it may concern: the Python package on PyPI is at version 2.3.2. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers
Keith Dart wrote: >On Sat, 18 Jun 2005, Michael Hudson wrote: > > > >>The shortest way I know of going from 2149871625L to -2145095671 is >>the still-fairly-gross: >> >> >> >v = 2149871625L >~int(~v&0x) > > >>-2145095671 >> >> >> >>>I suppose the best thing is to introduce an "unsignedint" type for this >>>purpose. >>> >>> >>Or some kind of bitfield type, maybe. >> >>C uses integers both as bitfields and to count things, and at least in >>my opinion the default assumption in Python should be that this is >>what an integer is being used for, but when you need a bitfield it can >>all get a bit horrible. >> >>That said, I think in this case we can just make fcntl_ioctl use the >>(new-ish) 'I' format argument to PyArg_ParseTuple and then you'll just >>be able to use 2149871625L and be happy (I think, haven't tried this). >> >> > >Thanks for the reply. I think I will go ahead and add some extension types >to Python. Thankfully, Python is extensible with new objects. > >It is also useful (to me, anyway) to be able to map, one to one, >external primitives from other systems to Python primitives. For >example, CORBA and SNMP have a set of types (signed ints, unsigned ints, >etc.) defined that I would like to interface to Python (actually I have >already done this to some degree). But Python makes it a bit more >difficult without that one-to-one mapping of basic types. Having an >unsigned int type, for example, would make it easier to interface Python >to SNMP or even some C libraries. > >In other words, Since the "Real World" has these types that I must >sometimes interface to, it is useful to have these same (predictable) >types in Python. > >So, it is worth extending the basic set of data types, and I will add it >to my existing collection of Python extensions. > >Therefore, I would like to ask here if anyone has already started >something like this? If not, I will go ahead and do it (if I have time). > > > I should make you aware that the new Numeric (Numeric3 now called scipy.base) has a collection of C-types that represent each C-datatype. They are (arguably) useful in the context of eliminating a few problems in data-type coercion in scientific computing. These types are created in C and use multiple inheritance in C. This is very similiar to what you are proposing and so I thought I might make you aware. Right now, the math operations from each of these types comes mostly from Numeric but this could be modified as desired. The code is available in the Numeric3 CVS tree at the numeric python sourceforge site. -Travis Oliphant ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Nick Coghlan wrote: > M.-A. Lemburg wrote: > >>May I suggest that you use a different name than "context" for >>this ?! >> >>The term "context" is way to broad for the application scopes >>that you have in mind here (like e.g. managing a resource >>in a multi-threaded application). > > > It's actually the broadness of the term 'context' which is appealing - the > examples in the draft documentation on SF are: > >- resource management (synchronisation locks, generic 'closing') >- HTML tag matching >- Decimal arithmetic context > > Any earlier version used 'suite managers' (partly to avoid confusing the hell > out of anyone ever exposed to Ruby's concept of blocks), but the 'context > management' term seems to more clearly describe what the protocol is for. This is exactly what I'm getting at: I can see the potential use for resource management (which is what started out the whole idea IIRC), but fail to see why you'd want to use it for anything more complicated than that. Once you start talking about contexts (which usually refers to a combination of environment, state and location) you have to explain things like nesting, scopes, combination of different contexts, their interaction with each other, etc. etc. Note that hiding things away in smart objects like what you call "context managers" will not make programs easier to understand, unless the specific task that such a "context manager" is simple enough to grasp by just looking at its definition in the with statement... but then you'd not call it a "context manager". BTW, the same argument applies to decorators. Programs don't get easier to read or understand if you overload a function with lots and lots of hidden magic... @put_all_the_smart_stuff_here def program(context): return "42" Of course, you *could* do all these things and Python is not preventing you from doing so, but will life get easier ? I doubt it. Let's keep things simple and Python nice. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 14 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python/dist/src/Miscdevelopers.txt, 1.15, 1.16
On 7/14/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > raymond> Log Message: > > raymond> Brett requests that Flovis's permissions be dropped. > > [Skip] > > Not to put too fine a spin on things, but I think it was more like > Brett > > got > > tired of waiting for Flovis's permissions to be increased and > retracted > > his > > original request. > > > Brett and Flovis DID send a private email with a drop request this > morning. They have chosen an alternate method of access. > > Brett's original request was fulfilled within 48 hours. I sent him a > confirmation note. Also, there was a concurrent check-in notification > for Misc/developers.txt. Additionally, Flovis's id appeared on the SF > developer list immediately. If for some reason they did not see any of > those three, they could have sent a follow-up note and gotten a fourth > confirmation that the job was done. > Yeah, I missed all three; I just kept expecting a reply to the python-dev list and wasn't looking for any other signs, so it's my bad. I moved over to Gmail a few weeks ago and I am still working out my Python workflow with it. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python/dist/src/Miscdevelopers.txt, 1.15, 1.16
> raymond> Log Message: > raymond> Brett requests that Flovis's permissions be dropped. [Skip] > Not to put too fine a spin on things, but I think it was more like Brett > got > tired of waiting for Flovis's permissions to be increased and retracted > his > original request. Brett and Flovis DID send a private email with a drop request this morning. They have chosen an alternate method of access. Brett's original request was fulfilled within 48 hours. I sent him a confirmation note. Also, there was a concurrent check-in notification for Misc/developers.txt. Additionally, Flovis's id appeared on the SF developer list immediately. If for some reason they did not see any of those three, they could have sent a follow-up note and gotten a fourth confirmation that the job was done. IOW, the check-in message is accurate. Your re-interpretation notwithstanding, if there's a problem, it is not on this end. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python/dist/src/Misc developers.txt, 1.15, 1.16
raymond> Log Message: raymond> Brett requests that Flovis's permissions be dropped. Not to put too fine a spin on things, but I think it was more like Brett got tired of waiting for Flovis's permissions to be increased and retracted his original request. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] e-mail addresses
On Thu, Jul 14, 2005, M.-A. Lemburg wrote: > > PS: Please don't use "-nospam" or the like email addresses when posting > to this list. Thanks. ...unless it's a valid address. Some people do use real addresses with "nospam" as an actual part of the address as an anti-spam measure. But it's always polite to include "yes, this is a real address" or similar in the .sig. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
Hi Neil,
>>> With the proposed modification, sys.argv[1] u'\u20ac.txt' is
>>>converted through cp1251
>>
>>Actually, it is not: if you pass in a Unicode argument to
>>one of the file I/O functions and the OS supports Unicode
>>directly or at least provides the notion of a file system
>>encoding, then the file I/O should use the Unicode APIs
>>of the OS or convert the Unicode argument to the file system
>>encoding. AFAIK, this is how posixmodule.c already works
>>(more or less).
>
>
>Yes it is. The initial stage is reading the command line arguments.
> The proposed modification is to change behaviour when constructing
> sys.argv, os.environ or when calling os.listdir to "Return unicode
> when the text can not be represented in Python's default encoding". I
> take this to mean that when the value can be represented in Python's
> default encoding then it is returned as a byte string in the default
> encoding.
>
>Therefore, for the example, the code that sets up sys.argv has to
> encode the unicode command line argument into cp1251.
Ok, I missed your point about sys.argv *not* returning Unicode
in this particular case.
However, with the modification of having posixmodule
and fileobject recode string input via Unicode (based on the
default encoding) into the file system encoding by basically
just changing the parser marker from "et" to "es", you
get correct behaviour - even in the above case.
Both posixmodule and fileobject would then take the cp1251
default encoded string, convert it to Unicode and then
to the file system encoding before opening the file.
>>On input, file I/O APIs should accept both strings using
>>the default encoding and Unicode. How these inputs are then
>>converted to suit the OS is up to the OS abstraction layer, e.g.
>>posixmodule.c.
>
>
>This looks to me to be insufficiently compatible with current
> behaviour whih accepts byte strings outside the default encoding.
> Existing code may call open("€.txt"). This is perfectly legitimate
> current Python (with a coding declaration) as "€.txt" is a byte string
> and file systems will accept byte string names. Since the standard
> default encoding is ASCII, should such code raise UnicodeDecodeError?
Yes.
The above proposed change is indeed more restrictive than
the current pass-through approach. I'm not sure whether we
can impose such a change on the users in the 2.x series...
perhaps we should have a two phase approach:
Phase 1:
try "et" and if this fails with an UnicodeDecodeError,
revert back to the old "es" pass-through approach, issuing
a warning as non-disruptive signal to the user
Phase 2:
move to "et" for good and issue decode errors
>>Changing this is easy, though: instead of using the "et"
>>getargs format specifier, you'd have to use "es". The latter
>>recodes strings based on the default encoding assumption to
>>whatever other encoding you specify.
>
>Don't you want to convert these into unicode rather than another
> byte string encoding? It looks to me as though the "es" format always
> produces byte strings and the only byte string format that can be
> passed to the operating system is the file system encoding which may
> not contain all the characters in the default encoding.
If the OS support Unicode directly, we can (and do) have a
special case that bypasses the recoding altogheter. However,
this currently only appears to be available on Windows
versions NT, XP and up, where we already support this.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jul 14 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SF patch #1214889 - file.encoding support
M.-A. Lemburg wrote: > Reinhold Birkenfeld wrote: >> Hi, >> >> would anyone care to comment about this patch of mine -- >> https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470 >> >> It makes file.encoding read-write and lets the write() and writelines() >> methods >> obey it. > > Done. Please see SF. > > PS: Please don't use "-nospam" or the like email addresses when posting > to this list. Thanks. Why? This address is perfectly valid (as is written in my signature), and almost completely spam-free. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SF patch #1214889 - file.encoding support
Reinhold Birkenfeld wrote: > Hi, > > would anyone care to comment about this patch of mine -- > https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470 > > It makes file.encoding read-write and lets the write() and writelines() > methods > obey it. Done. Please see SF. PS: Please don't use "-nospam" or the like email addresses when posting to this list. Thanks. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 14 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
